Jump to content

Class not found error


Kiwi Chris
 Share

Recommended Posts

I'm having an odd error similar to this:

I'm running WAMP on Windows 10, with Processwire, and get an internal server error trying to access either the front end or admin.

Checking my logs I find:

Error:     Class 'ProcessWire\PaymentModule' not found (line 3 of ...\processwire\site\modules\PaymentInvoice\PaymentInvoice.module)

The PaymentModule classs definitely exists, and hasn't been modified, and is namespaced.

The other thing I've noticed, is in the modules.txt log usually modules are installed via the site admin, however just before I started getting the error, I see a reference to a new module being installed via access to a frontend page via the following code.

$checkout = $modules->get("PadOnePageCheckout");
$checkout->setShippingModule("ShippingFixed"); 
$checkout->setPaymentModule("PaymentStripe"); // This module was not installed at the point the page was viewed, triggering the module to install.

 

Normally, following module installation, there is an entry in modules.txt saying Saved module info caches.

In this case there is no entry for this. The module that installed via the front-end extends the module in question that is supposedly missing.

Before the whole site went down, I noticed that the PaymentStripe module was not showing as installable or installed modules, in admin, however it is not this module that is claimed to be missing, but PaymentModule which it extends, and it is another payment module, PaymentInvoice that generates the error.

The site was working, although PaymentStripe wasn't showing up in the modules list, until suddenly everything stopped.

I'm using the premium Padloper shopping cart package, however I understand payment modules can be used independently of Padloper, and I'm not sure the issue actually relates to Padloper directly.

 

Link to comment
Share on other sites

Further development: I tried deleting the module that said that it couldn't find Payment Module.

That solved that error, but now AllInOneMinify module is giving a similar error saying that it can't locate a class that it depends on, even though nothing has changed.

Other sites on the same development server are working fine.

This has certainly shaken my confidence a bit in the robustness of Processwire, if seemingly at random, it starts throwing out errors about a whole range of supposedly missing classes that are definitely there, and it seems a bit random, as why does it report certain classes missing but not others?

Link to comment
Share on other sites

 

On 7/11/2018 at 1:46 AM, Kiwi Chris said:

Error:     Class 'ProcessWire\PaymentModule' not found (line 3 of ...\processwire\site\modules\PaymentInvoice\PaymentInvoice.module)

Are you sure that all Padloper's modules come from the PW3 Github branch and are namespaced as you say ?? You should double check your modules's files and templates using those modules..

 

14 hours ago, Kiwi Chris said:

This has certainly shaken my confidence a bit in the robustness of Processwire

It has nothing to do with ProcessWire's core. The robustness of ProcessWire can be broken by third-party module! or I want to say, the developer itself! thats all ✌️

 

Edit:

Also, AIOM+ look not officially supported for PW3, and it look like issues can happen depending the PHP version you are using. Consider using @ryan new version of ProCache.

More infos there:

 

  • Like 1
Link to comment
Share on other sites

9 hours ago, flydev said:

 

Are you sure that all Padloper's modules come from the PW3 Github branch and are namespaced as you say ?? You should double check your modules's files and templates using those modules..

 

 

It has nothing to do with ProcessWire's core. The robustness of ProcessWire can be broken by third-party module! or I want to say, the developer itself! thats all ✌️

 

Edit:

Also, AIOM+ look not officially supported for PW3, and it look like issues can happen depending the PHP version you are using. Consider using @ryan new version of ProCache.

More infos there:

 

I've managed to resolve the problem.

I actually still think the issue might be a core ProcessWire one, but at least I know how to fix it now.

Yes, I'm using the PW3 branch of Padloper, and it's working fine on other sites on my WAMP setup.

I'm using AIOM+ on many sites with PW3 and it's working fine on all the others.

I tried manually deleting all the entries in the cache table in phpMySQL and that allowed me to get into the site admin again temporarily, although it gave some notification about some modules that actually are present not being installed.

I went to modules, and did a refresh, and the error came back.

One thing I noticed that I wonder about, but don't know enough about how Processwire handles loading modules, is looking at the Modules.site/modules/ entry in the cache table, the modules seem to be listed in alphabetical order, and the offending module that is generating the error is listed before the module that it depends on, which it claims can't be found.

I'd hope this shouldn't matter, as it could have serious implications for module naming, as the offending module was working previously, but it seems it does.

I manually edited the order of the modules listed in the cache entry via phpMySQL, and the error went away.

I've tracked down the issue with AIOM+ I think. There was a namespace conflct in that a reference to a root PHP class was picking up the ProcessWire namespace and obviously not working. I think I must have added a namespace statement to the module so that the module compiler didn't have to do it, but forgot to check any possible conflicts. The good news is AIOM+ works fine without namespaces in Processwire 3.x

I think the AIOM+ problem might have actually been a red-herring with me trying to add namespaces to everything to try to get the first error to go away.

The real culprit here is that if the Modules.site/modules/ gets regenerated somehow, it seems it can potentially break a site, as it will add modules in alphanumeric order, and if a module depends on another one that comes later in the sort order, then the class will not be found. This can be fixed with careful naming of modules so that a module that has dependencies will always be listed after any dependencies, so in the case of PaymentInvoice, since it depends on PaymentModule, it probably should have been called PaymentModuleInvoice which would ensure that regenerating the modules cache would always load it after PaymentModule.

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

  • 3 months later...
  • 1 month later...
  • 7 months later...
  • 3 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...