[Resolved] Fatal Error when activating Access

[Author]

Posts

[laurencea]

My last reply doesn't look private...

[laurencea]

How can I add my download link in private?

[Minesh]

I have set the next reply to private which means only you and I have access to it.

[Minesh]

With all in one migration plugin, it allows me to import a maximum 200 MB file and the file you shared is of more than 800MB. It will be great if you can share a duplicator package so I can install it on my localhost and debug this issue further.

[Beda]

I am taking this for now because I am handling another ticket with the same issue, and the issue seems old.

Can I ask:
1. Did you ever use Access before on this site/server?
2. If so, when did the issue start happening?
3. If not, can I ask if your server has eval() active, and what the status of zlib.output_compression is on the server?
You can get these informations from the Server Admin directly, by asking if eval() is active (it has to be, otherwise Toolset will not work) and wether zlib.output_compression is ON or OFF.

I will also download and install your duplicate tomorrow, and see if I can replicate this on my local install
The error is likely not reported to your error log because some thing blocks the writing to it (my tip goes to wordfence and over-secured settings)

I will know more once I test, if you could meanwhile provide me the additional details - these can also help narrow down the issue.

I will do my best to find the issue ASAP.

[laurencea]

Thanks guys.

I have not used Access on this server yet.
zlib and eval are not enabled. However, Types, Maps, and Views seem to work. Though it doesn't seem to register Geodirectory post types. Which is what I'm wanting to manage with with Access and Types.

Didn't add the package link here, because the reply isn't private.

[Beda]

Eval must be enabled, as elaborated here:
https://toolset.com/toolset-requirements/

Toolset maps does not register any post type, and Access neither, hence you could not "register a Geodirectory post type with it".
Post Types would be created by Toolset Types.

I have the package already, as you provided it to Minesh previously and we have methods to deploy that even it's "too big" for the free version.

I deployed it locally, and I can not activate Access, I get a fatal error message but no fatal error logged. Of course that is because the debug is turned off on the duplicate, so when turning it on, you'll see the error. Enabling debug is done like so:
https://codex.wordpress.org/Debugging_in_WordPress

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );

Then you'll see the error that breaks your site:

