I am trying to: create an archive page with a custom search form.
Link to a page where the issue can be seen: hidden link
I expected to see: A working parametric search form
Instead, I got: Periodically, all controls on the form stop working. Selecting any of the dropdowns no longer refreshes the results, the reset button (clear filters) does not do anything and sort order controls stop working.
This appears to be related to whenever I edit anything in the archive view then return to the archive at the front end and refresh the page.
I am on Siteground hosting using their SG Optimiser caching however purging the SG cache does not resolve the problem
The only thing that clears the problem is clearing the history of the page at the browser level. I have the same problem in both Chrome and Edge. I don't have other browsers installed but the fact this is happening in both suggests it's something other than a browser issue.
Obviously, now I've figured out the fix, I can clear my history each time but I don't want this to be an issue when the site goes live.
Okay I'm able to replicate this, and each time I see the following errors in the JavaScript console:
JQMIGRATE: Migrate is installed, version 1.4.1
wp-mediaelement.min.js:1 Uncaught TypeError: b(...).not(...).filter(...).mediaelementplayer is not a function
at HTMLDocument.a (wp-mediaelement.min.js:1)
at i (jquery.js:2)
at Object.fireWith [as resolveWith] (jquery.js:2)
at Function.ready (jquery.js:2)
at HTMLDocument.J (jquery.js:2)
a @ wp-mediaelement.min.js:1
i @ jquery.js:2
fireWith @ jquery.js:2
ready @ jquery.js:2
J @ jquery.js:2
mediaelement-migrate.min.js:1 Uncaught ReferenceError: mejs is not defined
at mediaelement-migrate.min.js:1
at mediaelement-migrate.min.js:1
(anonymous) @ mediaelement-migrate.min.js:1
(anonymous) @ mediaelement-migrate.min.js:1
Can you try these troubleshooting steps first?
- Temporarily activate a default theme like Twenty Nineteen, then deactivate all plugins except Types, Views, and Blocks. Test again. If the problem is resolved, reactivate your theme and other plugins one by one until the problem returns.
Thanks for spotting that Christian.
I have created a staging version of the site and changed the theme to TwentyNineteen and deactivated all plugins apart from the Toolset ones mentioned, as instructed.
Form works correctly even after making a change to the archive page.
Switched back to Astra theme as provided in the reference site my site is based on (Tours), made a change to the Archive page - all works OK.
I then started a process of activating each additional plugin starting with the other Toolset ones.
I ran into a problem when I activated Akismet so thought that was the culprit until I realised that that had been inactive in my live site.
So I then started to reactivate in my staging site only the plugins that were active in the live site, making a change to the archive page and refreshing at the frontend after each activation. If a plugin didn't break the form, I kept it active and continued down the list. If a plugin did break the form, I deactivated it again, cleared the history and moved on to the next plugin.
But there doesn't seem to be a single culprit - a long list of plugins seem to break the form when activated or if the form doesn't break immediately after activation, then as soon as I make a change to the archive design, the form breaks.
Equally there's no consistency. I decided to go back to square one with Astra theme and the basic Toolset plugins. Then I activated SG Optimiser. All ok. Then I activated Ultimate Addons for Gutenberg as this is an addon to the Astra theme. The form broke when I changed the archive design. So I wondered if it was a combo of the two plugins. I deactivated SG Optimiser and the form worked again after a page refresh. Then I reactivated SG Optimiser expecting my form to break again - but it didn't, neither after a page refresh or after editing the archive design again. But then when I did another page refresh - the form broke!!
So I'm at a complete loss as to the root cause - especially considering that mediaelement.js is for video and audio - neither of which are present on this page. I don't understand why the script is even running!
Okay if you approve, I can try to create a clone of your site with the Duplicator plugin and run some tests locally. If I'm able to replicate the problem I can ask my team to investigate further.
Yes that's fine with me Christian.
Let me know what you need if anything
I'm not able to replicate this consistently on my own local site. However, I do see several database errors in the logs. Do you have access to server logs for this site? If you're not familiar, I can show you how to activate them temporarily. Go in your wp-config.php file and look for
define('WP_DEBUG', false);
Change it to:
define('WP_DEBUG', true);
Then add these lines, just before it says 'stop editing here':
ini_set('log_errors',TRUE);
ini_set('error_reporting', E_ALL);
ini_set('error_log', dirname(__FILE__) . '/error_log.txt');
Try to replicate the error a few times. If any server-side errors are generated, this will create an error_log.txt file in your site's root directory. Please send me its contents. Once that is done, you can revert the changes you made to wp-config.php and delete the log file.
Hi Christian
I made the changes to start the error logging.
I went back to my Astra Theme and just Toolset plugins and ensured all was working.
Activated SG Optimiser and test firstly with a simple page refresh, then with making a change to the archive design and refreshing. All worked OK.
Activated GDPR Cookie Consent and repeated above steps. All worked OK.
Activated Ultimate Addons for Gutenberg and repeated above steps. Form worked after page refresh but broke after making a change to the archive design and refreshing.
Error log file shows the following:
[07-Jun-2019 06:48:59 UTC] PHP Notice: map_meta_cap was called incorrectly. The post type scheduled-action is not registered, so it may not be reliable to check the capability "read_post" against a post of that type. Please see Debugging in WordPress for more information. (This message was added in version 4.4.0.) in /home/whippetw/staging/2/wp-includes/functions.php on line 4773
[07-Jun-2019 06:48:59 UTC] PHP Notice: map_meta_cap was called incorrectly. The post type scheduled-action is not registered, so it may not be reliable to check the capability "edit_post" against a post of that type. Please see Debugging in WordPress for more information. (This message was added in version 4.4.0.) in /home/whippetw/staging/2/wp-includes/functions.php on line 4773
I then deleted the error log and deactivated Ultimate Addons for Gutenberg, cleared my history and reloaded the page to get the form working again. Then I reactivated the plugin again, the form broke as before but this time no error log was created.
Does this shed any light for you?
Hmm, the notice about map_meta_cap isn't anything that would be causing the issue we're seeing. I was hoping for more concrete information there. The errors I saw in my local logs could be attributed to the cloning process, so I'm not convinced they are related to your issue at all. The next things I would like you to try:
- Go to Toolset > Settings > Frontend Content and turn on Browser History management for AJAX pagination and custom searches. Refresh the archive and you'll see the URLs change each time you change a filter. I'd like to know if the filters are more resilient this way.
- Temporarily switch to "always show all values for inputs" in the Custom search settings. This reduces the computing load required to update the View, which may help prevent silent failures.
- Delete all the Query Filters, as well as the filter control shortcodes from the Search and Pagination panel. Recreate the filters using the controls in the Search and Pagination panel. The corresponding Query filters will be recreated automatically, which often resolves unexplained filter corruption issues.
- Or if the previous step sounds too drastic, we could try recreating the archive from scratch, but keeping the old archive as a backup.
Turning on Browser History management for AJAX pagination and custom searches didn't make a different - the same problem of as soon as I make a change and save the archive, the form breaks at the front end.
Temporarily switching to "always show all values for inputs" in the Custom search settings also didn't make a difference.
I've created a new archive - without any of the styling but using the Search and Pagination section to set up the filters, but that archive has the same problems as the old one. It works fine until a change is made and saved at the back end and the page refreshed at the front end, then the form stops working.
Using the reload button or pressing F5 doesn't fix the problem, it is only when doing Ctrl-F5 or going into the History and removing the page that way, that the form begins to work again.
Sorry I don't have better news for you Christian
Well if I can't reproduce this on my local environment, the next step is to try to reproduce it on a different environment where I still have the ability to monitor things. If it's okay with you, I would like to post a copy of the site on a different staging server where we can test it out together. Let me know if that's okay and I'll get started.
Sorry for the delay in replying Christian
Yes please do whatever is necessary to solve the problem.
The site is in the early development phase anyway
You have my permission to copy the site to a different staging environment.
I'm asking for assistance on this one, I am a bit stuck and can't pin down any one source of the problem. It's really inconsistent for me too. I'll let you know what I find out.
Hi Johanna, let me see if I can help here.
This should be a classic cache problem. When developing, often I find myself in this loop of cached scripts and styles (by the browser) where I believe my changes weren't pushed, or things fail because they were pushed in pieces (several save actions).
It gets a little worse when you use Layouts or other AJAXified save mechanisms because often (And we just solved an issue related to that for SG and other cache mechanisms) those cache software do not exclude our actions from their optimization, hence corrupting the actions and making them fail.
See this for reference: https://toolset.com/forums/topic/memcached-prevents-field-group-title-from-saving/, https://toolset.com/forums/topic/internal-field-group-title-not-saving/
In an active development site, this can happen, but likely it won't happen in a live site, as you will not be constantly making adjustments to the structure anymore - and publishing posts is something those cache plugins standardly exclude so no issue there on live sites.
Clients visiting your site will cache what you deliver them in the browser as well, that is true, but it should not affect them as you won't be changing the design that often as in a developed site.
What however is unclear is why - if all above is what's happening - disabling and cleaning the cache of SG would not solve this issue.
Additionally to that, I loaded your website today the first time ever and would have received all latest versions (not cached) - however immediately I see the JS error on the console:
Uncaught TypeError: b(...).not(...).filter(...).mediaelementplayer is not a function
at HTMLDocument.a (wp-mediaelement.min.js:1)
at i (jquery.js:2)
at Object.fireWith [as resolveWith] (jquery.js:2)
at Function.ready (jquery.js:2)
at HTMLDocument.J (jquery.js:2)
So, this should be easy to replicate elsewhere too, and since Christian has set up a sandbox for me of your site, I will work on that to see what I can find.
On the sandbox (access details in below private reply) I proceeded as follows:
1. Updated all software
2. Re-Installed WordPress (this is a non-intrusive process, in Dashboard > Updates)
3. Noticed the Archive in question has a broken filter. This filter will not be applied to Taxonomy Archives matching the filtered taxonomies: mockup-category, mockup-tag:
Select posts with taxonomy:
Mockup Categories slug in one of those set by the URL parameter wpv-mockup-category
eg. <em><u>hidden link</u></em>
AND
Mockup Tags slug in one of those set by the URL parameter wpv-mockup-tag
eg. <em><u>hidden link</u></em>
4. Given this, the filter should be removed. You cannot filter a taxonomy by itself, and the archive applies only to taxonomies, so you cannot search by itself in it, since always either a tag or term is used, not many. This filter cannot work, so I removed it.
To have a list of many items, filterable by terms of many taxonomies, you should create a View, query the Post Type in a question, then add Front End Filters by the Taxonomies you need, so to be able to filter posts by terms. On archives, you always area already on one single term in the query and cannot filter that anymore by itself.
5. With what I am left I can filter by text in title and post body, Select items with a field as in File Format and Price lower than xy. These results should update on the fly when changing the input value.
The search works flawlessly, you can try it yourself at the link here hidden link, the Archive is here hidden link.
As said, log in details are in below private response.
Everything is still the same as on your live site but SG, of course, is not caching this server.
Can you confirm that removing the broken (and not supposed to work) filter solves the issue for you on the live site as well?
