[Phpmyadmin-devel] legal concerns about external libraries
Good day, team The Fedora legal team has discovered a potential licensing problem in the PHPExcel library bundled with phpMyAdmin. If true, and I am not a lawyer but it seems they are correct, that puts phpMyAdmin itself in violation and Fedora would then remove our package until we resolve the licensing problem. The report is at https://bugzilla.redhat.com/show_bug.cgi?id=629214 and the Tom there is from the Fedora Legal team, Robert is the (friendly) Fedora phpMyAdmin maintainer who I've also copied on this message (who first came to us on IRC to discuss this problem). It looks like the problem had been reported to the PHPExcel in February of 2010 but not resolved (http://phpexcel.codeplex.com/Thread/View.aspx?ThreadId=83335). Robert's also mentioned that they're investigating a similar claim regarding tcpdf; I believe that discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=548260 Regards, ~isaac
Isaac Bennetch a écrit :
Good day, team
The Fedora legal team has discovered a potential licensing problem in the PHPExcel library bundled with phpMyAdmin. If true, and I am not a lawyer but it seems they are correct, that puts phpMyAdmin itself in violation and Fedora would then remove our package until we resolve the licensing problem.
The report is at https://bugzilla.redhat.com/show_bug.cgi?id=629214 and the Tom there is from the Fedora Legal team, Robert is the (friendly) Fedora phpMyAdmin maintainer who I've also copied on this message (who first came to us on IRC to discuss this problem).
It looks like the problem had been reported to the PHPExcel in February of 2010 but not resolved (http://phpexcel.codeplex.com/Thread/View.aspx?ThreadId=83335).
Robert's also mentioned that they're investigating a similar claim regarding tcpdf; I believe that discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=548260
Regards, ~isaac
Thanks Isaac for relaying this issue to the team. -- Marc Delisle http://infomarc.info
Isaac Bennetch a écrit :
Good day, team
The Fedora legal team has discovered a potential licensing problem in the PHPExcel library bundled with phpMyAdmin. If true, and I am not a lawyer but it seems they are correct, that puts phpMyAdmin itself in violation and Fedora would then remove our package until we resolve the licensing problem.
The report is at https://bugzilla.redhat.com/show_bug.cgi?id=629214 and the Tom there is from the Fedora Legal team, Robert is the (friendly) Fedora phpMyAdmin maintainer who I've also copied on this message (who first came to us on IRC to discuss this problem).
It looks like the problem had been reported to the PHPExcel in February of 2010 but not resolved (http://phpexcel.codeplex.com/Thread/View.aspx?ThreadId=83335).
The change in license exists in the downloaded version of PHPExcel 1.7.6; this was not done by the phpMyAdmin team. The idea is that we want to remove the problematic files. For exporting in Excel 2007, my quick test worked (after removing PHPExcel/Shared/OLE directory, OLE.php and OLERead.php). For exporting in Excel 97-2003, it does not work, we would have to remove the calling of class PHPExcel_Shared_OLE_PPS_FILE from Writer/Excel5.php and maybe some other tweaking. I suggest dropping support for "Excel 97-2003". An alternative for these versions is our "CSV for MS Excel" export.
Robert's also mentioned that they're investigating a similar claim regarding tcpdf; I believe that discussion is at https://bugzilla.redhat.com/show_bug.cgi?id=548260
Regards, ~isaac
-- Marc Delisle http://infomarc.info
Hi Dne Tue, 02 Aug 2011 09:13:18 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
The change in license exists in the downloaded version of PHPExcel 1.7.6; this was not done by the phpMyAdmin team.
The idea is that we want to remove the problematic files.
For exporting in Excel 2007, my quick test worked (after removing PHPExcel/Shared/OLE directory, OLE.php and OLERead.php).
For exporting in Excel 97-2003, it does not work, we would have to remove the calling of class PHPExcel_Shared_OLE_PPS_FILE from Writer/Excel5.php and maybe some other tweaking.
I suggest dropping support for "Excel 97-2003". An alternative for these versions is our "CSV for MS Excel" export.
I still wonder if native support for Excel 2007 is worth including 3 MiB of code. How about shipping just wrapper files (export and import plugins), which would work only if PHPExcel is installed in PHP search path? This way we could include support for both, but user would have to download PHPExcel on his own. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
Hi
Dne Tue, 02 Aug 2011 09:13:18 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
The change in license exists in the downloaded version of PHPExcel 1.7.6; this was not done by the phpMyAdmin team.
The idea is that we want to remove the problematic files.
For exporting in Excel 2007, my quick test worked (after removing PHPExcel/Shared/OLE directory, OLE.php and OLERead.php).
For exporting in Excel 97-2003, it does not work, we would have to remove the calling of class PHPExcel_Shared_OLE_PPS_FILE from Writer/Excel5.php and maybe some other tweaking.
I suggest dropping support for "Excel 97-2003". An alternative for these versions is our "CSV for MS Excel" export.
I still wonder if native support for Excel 2007 is worth including 3 MiB of code.
Where I work, a user faced a situation where simple CSV exporting was not enough but I don't remember the specifics. Maybe Dieter can add his comments about native support's advantages.
How about shipping just wrapper files (export and import plugins), which would work only if PHPExcel is installed in PHP search path?
This might be more difficult to set up for user in hosting environments.
This way we could include support for both, but user would have to download PHPExcel on his own.
-- Marc Delisle http://infomarc.info
Hi Dne Tue, 02 Aug 2011 10:18:33 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
Michal Čihař a écrit :
I still wonder if native support for Excel 2007 is worth including 3 MiB of code.
Where I work, a user faced a situation where simple CSV exporting was not enough but I don't remember the specifics. Maybe Dieter can add his comments about native support's advantages.
Having use case when native Excel is needed would definitely help in making such decision.
How about shipping just wrapper files (export and import plugins), which would work only if PHPExcel is installed in PHP search path?
This might be more difficult to set up for user in hosting environments.
It definitely would be, however it would save us of licensing troubles and decrease download size. -- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
On Tue, Aug 2, 2011 at 9:51 PM, Michal Čihař <michal@cihar.com> wrote:
Hi
Dne Tue, 02 Aug 2011 10:18:33 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
Michal Čihař a écrit :
I still wonder if native support for Excel 2007 is worth including 3 MiB of code.
Where I work, a user faced a situation where simple CSV exporting was not enough but I don't remember the specifics. Maybe Dieter can add his comments about native support's advantages.
Having use case when native Excel is needed would definitely help in making such decision.
How about shipping just wrapper files (export and import plugins), which would work only if PHPExcel is installed in PHP search path?
This might be more difficult to set up for user in hosting environments.
It definitely would be, however it would save us of licensing troubles and decrease download size.
As an alternative: I would find it a great have a full and light version of phpmyadmin where libs such as phpexcel are not included.
-- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Michal Čihař a écrit :
Hi
Dne Tue, 02 Aug 2011 10:18:33 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
Michal Čihař a écrit :
I still wonder if native support for Excel 2007 is worth including 3 MiB of code. Where I work, a user faced a situation where simple CSV exporting was not enough but I don't remember the specifics. Maybe Dieter can add his comments about native support's advantages.
Having use case when native Excel is needed would definitely help in making such decision.
Michal, in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer. Then Garvin Hicking replied "it's a good benefit". We could ask the phpmyadmin-users list about use cases.
How about shipping just wrapper files (export and import plugins), which would work only if PHPExcel is installed in PHP search path? This might be more difficult to set up for user in hosting environments.
It definitely would be, however it would save us of licensing troubles and decrease download size.
-- Marc Delisle http://infomarc.info
2011/8/3 Marc Delisle <marc@infomarc.info>:
Michal Čihař a écrit :
Hi
Dne Tue, 02 Aug 2011 10:18:33 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
Michal Čihař a écrit :
I still wonder if native support for Excel 2007 is worth including 3 MiB of code. Where I work, a user faced a situation where simple CSV exporting was not enough but I don't remember the specifics. Maybe Dieter can add his comments about native support's advantages.
Having use case when native Excel is needed would definitely help in making such decision.
Michal, in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer.
Then Garvin Hicking replied "it's a good benefit".
We could ask the phpmyadmin-users list about use cases.
Good idea. I wouldn't drop Excel (97/2003 or 2007) export just like that, unless nobody seems to use it of course. ;) F.e. : It's very useful to export data from a database using a query to an excel-sheet to use for further analysis (or other uses). Since both Excel 2003 and 2007 (and other versions) are still widely used, I don't think that any of them can be dropped. It's true that CSV-export can be used for that, but it would mean an extra step to convert to Excel. I had a brief look at the PHPExcel library yesterday and I think it will be possible to remove a lot from the library that we don't use, including the OLE part (which would solve the license problem). OLE is used to link objects (like an excel sheet or a graph) to other documents/applications, but we don't use that when exporting to Excel format.
How about shipping just wrapper files (export and import plugins), which would work only if PHPExcel is installed in PHP search path? This might be more difficult to set up for user in hosting environments.
True, but the phpMyAdmin package has to be installed by someone anyway. It could be part of the installation procedure to install the PHPExcel library somewhere. But then again, this might cause compatibility problems with future releases of both phpMyAdmin and PHPExcel.
It definitely would be, however it would save us of licensing troubles and decrease download size.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Groetjes, Dieter Adriaenssens
Dieter Adriaenssens a écrit :
2011/8/3 Marc Delisle <marc@infomarc.info>:
Michal Čihař a écrit :
Hi
Dne Tue, 02 Aug 2011 10:18:33 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
Michal Čihař a écrit :
I still wonder if native support for Excel 2007 is worth including 3 MiB of code. Where I work, a user faced a situation where simple CSV exporting was not enough but I don't remember the specifics. Maybe Dieter can add his comments about native support's advantages. Having use case when native Excel is needed would definitely help in making such decision. Michal, in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer.
Then Garvin Hicking replied "it's a good benefit".
We could ask the phpmyadmin-users list about use cases.
Good idea.
I wouldn't drop Excel (97/2003 or 2007) export just like that, unless nobody seems to use it of course. ;) F.e. : It's very useful to export data from a database using a query to an excel-sheet to use for further analysis (or other uses). Since both Excel 2003 and 2007 (and other versions) are still widely used, I don't think that any of them can be dropped. It's true that CSV-export can be used for that, but it would mean an extra step to convert to Excel.
Not necessarily an extra step. In my tests, Excel is happy to open this .csv file and save changes to it (it just displays a warning at save time but no need to convert). I admit I'm not a seasoned Excel user.
I had a brief look at the PHPExcel library yesterday and I think it will be possible to remove a lot from the library that we don't use, including the OLE part (which would solve the license problem). OLE is used to link objects (like an excel sheet or a graph) to other documents/applications, but we don't use that when exporting to Excel format.
How about shipping just wrapper files (export and import plugins), which would work only if PHPExcel is installed in PHP search path? This might be more difficult to set up for user in hosting environments.
True, but the phpMyAdmin package has to be installed by someone anyway. It could be part of the installation procedure to install the PHPExcel library somewhere. But then again, this might cause compatibility problems with future releases of both phpMyAdmin and PHPExcel.
It definitely would be, however it would save us of licensing troubles and decrease download size.
-- Marc Delisle http://infomarc.info
Hi Dne Wed, 3 Aug 2011 15:48:12 +0200 Dieter Adriaenssens <dieter.adriaenssens@gmail.com> napsal(a):
I wouldn't drop Excel (97/2003 or 2007) export just like that, unless nobody seems to use it of course. ;) F.e. : It's very useful to export data from a database using a query to an excel-sheet to use for further analysis (or other uses). Since both Excel 2003 and 2007 (and other versions) are still widely used, I don't think that any of them can be dropped. It's true that CSV-export can be used for that, but it would mean an extra step to convert to Excel.
You can open CSV files with Excel without any extra step, I think it will ask you to change format when you try to save it.
I had a brief look at the PHPExcel library yesterday and I think it will be possible to remove a lot from the library that we don't use, including the OLE part (which would solve the license problem). OLE is used to link objects (like an excel sheet or a graph) to other documents/applications, but we don't use that when exporting to Excel format.
Stripping down the library would be option as well.
True, but the phpMyAdmin package has to be installed by someone anyway. It could be part of the installation procedure to install the PHPExcel library somewhere.
pear installation should be easy enough.
But then again, this might cause compatibility problems with future releases of both phpMyAdmin and PHPExcel.
Indeed, thought requiring exact version should be possible. -- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
Michal Čihař a écrit :
Hi
Dne Wed, 3 Aug 2011 15:48:12 +0200 Dieter Adriaenssens <dieter.adriaenssens@gmail.com> napsal(a):
I wouldn't drop Excel (97/2003 or 2007) export just like that, unless nobody seems to use it of course. ;)
We also use this library for Excel 97/2003 or 2007 import.
F.e. : It's very useful to export data from a database using a query to an excel-sheet to use for further analysis (or other uses). Since both Excel 2003 and 2007 (and other versions) are still widely used, I don't think that any of them can be dropped. It's true that CSV-export can be used for that, but it would mean an extra step to convert to Excel.
You can open CSV files with Excel without any extra step, I think it will ask you to change format when you try to save it.
I had a brief look at the PHPExcel library yesterday and I think it will be possible to remove a lot from the library that we don't use, including the OLE part (which would solve the license problem). OLE is used to link objects (like an excel sheet or a graph) to other documents/applications, but we don't use that when exporting to Excel format.
Stripping down the library would be option as well.
True, but the phpMyAdmin package has to be installed by someone anyway. It could be part of the installation procedure to install the PHPExcel library somewhere.
pear installation should be easy enough.
I had not noticed that PHPExcel is available as a PEAR package! (from http://phpexcel.codeplex.com/releases/view/45412). We would have some testing to do to ensure all goes smoothly with an unbundled PHPExcel library.
But then again, this might cause compatibility problems with future releases of both phpMyAdmin and PHPExcel.
Indeed, thought requiring exact version should be possible.
-- Marc Delisle http://infomarc.info
Hi Dne Wed, 03 Aug 2011 07:45:53 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer.
Yes, it was completely different code compared to current one and it did require setup from user (it required temporary dir to construct files).
Then Garvin Hicking replied "it's a good benefit".
We could ask the phpmyadmin-users list about use cases.
For whatever feature, you will always find at least one user :-). -- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
Michal Čihař a écrit :
Hi
Dne Wed, 03 Aug 2011 07:45:53 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer.
Yes, it was completely different code compared to current one and it did require setup from user (it required temporary dir to construct files).
Then Garvin Hicking replied "it's a good benefit".
We could ask the phpmyadmin-users list about use cases.
For whatever feature, you will always find at least one user :-).
True but for a feature that has been in the code since 2004, the base of persons using it has had the time to grow. Especially when we're talking about a product as popular as MS Excel. -- Marc Delisle http://infomarc.info
Marc Delisle a écrit :
Michal Čihař a écrit :
Hi
Dne Wed, 03 Aug 2011 07:45:53 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer. Yes, it was completely different code compared to current one and it did require setup from user (it required temporary dir to construct files).
Then Garvin Hicking replied "it's a good benefit".
We could ask the phpmyadmin-users list about use cases. For whatever feature, you will always find at least one user :-).
True but for a feature that has been in the code since 2004, the base of persons using it has had the time to grow. Especially when we're talking about a product as popular as MS Excel.
Well, a few days after asking on the phpmyadmin-users list about this, we got four answers and they are happy with using CSV for their export and import needs. Removing PHPExcel for the upcoming 3.5 is something we could easily do, and we could also remove it for the 3.4.5 release (or 3.4.4-rc2) so that the Fedora team can see the licensing issue resolved for our current stable release. Still have to verify the tcpdf issue, however. -- Marc Delisle http://infomarc.info
2011/8/8 Marc Delisle <marc@infomarc.info>:
Marc Delisle a écrit :
Michal Čihař a écrit :
Hi
Dne Wed, 03 Aug 2011 07:45:53 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer. Yes, it was completely different code compared to current one and it did require setup from user (it required temporary dir to construct files).
Then Garvin Hicking replied "it's a good benefit".
We could ask the phpmyadmin-users list about use cases. For whatever feature, you will always find at least one user :-).
True but for a feature that has been in the code since 2004, the base of persons using it has had the time to grow. Especially when we're talking about a product as popular as MS Excel.
Well, a few days after asking on the phpmyadmin-users list about this, we got four answers and they are happy with using CSV for their export and import needs.
I find it strange there are no objections against removing support for import/export excel files from our user base, but if nobody really needs it, then we can remove it I guess.
Removing PHPExcel for the upcoming 3.5 is something we could easily do, and we could also remove it for the 3.4.5 release (or 3.4.4-rc2) so that the Fedora team can see the licensing issue resolved for our current stable release.
I'll remove PHPExcel and the import/export for Excel from QA_3_4, or shall I create a branch first, to test it?
Still have to verify the tcpdf issue, however.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Groetjes, Dieter Adriaenssens
Le 2011-08-10 03:32, Dieter Adriaenssens a écrit :
2011/8/8 Marc Delisle <marc@infomarc.info>:
Marc Delisle a écrit :
Michal Čihař a écrit :
Hi
Dne Wed, 03 Aug 2011 07:45:53 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer. Yes, it was completely different code compared to current one and it did require setup from user (it required temporary dir to construct files).
Then Garvin Hicking replied "it's a good benefit".
We could ask the phpmyadmin-users list about use cases. For whatever feature, you will always find at least one user :-).
True but for a feature that has been in the code since 2004, the base of persons using it has had the time to grow. Especially when we're talking about a product as popular as MS Excel.
Well, a few days after asking on the phpmyadmin-users list about this, we got four answers and they are happy with using CSV for their export and import needs.
I find it strange there are no objections against removing support for import/export excel files from our user base, but if nobody really needs it, then we can remove it I guess.
As Michal said, "for whatever feature, you will always find at least one user" so at this point, I'm not saying that nobody needs it. However, these users should find that CSV import/export is a correct replacement for this feature.
Removing PHPExcel for the upcoming 3.5 is something we could easily do, and we could also remove it for the 3.4.5 release (or 3.4.4-rc2) so that the Fedora team can see the licensing issue resolved for our current stable release.
I'll remove PHPExcel and the import/export for Excel from QA_3_4, or shall I create a branch first, to test it?
I don't think a branch is necessary. Please do the removal.
Still have to verify the tcpdf issue, however.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Marc Delisle http://infomarc.info
2011/8/10 Marc Delisle <marc@infomarc.info>:
Le 2011-08-10 03:32, Dieter Adriaenssens a écrit :
2011/8/8 Marc Delisle <marc@infomarc.info>:
Marc Delisle a écrit :
Michal Čihař a écrit :
Hi
Dne Wed, 03 Aug 2011 07:45:53 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
in this old message from June 2004 https://sourceforge.net/mailarchive/forum.php?thread_name=20040608142911.GA1... you mention that you added MS Excel export with PEAR Spreadsheet_Excel_Writer. Yes, it was completely different code compared to current one and it did require setup from user (it required temporary dir to construct files).
Then Garvin Hicking replied "it's a good benefit".
We could ask the phpmyadmin-users list about use cases. For whatever feature, you will always find at least one user :-).
True but for a feature that has been in the code since 2004, the base of persons using it has had the time to grow. Especially when we're talking about a product as popular as MS Excel.
Well, a few days after asking on the phpmyadmin-users list about this, we got four answers and they are happy with using CSV for their export and import needs.
I find it strange there are no objections against removing support for import/export excel files from our user base, but if nobody really needs it, then we can remove it I guess.
As Michal said, "for whatever feature, you will always find at least one user" so at this point, I'm not saying that nobody needs it. However, these users should find that CSV import/export is a correct replacement for this feature.
Removing PHPExcel for the upcoming 3.5 is something we could easily do, and we could also remove it for the 3.4.5 release (or 3.4.4-rc2) so that the Fedora team can see the licensing issue resolved for our current stable release.
I'll remove PHPExcel and the import/export for Excel from QA_3_4, or shall I create a branch first, to test it?
I don't think a branch is necessary. Please do the removal.
library/PHPExcel and native Excel import/export was removed from QA_3_4 (ready for 3.4.5) and master. I've run into some things that seemed to be used only by Excel export/import, but haven't removed them yet : - config option TempDir -> according to Documentation.html this was needed for Excel export, the option is only used in File.Class.php -> checkUploadedFile() - checkUploadedFile () -> not used anymore - PMA_getColumnNumberFromName() -> not used Shall I remove them as well, or will they be needed in the future? BTW : PMA_getColumnAlphaName() is still used by ods import
Still have to verify the tcpdf issue, however.
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Groetjes, Dieter Adriaenssens
Dieter Adriaenssens a écrit :
library/PHPExcel and native Excel import/export was removed from QA_3_4 (ready for 3.4.5) and master. I've run into some things that seemed to be used only by Excel export/import, but haven't removed them yet :
- config option TempDir -> according to Documentation.html this was needed for Excel export, the option is only used in File.Class.php -> checkUploadedFile() - checkUploadedFile () -> not used anymore - PMA_getColumnNumberFromName() -> not used
Shall I remove them as well, or will they be needed in the future?
About TempDir, there is another (optional) purpose, see FAQ 1.11. But it's been a while since I last tested this... checkUploadedFile() has comments about being used in the open_basedir situation.
BTW : PMA_getColumnAlphaName() is still used by ods import
-- Marc Delisle http://infomarc.info
2011/8/10 Marc Delisle <marc@infomarc.info>:
Dieter Adriaenssens a écrit :
library/PHPExcel and native Excel import/export was removed from QA_3_4 (ready for 3.4.5) and master. I've run into some things that seemed to be used only by Excel export/import, but haven't removed them yet :
- config option TempDir -> according to Documentation.html this was needed for Excel export, the option is only used in File.Class.php -> checkUploadedFile() - checkUploadedFile () -> not used anymore - PMA_getColumnNumberFromName() -> not used
Shall I remove them as well, or will they be needed in the future?
About TempDir, there is another (optional) purpose, see FAQ 1.11. But it's been a while since I last tested this...
checkUploadedFile() has comments about being used in the open_basedir situation.
OK, won't touch them.
BTW : PMA_getColumnAlphaName() is still used by ods import
-- Marc Delisle http://infomarc.info
------------------------------------------------------------------------------ uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Groetjes, Dieter Adriaenssens
participants (5)
-
Dieter Adriaenssens -
Isaac Bennetch -
Marc Delisle -
Michal Čihař -
Tyron Madlener