I’m trying to use a Drupal 6.x website with the Sheetnode 6.x-1.8+8-dev module (it provides a way to create spreadsheets). The module is pretty cool and somewhat hairy to install, but I think it has some bugs (which isn’t unexpected)… I’m currently trying to use this module to export a spreadsheet I created from a Sheetnode-imported XLSX file (which I was only able to do after adjusting my.ini values revolving around execution time and max post size values). Each time I try to export it using the Sheetnode export feature, I get the following (nasty) error:
[INDENT]An error occurred. /projects/foobar/?q=batch&id=31&op=do { “status”: true, “percentage”: 100, “message”: “Exported 1 out of 1 sheets.\x3cbr/\x3eProcessed sheet \x3cem\x3eSheet1\x3c/em\x3e.” }
Warning: include_once(./includes/unicode.entities.inc) [function.include-once]: failed to open stream: No such file or directory in C:\www\projects\foobar\includes\unicode.inc on line 339
Warning: include_once() [function.include]: Failed opening ‘./includes/unicode.entities.inc’ for inclusion (include_path=‘.;C:\php\pear’) in C:\www\projects\foobar\includes\unicode.inc on line 339
Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, ‘php’, ‘%message in %file on line %line.’, ‘a:4:{s:6:\“%error\”;s:7:\“warning\”;s:8:\“%message\”;s:102:\“mysqli_query() [<a href=\‘function.mysqli-query\’>function.mysqli-query</a>]: MySQL server has gone away\”;s:5:\“%file\”;s:53:\“C:\\www\\projects\\foobar\\includes\\database.mysqli.inc\”;s:5:\“%line\”;i:114;}’, 3, ‘’, ‘http://localhost/projects/foobar/?q=batch&id=31&op=do’, ‘http://localhost/projects/foobar/?q=batch&op=start&id=31’, ‘127.0.0.1’, 1354290343) in C:\www\projects\foobar\includes\database.mysqli.inc on line 134
Warning: include_once(modules/dblog/dblog.admin.inc) [function.include-once]: failed to open stream: No such file or directory in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 367
Warning: include_once() [function.include]: Failed opening ‘modules/dblog/dblog.admin.inc’ for inclusion (include_path=‘.;C:\php\pear’) in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 367
Fatal error: Call to undefined function dblog_overview() in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 375
[/INDENT]
So far, I’ve been unsuccessful in completely understanding what’s going on with this and nobody over in the Drupal community seems to, either. I’ve also submitted a support ticket from the module creator, but not surprisingly, it’s been ignored. I was able to find a thread about something similar here, but I don’t think it completely applies because A.) I’m not using Devel, and B.) I’ve tried some of the suggested “fixes” in that thread. Nothing seems to fix it for me.
From everything I’ve read, people claim that this is fixed by increasing various my.ini values (i.e. - max_<whatever>, etc.) I’ve done this–I’ve even gone as far as increasing certain values upward to about 2048 M! Still no dice. I’ve even gone as far as set up a completely brand new Drupal 6.x sandbox with no other modules running–just those that this module needs. Everything works except the exporting feature, which is a deal breaker. (I’ll attach the test spreadsheet I’m trying to test with–it’s in the ZIP file and is very generic / basic.)
Here are the my.ini and php.ini values I’m running with:
In my.ini, I have the following:
- key_buffer = 384M
- max_allowed_packet = 1024M
- table_cache = 4096
- sort_buffer_size = 512K
- net_buffer_length = 512K
- read_buffer_size = 512K
- read_rnd_buffer_size = 512K
- myisam_sort_buffer_size = 64M
- basedir=C:/Program Files (x86)/wamp/bin/mysql/mysql5.5.16
- log-error=C:/Program Files (x86)/wamp/logs/mysql.log
- datadir=C:/Program Files (x86)/wamp/bin/mysql/mysql5.5.16/data
Every “myisamchk” parm is set for 512M (for whatever it’s worth).
In php.ini, I have the following:
- max_execution_time = 120
- max_input_time = 120
- memory_limit = 1024M
- post_max_size = 1024M
- mysql.cache_size = 2000
- mysql.connect_timeout = 120
As you can see, there shouldn’t be a problem with memory!
Here’s a list of the associated modules / libraries and where they reside:
- /sites/all/modules/sheetnode (version 6.x-1.8+8-dev)
- /sites/all/modules/sheetnode/socialcalc (latest version from Git)
- /sites/all/libraries/tcpdf (version 5.9.101)
- /sites/all/libraries/PHPExcel (version 1.7.8)
The problem is straightforward: I can’t export a spreadsheet to XLS or XLSX format using the Sheetnode export facilities. The process starts, but then bombs-out with that I provided above.
To me (and judging from everything I’ve read so far), it seems like the parsing process responsible for escaping special kinds of encoded characters might be inadvertently allowing some characters to slip through the validation checks, and in turn, causing a cascading issue of interpreting code in certain ways, which is causing all sorts of havoc with things (i.e. - screwing up values of things like inclusion paths as depicted by the fact that the unicode file above it claims it can’t find IS in fact where it should be–which makes no sense). In other words, it seems as if some characters that should be encoded a certain way are slipping through and essentially causing injection issues. But of course, I could be wrong.
I’ve looked at my PHP log and it just has what I posted above. So it’s not much help.
I just hope someone (ANYONE) has some useful feedback about this. How can I try to debug something like this? What methods or functions could / should I use and how / where? Should I just cut my losses and look for another solution? The ticket queue I’ve submitted a ticket to about this is basically useless and who am I to expect help for open-source stuff, right? After all, open-source = generosity, so I guess I should just be happy with what I have…
At any rate, if I’m unclear about anything or if I haven’t provided enough information, please let me know and I’ll try to clarify where necessary. I’d really love to be able to use this thing, but it’s becoming a time sink with little-to-no traction being made.