Empty response after working with modules

[Deltanic]

Hello,

After working with some modules ProcessWire suddenly stopped working. It's not sending back any data to the browser. No error log, no debug, no PHP errors, nothing. 

I've been trying to debug the problem, and somewhere in the load() method in wire/core/Modules.php everything goes wrong. I'm unable to find the exact clause though.

We have even reverted all code (both from the site and from PW) to a week old, at the time working backup. However, even this does not solve the issue so we suspect there is something wrong in the database. The problem is I don't know where to look.

The controlpanel does not work either.

We are running ProcessWire 2.5.

Is there anything I could to to solve this issue?

[kongondo]

Hi Deltanic,

Welcome to the forums and sorry to hear about your troubles.

There's a useful debug guide here: http://processwire.com/docs/tutorials/troubleshooting-guide/

Could you also list the 'after working with some modules' modules?

Even with turning 'debugmode' on (true) you still don't get any errors? What about Apache errors? PHP and MySQL versions?

[Deltanic]

There's a useful debug guide here: http://processwire.com/docs/tutorials/troubleshooting-guide/

Unfortunately this is not an htaccess issue. None of these steps seemed to help.

Could you also list the 'after working with some modules' modules?

Well, I was busy with a shopping cart module: http://modules.processwire.com/modules/shopping-cart/

It had to be slightly altered to work with some payment service we use. For this, I added a .module file to extend functionality. This worked fine. After that I basically made a copy of that .module file, and slightly altered it (so no duplicate class/filenames or whatsoever). Thats where things went down.

Even with turning 'debugmode' on (true) you still don't get any errors? What about Apache errors? PHP and MySQL versions?

Yes, debug is on. PHP: 5.3.26, MySQL: 5.5.20. Apache logs tell nothing useful. The error log is empty (apart from some 404's from a few days earlier) and the access log has nothing useful either.

We just reverted the database to the one of a week old, which seems to work. So it seems to be an issue with the modules. Still curious to know what causes this, to prevent it the next time. Or better yet, how to fix the up to date database. Reverting the database is quite a big deal, considering the work that has been done the past week.

[kongondo]

Are you saying then that your custom module file (the shopping cart) is working with your backed-up database? What I am trying to get at is whether you have definitely isolated the issue to the database and not something to do with your module...I am assuming that you did not alter any PW core files and db tables...(you say you reverted all code both from the site and from PW)

[adrian]

If some code from a module that you are developing (or one from someone else), breaks your site again, you can uninstall it by putting this code in a template file and loading a page with that template:

$modules->uninstall("ModuleClassName");

If that still doesn't work for some reason, delete the .module file from your modules directory. If still no luck, go into PHPMyAdmin and delete the row for the module from the modules DB table.

Following those steps in order should remove all remnants of a module that is causing problems.

Of course that won't reverse any changes that the module may made to other DB tables while it was installed, but this is rare for most modules, so not likely an issue.

[Deltanic]

Are you saying then that your custom module file (the shopping cart) is working with your backed-up database? What I am trying to get at is whether you have definitely isolated the issue to the database and not something to do with your module...I am assuming that you did not alter any PW core files and db tables...(you say you reverted all code both from the site and from PW)

It's clearly the module where things went mad. Adding the first one was fine, the second one caused the problem. The problem was however in the database. The caches table seemed to be corrupted, having empty JSON strings.

Yes, we reverted PW as well. But this was just to assure no one else could've edited the core (which would be very stupid). There were no alterations in the core.

If some code from a module that you are developing (or one from someone else), breaks your site again, you can uninstall it by putting this code in a template file and loading a page with that template:

$modules->uninstall("ModuleClassName");

If that still doesn't work for some reason, delete the .module file from your modules directory. If still no luck, go into PHPMyAdmin and delete the row for the module from the modules DB table.

Following those steps in order should remove all remnants of a module that is causing problems.

Of course that won't reverse any changes that the module may made to other DB tables while it was installed, but this is rare for most modules, so not likely an issue.

The templates are never loaded. I deleted the .module files, and the corresponding rows in the database without luck. The error was somewhere in the Modules::load() method, but I don't know exactly what. Even after removing the modules.

So it looks like the caches were corrupted. This is strange though, because I also disabled dbCache. This makes me still unsure what caused the issue, and doubtful if I should try adding the module again (and finish what I was doing). Is there a way to ensure I won't get this issue again? Could I have messed up something myself, which I shouldn't do the next time?

From the docs:

•  Login to your ProcessWire admin, click to the Modules tab and click the module name that you want to uninstall. Check the box to uninstall and click submit.
• It is now safe to remove the module's files from /site/modules/ if you want to.

I renamed a module before even installing it (So essentially "removing" for a system that is not aware of filechanges). Could that have been it?

[Soma]

Without knowing what you did its not possible to say much without seeing the module. Can you post the modules in question?

[Deltanic]

I managed to reproduce the problem with steps. 

1. Create a module (or use an existing one and skip to step 3)
2. Refresh modules in the controlpanel so PW finds the module.
3. Give the module an error, in my case, an unimplemented abstract method.
4. Refresh the control panel.
5. Get the error message.
6. Fix the error.
7. Refresh again.

And witness PW not sending any data.

More specifically, my steps, performed in the shopping cart module:

1. Edit PaymentAbstract, add new abstract methods.
2. Forget to update PaymentExample.module.
3. PW notifies me about the issue.
4. Fix the issue.
5. Refresh, and PW stopped working.

Code:

- Edited PaymentAbstract.php

- MollieExtension.php - Mollie can be found here.

- Added PaymentIdeal.php (accidentally named it .php instead of .module)

- Edited PaymentInvoice.module

And again the cache got corrupted. Emptying cache does not solve it, we had to revert to an older cache.

[Soma]

I tried to reproduce here and no luck. I fix error and everything works fine.

I'm working with lots of modules since a long time and also got errors and stuff, but never actually something that would stop PW working after fixing it.

Edit: usually when something strange, deleting /assets/cache/ files does clean things, or a module "refresh" which does the same.

I think $config->dbCache isn't something that has to do with module and other caches, it's for queries. PW has introduced (2.5 or earlier) some sort of cache I think as there's a table "cache", I think that get's cleaned on a module refresh but not sure. Anyway nothing to do with dbCache setting (but could be wrong)

[Deltanic]

Unfortunately, deleting the cache did not have any effect. So far I've been unable to find the cause of all this, but since I did manage to get everything working again, I'm not going to bother myself with this issue any longer. Next time I'm gonna be a bit more careful, I guess