A few days ago I had a particular problem, the Bean module that allows creating Blocks as configurable entities stopped working and no longer allowed me to manage the Block Types, the only thing it showed me was an error indicating that the element that was trying to be loaded It was not an object.
After several hours going through the Bean code , I reached the point where the module loaded the plugins and subsequently a verification was made to ensure that the 'BeanPlugin' Class existed, this is done in the ctools_plugin_get_class function , everything It was going in order, the plugin had the complete and well-structured definition, but in the end a final validation was done with the PHP class_exists function , and at this point the returned value was NULL, that is, the class was not registered.
The first thing that came to mind was to perform a registry cleanup using Registry Rebuild via Drush .
$ drush dl registry_rebuild
$ drush str
After performing the cleanup I was able to verify that it had no effect either, which left me with the only alternative of checking the Drupal Core to understand when it registered the classes and why “BeanPlugin” specifically was not available.
When installing a module, Drupal also identifies its files and makes a record of associated classes. This record is kept in the “registry” table. When searching in that table I noticed that the “BeanPlugin” class was not there, which indicated to me that the file containing it had not been parsed. This gave me two possibilities: either PHP had not identified the file in the folder or for some reason the class record had been lost after having parsed it on a previous occasion.
The first thing I did was to verify that the file was in the registry, to do this I checked the “registry_files” table, the records showed the file path which ruled out the first possibility and it was only possible that the class record had been lost in the “registry” table for some reason, the solution had to be for Drupal to do the parsing again and verify that on this occasion the class was registered.
The task was not going to be easy but I had to start so I based myself on the Registry Rebuild script to find the registration point of the classes and also understand why it did not work for me with Drush, the part that interested me began with the execution of the registry_rebuild function , which calls registry_update which in turn executes _registry_update , this last function does the work of identifying the module directories and parsing the .info files to identify the associated information and files, if we review the .info file of the Bean module we find the following line:
files[] = plugins/BeanPlugin.class.php
The above is indicating that this file is necessary for the module and therefore is a candidate to be parsed.
Continuing with the exploration we found within _registry_update a function that does the task of parsing the identified files, I am talking about _registry_parse_files which determines whether a file should be parsed or not based on the hash, this was when I understood what was happening. There was a conditional that said that if the file was already registered and the hash value had not changed, that is, the file had no modifications, it was not necessary to parse it again, that condition made a lot of sense, in case of enabling a new Drupal module I would not have to go through absolutely all the files again unless it was necessary, however that measure was affecting me because the file had not been modified and was also registered in the “registry_file” table, therefore I skipped it, now I understood the reason why with $drush rr it didn't work.
Once the problem was understood, the solution had to be simpler, I just had to remove the record from the file in the “registry_file” table and that was already a reason for it to be parsed again, to make sure I deleted the record from all the files related to the module in the “registry_file” table and ran it again.
$ drush str
Once finished I checked the registry table again and this time the class I needed was there. Later I tested the module again and everything worked perfectly!
This was not the first time this happened to me with the Bean module. The previous time I decided to uninstall the module because I didn't have much data, but in this case I couldn't do the same. I'm not sure if it's a problem with the module or some unintentional administrative action that caused it. I only know that it forced me to get to the bottom of the problem and better understand the logging system.
I hope that the explanation of this solution helps you understand how the registration of files and classes works in Drupal so that you have alternatives in similar cases.