Fatal error: Cannot redeclare password_policy_features_export_options()

Thanks for reporting this. Looked at the code and didn't see anything that should cause it. The only reference to password_policy.features.inc is in password_policy.module:password_policy_features_api(). Looking at the documentation on how to integrate with Features, that seems correct.

What version of Password Policy were you updating from? I tested several update paths to 7.x-1.14 and never saw this. Features was installed/enabled.

Does this error persist for you, or did it occur once and then not again? (Would clearing Drupal cache resolve it?)

Upgrading from 1.5 to 1.14

Appears to be an issue with the ctools cache. You can't clear Drupal cache when this issue is happening because the error just shuts the whole site down.

You can fix it by temporarily renaming password_policy/password_policy.features.inc to something else, clearing cache, and then putting the file back.

I unsuccessfully tried to reproduce this.
1. Installed Drupal 7.56.
2. Installed latest Features, Ctools.
3. Installed Password Policy 7.x-1.5.
4. Browsed to Features configuration pages. (Just to execute some Features code.)
5. Upgraded Password Policy to 7.x-1.14.
6. Browsed to another page on site. No error observed. No error in logs.

Any idea what might be different for me? If I can reproduce this, I can probably get to the bottom of it.

Why do you think Ctools is involved? Password Policy 7.x-1.x does not use Ctools, and Ctools is not a dependency of Features.

Also, how did you upgrade Password Policy? Using Drush (which commands?) or by manually downloading/extracting then running update.php? Just to rule out differences in my upgrade process. Thanks.

Would need more information to be able to make headway on this. It could be an issue with sites that is unrelated to Password Policy.

Hello,
I reproduce the problem.

it seems that php reads the code first in the module features from /sites/all/modules/contrib/features/includes/features.ctools.inc(32).
So like the function password_policy_features_export_options() does not exist yet, features.ctools.inc create the function in php registry or something ...
So when php read after the code form password_policy, the function already exist ...

I keep finding a solution .... but if anybody can advised me

Thank you

chanac_hares,

Could you please provide me some information to help me reproduce the problem?

- How did you upgrade to 7.x-1.14? Using Drush or via the website?
- Which version of Password Policy did you upgrade from?
- Which version of Features are you using?

Once I can reproduce this error, I can fix it.

I posted a modest $30 bounty for this issue on Bountysource:
https://www.bountysource.com/issues/51512407-fatal-error-cannot-redeclar...

Would want a way to reproduce the problem and a patch that fixes it.

AohRveTPV,

Here is the list of all my attempts

• Clear all cache from backOffice
• Clear all cache from drush cc all
• truncate all cache tables directly from database server
• try à registry rebuilf with help of registre_rebuild php script available here

But, None of these attempts had the desired effect ...

I finally solved my problem by adding the two following lines in the registry_rebuild script.

db_truncate('registry')->execute();
db_truncate('registry_file')->execute();

With empty "registry" and "registry_file" tables , the registry_rebuild.php script works like a charm ...

Regards

Thanks, chanac_hares, that is a good clue and workaround for people experiencing this problem.

I made another effort at reproducing it but was unsuccessful.

More information is needed to fix this bug. I would like any of the following:
- Steps to reproduce (of course).
- A full copy of a site having this problem.
- A list of modules installed on a site having this problem and their versions.
- The PHP version of a site having this problem.
- A list of any non-default Features configuration for a site having this problem.
- Any details about how you ran into the problem. (What version of Password Policy did you update from, how did you update Password Policy (drush or through the web UI), when did you first see the problem, etc.)

I think if multiple people share such information we might be able to find the common denominator. Or if someone can share their code and database for an entire site having this problem, I'll get to the bottom of it for sure. Thanks!

I'm taking the $30 bounty off the project page, but the bounty is still active. Thanks.

I have the same problem.
I had version 7.x-2.0-alpha7 working, but I tried to install with drush the release 7.x-1.15 without success.