WordPress database error: [COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4']
CREATE TABLE wp_toolset_maps_address_cache ( address_passed varchar(190) NOT NULL, address varchar(255) NOT NULL, point point NOT NULL, PRIMARY KEY (address_passed) ) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8_general_ci

Note that on the duplicate Views IS ACTIVE, so I am not sure why it is not possible to activate it on your online site, given that is a copy of it, it should be active there.
It may be the same reason.

The error mentioned above a bit more dissected:

[25-Oct-2019 06:54:31 UTC] 
WordPress database error COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4' for query CREATE TABLE wp_toolset_maps_address_cache (
			address_passed varchar(190) NOT NULL, 
			address varchar(255) NOT NULL, 
			point point NOT NULL,
			PRIMARY KEY  (address_passed)
		) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8_general_ci made by require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('after_setup_theme'), WP_Hook->do_action, WP_Hook->apply_filters, Types_Main->after_setup_theme, Toolset_Common_Bootstrap::get_instance, Toolset_Common_Bootstrap->__construct, do_action('toolset_common_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, OTGS\Toolset\Maps\Bootstrap->initialize_classes, OTGS\Toolset\Maps\Controller\Troubleshooting\CacheUpdate->init, OTGS\Toolset\Maps\Controller\Cache\CreateDatabaseTable::run, dbDelta

It comes down to wp_postmeta table on your site using utf8_general_ci collation, which cannot use utf8mb4 character set.

Our code adjusts to different collations of wp_postmeta table when creating our table, but it doesn’t adjust to different character sets, because WP should always use utf8mb4 (in theory). So, collations which don’t support that character set can’t work.

There is a workaround, to run a SQL command:

alter table wp_postmeta convert to character set utf8mb4 collate utf8mb4_unicode_520_ci;

Of course, that could potentially break some other plugins, but chances for that are slim.
Our Developers will in future check in our code if the database is using utf8mb4 character set and compatible table collation.
The questions is: if it doesn't, do we just output a more informative error, or do we also adjust the character set and make everything "just work", even though that might cause other, hard to figure out problems later on? This is the reason why it was not yet resolved.
I have however asked for a professional handling of this issue and to prioritize this, because I see many tickets with this issue and no real solution.

That said, this is the reason your Maps do not work, but not the reason you cannot active Access.

That is because of another error:

[26-Oct-2019 07:55:14 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 131072 bytes) in /Applications/MAMP/htdocs/tssupp-3218/wp-content/plugins/mainwp-child/class/class-mainwp-child-wordfence.php on line 2658
[26-Oct-2019 07:55:14 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 81920 bytes) in /Applications/MAMP/htdocs/tssupp-3218/wp-includes/option.php on line 392

MainWP Child causes this issue but must not be directly culprit of it.

The memory may exhaust anywhere else already, and together with WordFence accidentally just is the one eating up the last bit.

Note, deactivating it, or even deactivating ALL plugins on your site and activating Access will STILL fail in fatal error, this time due to

[26-Oct-2019 08:01:54 UTC] PHP Warning:  Parameter 1 to NF_EmailTelemetry::update_metrics() expected to be a reference, value given in /Applications/MAMP/htdocs/tssupp-3218/wp-includes/class-wp-hook.php on line 286

AND

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in /Applications/MAMP/htdocs/tssupp-3218/wp-content/plugins/types-access/application/models/access_settings.php on line 48

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0

The FIRST error is immediately gone as soon your Custom Child Theme is deactivated.
We cannot debug child themes, hence I activated a native WordPress theme and the error is gone, however the memory exhaustion not.

So I replaced the entire Toolset with fresh copies from https://toolset.com/account/downloads/, which did not help.
Hence I deleted all plugins, which returns once again a fatal error due to another plugin

[26-Oct-2019 08:08:05 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function geodir_get_option() in /Applications/MAMP/htdocs/tssupp-3218/wp-content/plugins/geodir_ajax_duplicate_alert/uninstall.php:22
Stack trace:
#0 /Applications/MAMP/htdocs/tssupp-3218/wp-admin/includes/plugin.php(1192): include()
#1 /Applications/MAMP/htdocs/tssupp-3218/wp-admin/includes/plugin.php(934): uninstall_plugin('geodir_ajax_dup...')
#2 /Applications/MAMP/htdocs/tssupp-3218/wp-admin/includes/ajax-actions.php(4310): delete_plugins(Array)
#3 /Applications/MAMP/htdocs/tssupp-3218/wp-includes/class-wp-hook.php(286): wp_ajax_delete_plugin('')
#4 /Applications/MAMP/htdocs/tssupp-3218/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters('', Array)
#5 /Applications/MAMP/htdocs/tssupp-3218/wp-includes/plugin.php(465): WP_Hook->do_action(Array)
#6 /Applications/MAMP/htdocs/tssupp-3218/wp-admin/admin-ajax.php(173): do_action('wp_ajax_delete-...')
#7 {main}
  thrown in /Applications/MAMP/htdocs/tssupp-3218/wp-content/plugins/geodir_ajax_duplicate_alert/uninstall.php on line 22

I had to remove them manually and saw, that you had deleted all index.php files from the native WordPress folders, which is generally a bad idea, those are there for a reason.
I fully re-installed WordPress, with a clean Plugins and Themes folders, but still, the Access plugin can't be activated.

I checked the database and saw that the site seems to be from a Multisite, but the debug info you provided says it is not a multisite, as well there are many database tables missing that should be there in a Multisite.
Hence the site is at this point likely irrecoverably corrupt.
I don't know the precise history of this website but it does not seem a clean or fresh site, rather something older that was built upon in many layers.
Do you recall if the site was a multisite at some point?

Note that at this point I have no further options here in support, as the issue seems closely related to a database corruption.

I managed to slim down the duplicate you had provided so far to provide it to the Developers for further investigation, but I suspect this will require some edits in the Database directly.

As First step on your server you will have to activate Eval, and then correct the database collation issue.
Please let me know if this brings any solution to the issue (although as seen above, likely not)

Meanwhile I escalate this ticket to our 2nd Tier who will then inform the DEV next week and have a close look at the issue.

Thank you for your patience and understanding

[Beda]

I have one solution that you can try, but it's not a explanation as of why this happens, or something I can suggest as stable resolution, it's however solving the problem and could be applied, if you need to move on with development.

1. Backup your database
2. Login to MySQL and find the option called "wpcf-access-taxonomies"
3. Copy it's content to a safe location
4. Delete the option's content
5. Activate Toolset Access
6. Add the options content again to the database
7. Make sure everything works

Our Developer is investigating this but it is tricky to spot what is happening.
I will keep you in the loop, can you test above solution on your site after a backup?
I tested in on the copy of your site locally and it solved the issue.

[laurencea]

Ok, thanks. I'll give it a shot and report back..

[Beda]

OK.
Meanwhile our Developer also came up with the core reason of this issue, and added a (edge case) fix to the Access Plugin.
This will be eventually shipped in a future release, hence it should then not happen anymore even when these kind of edge cases happen (The technical reason are missing roles, but permissions set for such roles, hence Access rolling out in fatal errors of different types on activation).

The fix I provided above already worked on another users's site so I am highly confident it should work on yours too (and well, I tested in your duplicate as well 🙂 )

Remember to make a backup of your database first, this is important.

[laurencea]

Hi,
I received this email today, is this from your test site?

Your Site is Experiencing a Technical Issue
First, visit your website (hidden link) and check for any visible issues. Next, visit the page where the error was caught (hidden link) and check for any visible issues.

Error Details
=============
An error of type E_ERROR was caused in line 128 of the file /Applications/MAMP/htdocs/duplicator/wp-content/plugins/types-access/application/controllers/permissions_post_types.php. Error message: Uncaught Error: Call to undefined method OTGS\Toolset\Access\Models\Settings::is_object_valid() in /Applications/MAMP/htdocs/duplicator/wp-content/plugins/types-access/application/controllers/permissions_post_types.php:128
Stack trace:
#0 /Applications/MAMP/htdocs/duplicator/wp-includes/class-wp-hook.php(286): OTGS\Toolset\Access\Controllers\PermissionsPostTypes->registered_post_type_hook('post', Object(WP_Post_Type))
#1 /Applications/MAMP/htdocs/duplicator/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters('', Array)
#2 /Applications/MAMP/htdocs/duplicator/wp-includes/plugin.php(465): WP_Hook->do_action(Array)
#3 /Applications/MAMP/htdocs/duplicator/wp-includes/post.php(1377): do_action('registered_post...', 'post', Object(WP_Post_Type))
#4 /Applications/MAMP/htdocs/duplicator/wp-includes/post.php(40): register_post_type('post', Array)
#5 /Applications/MAMP/htdocs/duplicator/wp-includes/class-wp-hook.php(286): create_initial_post_types('')
#6 /Applications/MAMP/htdocs/duplicator/wp-includes/class-wp-

[Beda]

Yes, it seems to be. "Good" to know WordPress manages to send emails out of my Computer which is locked behind a firewall both for incoming and outgoing connection not explicitly allowed. I'll have to revise that.

The email was sent to you because saved in your Duplicate, which I did not change for testing purposes. In past this was never an issue, it seems to be now.
I will make it a standard workflow from now to immediately change that email as first thing when deploying duplicates, so users are not bothered by this.

My apologies about the email, and, good news:
https://toolset.com/errata/unknown-fatal-error-when-activating-toolset-access/

It has a patch that you can apply in case you need, or, you can simply wait for the next release.

[laurencea]

Thanks for verification. I'll check the patch and report back.

thanks!

[laurencea]

Looks like the patch worked fine. I am able to activate Access and it appears to be working.
Thank you!