Hi Christian,
I deactivated Give and indeed the site is blazing fast now. Keep in mind that some awkward issues can come up on the staging site because of SSL, plugin licenses, etc. So in the meantime, please continue troubleshooting without activating Give.
Thanks,
Nadav
Hi Christian,
Been doing some more research on the staging site to help us zoom in on the issues a little more. Here are my findings:
1. With ONLY Toolset (full suite) and WPML (full suite) on, I am still unable to get to edit images in the media library. When WPML plugins are deactivated, I am able to edit images. So your plugin suites seem to have a compatibility issue between themselves. BUT - When WPML is on, and I deactivate Access only, I can edit the images.
2. A new issue that AICF staff found is that they can't remove featured images from Artists. It's even worse in Events, Posts and Newsletters where you can't even see a featured image in the backend (see screenshot). On staging, this issue is present as well with ONLY Toolset+WPML activated, as well as with Toolset as the only set of plugins activated. It would be impossible to test without Toolset on as Types is what generates some the CPTs.
3. Then I tried activating plugins one by one. Knowing that Give is a problematic plugin in staging, I went ahead and activate it anyway to try some things out. I went to Toolset Access Control and whoop: I got that broken Access screen again (see screenshot). So: Access and Give are conflicting. The question is, whose "fault" is it? Please help me investigate this as Give is a crucial plugin for our site (same as Toolset). Note: even when WPML is deactivated, this issue is present.
4. Tag Artists feature (as mentioned in the other thread) still doesn't work as it used to. This is a very important feature and I truly believe this has something to do with changes in Toolset, not in our code (as we haven't changed the code for this feature and it simply cycling through all artists – but seemingly with limited access).
Thanks,
Nadav
3. ...So: Access and Give are conflicting.
I agree with your assessment here, this seems to be the problem with the Access Control screen. In my local testing, I am unable to replicate this issue with Give 2.0.4. When I test on your staging site, I'm shown this error at the top of the screen:
Give needs to upgrade the database but cannot because AJAX does not appear accessible. This could be because your website is password protected, in maintenance mode, or has a specific hosting configuration or plugin active that is preventing access.
The link points here: hidden link
Give’s upgrade system relies on admin-ajax.php to receive update progress reports from the server. It is a very important file. If it is inaccessible, it is very likely that Give will not behave as expected.
I don't see the same issue in my local testing, so I'm curious if this could be part of the problem. Can you get this error resolved?
1. ...I am still unable to get to edit images in the media library.
2. A new issue that AICF staff found is that they can't remove featured images from Artists.
Thanks for adding a summary of issues here. I will address issue 3 in this ticket, and we have a separate ticket already for issue 4. Please create separate tickets for 1 and 2 so we can investigate these problems as soon as possible.
The Give AJAX error message you are encountering is only happening because we're on staging. It's not appearing on the live site. Please advise what we can do to troubleshoot this given this roadblock.
As far as #1 & #2, opening tickets in a few minutes.
Thanks,
Nadav
Please advise what we can do to troubleshoot this given this roadblock.
Ask the Give plugin authors for assistance. Surely they offer a way to test updates in a development environment before going straight to production. Hopefully there's just a configuration that allows you to allow access for a different domain, but I have no idea how their software works, or what happens when the DB is updated.
The next steps depend on the result of the database update mentioned in the message above. If the Access Control screen is not fixed, then I need to be able to recreate this conflict somehow in a local environment, while running the latest versions of all plugins. I'm currently unable to do that, so we need to come up with a working approach.
The statement you're seeing from them is only because we're on staging. There is no real need for a database upgrade since on the live site it doesn't request that. Only since moving this to staging this started happening. I just contacted Flywheel to see if maybe they can remove privacy mode etc so that it starts working on staging. I'll keep you posted.
Okay thanks, my concern was that production's database was updated but staging's database was not...but if this staging environment was created after the production's database was updated to work with Give's latest version, then it should not be a problem. Those updates would have been pulled down to staging when the environment was created. In that case, we can ignore that error. I'll try to investigate with the DB backup provided here: https://toolset.com/forums/topic/no_privilege-error-when-trying-to-edit-images/#post-618389
FYI: Flywheel agreed to remove privacy mode on staging - at least for a while. So that AJAX error message is gone and the site works at a reasonable speed even with Give activated.
Thanks, I was able to reproduce the Access screen issue with the SQL dump you provided in another ticket. I am escalating this to my 2nd tier team for further investigation. Please stand by and I will update you as soon as I have information to share.
I have a patch file available from our developers that resolves the Access screen issue while the Give plugin is active:
hidden link
Please extract the patched Helper.php file into the directory wp-content/plugins/types-access/includes/ and let me know the results.
Hi, it worked. What was the nature of the conflict?
Should I just keep the new helper file there and the patch will be included in the next version of Access?
This didn't seem to help some other open issues that we have, so I guess I was wrong about Access blocking certain features (or maybe it still is?):
1. #no_privilege links in media library for Developer and Senior Staff users (doesn't seem to be an issue for Admin [which isn't in use] or regular Staff.
2. Backend errors and bizarreness with removing and re-adding featured images.
3. Problem with the Tag Artists feature where all of a sudden a user can only find themselves, and not the entire list of artist in the dropdown/search on that page.
(all issues have their tickets of course)
Hi, it worked. What was the nature of the conflict?
This condition appears to result in the error:
if ( ( isset( $post->post_type ) && $post->post_type != 'attachment' )
The problem is, when the previous expression is true, the following line runs and causes the issue:
TAccess_Loader::loadAsset( 'STYLE/wpcf-access-post', 'wpcf-access' );
Activating Give, or one of a couple of other plugins, caused this condition to return a false positive.
Should I just keep the new helper file there and the patch will be included in the next version of Access?
Yes, keep the helper file for now, and the permanent fix will be included in the next stable release of Access. If another patch must be placed in the same helper file between now and then, we can merge those changes together into the same helper file.
