backdrop-contrib / phpexcel

The PHPExcel module allows developers to export/import data to/from real Excel files.
GNU General Public License v2.0
0 stars 2 forks source link

Need a new module, the successor to PHPExcel. #7

Open VasasA opened 6 months ago

VasasA commented 6 months ago

PHPExcel library is no longer being supported. @bugfolder suggested a long-term solution: "Create a PHPSpreadsheet module (based on https://github.com/PHPOffice/PhpSpreadsheet, the successor to PHPExcel) for PHP versions 8.0+. Maybe follow the migration from PHPExcel guide to migrate PHPExcel module to the new module (which I would suggest warrants a new module name, phpspreadsheet)."

AlexHoebart-ICPDR commented 4 months ago

Hi, are you working on this? I also need XLSX import and export in a Backdrop project (migration from Drupal 7).

I was using the PHPExcel module in D7 already with the following patch which replaced the library with PhpSpreadsheet and worked well for me: https://www.drupal.org/project/phpexcel/issues/3016486 I'm willing to implement this in Backdrop but was wondering if it should be included in this project or a new project as you suggest. The more recent module versions in Drupal also use PhpSpreadsheet without changing the name of the module. On the other hand, there is an additional module in D7 where the change of library was also reflected in change of module name: https://www.drupal.org/project/views_data_export_phpspreadsheet. So, there are two different approaches for naming in Drupal.

I need both modules and will work on this. Another related issue is the way of inclusion of the library in Drupal vs. Backdrop. I assume that in Backdrop, the migrated views_data_export_phpspreadsheet module should depend on this (or a new PhpSpreadsheet module) which already includes the library. So again, the naming decision would be important.

I would appreciate any recommendations on this.

VasasA commented 4 months ago

@AlexHoebart-ICPDR We aren't working on it. The name "phpspreadsheet" is already taken by the "PHP Spreadsheet" project. So I think the patched PHPExcel (with PhpSpreadsheet library) should be included in a new Backrop project. For example: "spreadsheet" I note that the "PHP Spreadsheet" project will be difficult to port to Backrop, because it does not have a D7 version. Fortunately, the "Data export phpspreadsheet" module has a D7 version, so it can be easily ported to Backdrop. I think the name of the project should be "views_data_export_phpspreadsheet". One of its dependencies is the "Views Data Export" module is already ported. The other dependency will be the new project that contains the library. What do you think @herbdool, @bugfolder and @klonos ?

AlexHoebart-ICPDR commented 3 months ago

I looked shortly into the D7 module "PHP Spreadsheet" project - it only installs the library, nothing else. So, actually it is not difficult to port, but this PHPExcel module does more.

Another issue of concern is the size of the PhpSpreadsheet library: it needs to have a lot of dependencies installed with composer which result in 198MB of files. Does it make sense to package this with the module? BTW, I started porting views_data_export_phpspreadsheet, and have it roughly working, but not in batch mode and I don't understand what is going on (there is only an error in the library not the module). Maybe I consider also other libraries, for example I found that one which looks promising: https://github.com/aVadim483/fast-excel-writer (reader also available).

What do you think?

VasasA commented 3 months ago

The large size may be a problem for some users. It is probably not possible to reduce the size to keep the module functional. And Backdrop should work without Composer. But it is important that the "phpspreadsheet" module in Backdrop uses the same library as the Drupal "phpspreadsheet" module. It would be useful to create other modules with a smaller library than FastExcelWriter. So users would have a choice if the "phpspreadsheet" module is too big. About error of batch mode: Please see the chat of Backdrop. Maybe there will be a knowledgeable expert there.

laryn commented 3 months ago

Thinking out loud here, but if the size is too much to bundle within this module directly for everyone, you could maybe make a wrapper module that bundles the library and then add support for Composer Manager in this module. So the dependency would be soft: Composer Manager OR the wrapper module that bundles the library directly.