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.
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
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ř 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.
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.
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.
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
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.
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ř 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.
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ř 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 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.
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
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
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
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
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
-
Dieter Adriaenssens -
Isaac Bennetch -
Marc Delisle -
Michal Čihař -
Tyron Madlener