Hi, I just upgraded the toolset version for all plugin that were installed. They were actually quite outdated and in order to guarantee my customer all the security benefits and an improvement in terms of results I updated them all.
Now I noticed a quite peculiar issue.
In the previous version, I had a filter that was working just fine (domain of the live cosmogas.com).
In the 'staging' website, where I performed the upgrade, this aspect seems not to be working properly.
The actual code used is the very same.
This issue is involved in all other parts where a filter is called. Any idea on how to act? Let me know if you need any further info to provide me assistance or advice.
Hello, I'll be glad to take a closer look. It might be fastest if you can provide a login for the wp-admin area so I can see how this View is configured. Private reply fields are enabled here.
The main thing I see is that none of the post relationships seem to have been maintained. I edited a few of the Documenti Cosmogas posts, but none of them seem to be connected to any Articoli Cosmogas posts. Do you have a backup of the site from before the update, or can I log into the live site and make a copy to run some additional tests?
Hi Christian,
I'll provide you an environment with the very same configuration that was present before the upgrade.
May I send you a private message as done before? How can I send it? 🙂
Yes of course, I will activate private reply fields here.
Thank you for the access information. I'm creating a clone so I can investigate this in more detail. I'll give you an update shortly.
Okay I see the issue now. It has to do with the translation settings in WPML for the post type Articoli Cosmogas (articolo-cosmogas).
The current setting is "Translatable - only show translated items". In order for post relationships to work with translated content in the latest versions of Toolset and WPML, the preferred setting for Articoli Cosmogas is "Translatable - use translation if available or fallback to default language". This setting will allow you to create post relationships in the default language, and have those relationships automatically apply to content in secondary languages as well.
Is this setting acceptable for your site?
Hi Christian,
Thx for the great help, so far: it seems to be working. What does this change imply?
Another question: there is a further filter option for logged-in users only (if you login with admin privileges I granted you should be able to see the filter I'm talking about).
hidden link
This appeared to be broken, after the upgrade, and now it, at least, it seems not to be as broken as before, but the filters do not behave as it is supposed, and as you may verify in the 'clean' version I provided you.
Is it still an issue connected with WPML, in your opinion?
Any idea, about that, too?
Ps. In case yo wont be able to answer this by today or tomorrow, have a Happy new Year! 🙂
Thx for the great help, so far: it seems to be working. What does this change imply?
The implication of this setting is that Articoli Cosmogas posts in the default language will be displayed if no translated content is provided for a secondary language: https://wpml.org/documentation/translating-your-contents/displaying-untranslated-content-on-pages-in-secondary-languages/#using-the-default-language-as-a-fallback-for-untranslated-content
This appeared to be broken, after the upgrade, and now it, at least, it seems not to be as broken as before, but the filters do not behave as it is supposed, and as you may verify in the 'clean' version I provided you.
It seems there was a server-side error when I tried to load this page:
hidden link
I created a temporary error log to get more information about that. The full error message was:
[30-Dec-2020 20:18:40 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 3538560 bytes) in /wp-includes/wp-db.php on line 2024
To fix that memory issue, I modified the /wp-config.php file to increase the amount of memory available for WordPress by adding the last two lines just after the WP_DEBUG line:
...
define('WP_DEBUG', false);
define('WP_MEMORY_LIMIT', '256M');
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
...
Now the page renders completely without a memory error. However, I'm not sure if I understand the problem with the filters. Did this solve the issue, or is there still a problem with the filter(s)? If so, can you tell me more about the problem?
Maybe I've not explain good: the issue is in the new website, updated --> hidden link
You pasted, and tried the 'clean one', which was actually working as expected, as you pointed out --> hidden link
As you might see, on the updated one, the filter does load with some option already selected:
hidden link
Let me know, if you need any more clarification about this
As you might see, on the updated one, the filter does load with some option already selected
That is strange. I do not see any filters on either site, so I am still a bit confused. Let us review, step-by-step.
1. I log in using the toolsetassistance@...com profile you provided earlier.
2. After I log in, I visit the page here:
hidden link
3. It takes a few seconds for the page to load completely because Query Monitor is active, analysing and reporting on the queries used to generate the page.
4. While the page is loading, I can see the View results displayed on the page, but no search filters. I have attached a screenshot so you can see this loading process as I see it in the browser, page-loading.png.
5. After a few moments the page loads completely, and the View results disappear. However, I still cannot see search filters anywhere. I have attached loaded.png so you can see what I see.
It looks like the filters are present in the page markup, but hidden with CSS. Is there some custom JS / CSS that should make the filters visible? Can you explain that process a bit more?
Hi Christian.
I hope you've passed a good period, with Christmas and New Year.
So, about your latest message, I double checked and, in effect, you were right in saying that you just get a link, within that page (it was connected to your language). Now you should see everything correct, in terms of process:
- Login with credentials already provided
- Visit the page hidden link
- It load and after that you should see this: hidden link
Now you should be able to see it.
I changed the language also in the 'staging' I provided you hidden link. So, if logged in, in this environment, too, you should be able to see how the filter is supposed to work.
Let me know, in case of any issue.
Thx a lot for your work, so far, and the efforts: very appreciated.
Yes okay I see the filter now on both sites, but I am still confused. What is the problem? I see the same filter behavior on both sites:
hidden link
hidden link
When the page loads, I see one filter with no options selected. When I select one option, results load and two more filters appear. I see the same behavior on both sites.
Earlier you wrote:
As you might see, on the updated one, the filter does load with some option already selected:
hidden link;
However, I do not see this behavior on either site. Should I expect to see the selected filter(s) on 1670522 or 1671504? How are these filters activated automatically when the page loads? Is there custom code written to achieve this? Where can I see this custom code?
Hi Christian,
The js script that handles that behavior should rely on this custom.js.
hidden link
The lines should be 8035 and 8132.
Let me know if they make any sense to you.
Thx
I see some custom code that looks like it is designed to show and hide custom field filters and the list of results based on the selected option of the wpv-categoria-documento filter. When nothing is selected in the first filter, the other filters and results should be hidden. If something is selected in the first filter, the other filters and results should be displayed. This all seems okay to me, but I'm still not sure I understand the problem. What do you want to achieve, exactly? How is that different from what is seen on the site now?