Actually, the installation was done without errors, but once I tried to clear the cache......

1. The command "drush cc all" results in the following error:

PHP Fatal error: Cannot redeclare password_policy_features_export_options() (previously declared in ..../drupal/sites/all/modules/features/includes/features.ctools.inc(32) : eval()'d code:1) in ..../drupal/sites/all/modules/password_policy/password_policy.features.inc on line 14

Drush command terminated abnormally due to an unrecoverable error.

2. The web site doesn't work - "The web site" currently is under maintenance.
The website encountered an unexpected error. Please try again later.

Current PHP version on the server: 5.6.35
Features: 7.x-2.10
CTool: 7.x-1.14

tandim,

Thanks for reporting the problem and sharing some of your server info.

If I can reproduce this locally, I can fix it. If providing a copy of your broken site is possible, I should be able to reproduce it and fix it. But I realize most sites have private or proprietary information that would be hard to sanitize, and that is not possible.

To clarify, did you upgrade from 7.x-1.14 or install 7.x-1.15 anew?

Or did you disable 7.x-2.0-alpha7, uninstall 7.x-2.0-alpha7, then install 7.x-1.15?

Did you use Drush for all the disabling/uninstalling/installing?

AohRveTPV,

Thank you for the answer!

Unfortunatly, as you supposed, I am not able to give you a copy of the broken web site :(

I had 7.x-2.0-alpha7 working without problems. It was installed from the person before me. I just wanted to replace it with an available stable version, which is 7.x-1.15. I did not disable or uninstall the old version. I just replaced the module with the new version (and updating in the make.yml file) and used "drush make" to build the web site with the new version of the module....This is the instruction given from the web site builder....
Anyway, maybe exactly there is the problem....maybe something from the old version remains in the db and make conflicts....and maybe I should disable/uninstall first the old module and then install the new version clearly....I will try and let you know...thanks!

By the way, I tried also drush updatedb and it results the same error....

Definitly it is something wrong written and managed in the DB....maybe 02-version write something more in the DB, which 1.15-version doesn't clear and/or update...and it becomes some conflict....I don't know...

I tried to fix the problem by building again the web site with my previous version (7.x-2.0-alpha7) by drush make...but after I did the command I tried "drush cc all" and it gave me the error:

Fatal error: Class 'PasswordPolicy' not found in ..../drupal/sites/all/modules/password_policy/password_policy.module on line 202

Also the web site still doesn't work and this time gives white screen with the error:

Fatal error: Class 'PasswordPolicy' not found in ..../drupal/sites/all/modules/password_policy/password_policy.module on line 202

I used db backup to restore the db and the web site start working again...until I tried to clear the cache.....I rebuild the web site with the 02 version....nothing..the web site again broked...

tandim,

When switching between the 7.x-1.x and 7.x-2.x branches, you must uninstall the current branch of the module, then install the new branch. Uninstalling removes database entries associated with the module.

So to switch from 7.x-1.x to 7.x-2.x:
1. drush pm-disable password_policy
2. drush pm-uninstall password_policy
3. Remove password_policy 7.x-1.x module directory.
4. drush pm-download password_policy-7.x-2.0-alpha7
5. drush pm-enable password_policy

The fatal errors in your last comment are due to not uninstalling the prior installation of the module.

hi AohRveTPV,

Thank you. You were right. Once I uninstalled the old version (password_policy-7.x-2.0-alpha7) and I installed the new version (7.x-1.15) , everythigng was ok, and seems working normal. There is not anymore presented the error which I reported initially.

Of course, I had to uninstall also password change tab and disable the modules which require the password_policy module.

Since the UI for configuration of this module is quite different, I was wondering if a stable version of password_policy-7.x-2.0 will be releases soon?

Since the UI for configuration of this module is quite different, I was wondering if a stable version of password_policy-7.x-2.0 will be releases soon?

Probably not. 7.x-2.x is still in alpha. Next would probably be beta releases. #2331599: 2.0 release roadmap? tries to list some issues that need to be resolved before a stable release, but a plan hasn't been developed.

My personal focus is on fixing known bugs in 7.x-1.x. But I'd be glad to do a beta release of 7.x-2.x once the criteria for a beta release are met. drupal.org has guidelines for beta vs. alpha releases.

I'm not sure it helps to repeat the problem, but here's my experience:

1. Using password_policy 7.x-1.9 since 2016.
2. Patched password_policy for security issue, but otherwise stayed on 7.x-1.9
3. Using Features 7.x-2.10 since ~2016.
4. Upgraded to 7.x-1.15

On one site I manage, this process led to the problem "Cannot redeclare password_policy_features_revert()" and after clearing caches, the issue seemed to be resolved by doing a registry rebuild: https://www.drupal.org/project/registry_rebuild

On a second site, clearing caches ("all" cache and then visiting the admin > features page) seemed to fix the problem. But later after clearing cache via "drush cc all" the problem came back. On the second site, we moved all of the hook implementations from password_policy.features.inc into password_policy.module

I believe it's considered ideal to put all hook implementations in the .module since it guarantees they get loaded early in the Drupal bootstrap. Moving to active and adjusting the title to reflect that idea.

greggles,

I looked and Password Policy is doing it the same way as a couple other popular modules (Variable, Ubercart): The hook_features_api() implementation is in the .module file, and the Features hooks are in the .features.inc.

I did, however, spot one subtle bug. I wonder if it could be causing a problem. Maybe unrelated. In password_policy_features_api():

'features_source' => TRUE,

should be:

'feature_source' => TRUE,

per Features module features.api.php.

Interestingly, the Variable module also spells it as "features_source".

I think if we are doing things the same way as other popular modules with regards to Features hook placements, that can't be the cause of this bug, else it'd be seen in those other modules.

Nevermind, the Features code handles both "feature_source" and "features_source". Apparently the documentation erroneously had "features_source" at one point, so they kept support for both keys.

I'll change it to "feature_source" though to avoid any future confusion.

So, I'm back to having no hypotheses on this problem. I'll try again to reproduce it based on greggles' post.

I delved into the code and now have a hypothesis on why this is happening:

Password Policy used to have an incomplete implementation of the Ctools Export API. It was possible to export password policies but not import them. I removed that implementation (#2401787: Remove Features export while Features import is not available), and the removal was released with 7.x-1.10 I believe.

The 'export' schema keys from that implementation cause features.ctools.inc to define its own functions like password_policy_features_export_options(). Since schemas can be loaded from cache, it is possible after upgrading to 7.x-1.15 that the old, cached schemas will cause features.ctools.inc to define those functions, and password_policy.features.inc will subsequently try to re-define the same functions.

So I think the fix may be just to clear the schema cache in a hook_update_N() function, to ensure the old schemas with the 'export' keys aren't used.

I'll try to reproduce the problem based on this hypothesis. If I can reproduce it, implement/test the schema-cache-clearing fix...

Does this seem plausible? Any better ideas of how to fix? Thanks.

Procedure to reliably reproduce these errors:
1. Start from a site where Ctools is installed, but Features and Password Policy are uninstalled.
2. Install Features 7.x-2.10. (Do not do anything else--it is important that the Features cache does not get set.)
3. Install Password Policy 7.x-1.9.
4. Visit the site front page. (This is necessary to set the Schema cache.)
5. Install Password Policy 7.x-1.15 and run database updates.

Clears schema cache in update function. Specifically, clears all cache entries with ids beginning with "schema".

Seems to prevent this problem, provided that database updates are run upon update, per proper module update procedure.

This problem should also be fixable by clearing the schema cache using drush cache-clear all or similar, as suggested in #3 and #22.

Once the cache of the old Password Policy <=7.x-1.9 schema is cleared, this problem should never occur again.

Seems good to me. Thanks for your continued work on this hard-to-debug problem!

Thanks to all who reported the bug and helped determine its cause.