I see the issue both on English and Italian, and I see the DDBB error as Christian mentioned:
WordPress database error: [Unknown column 'wpml_translations.language_code' in 'where clause']
SELECT s.id, st.status, s.domain_name_context_md5 AS ctx , st.value AS translated, st.mo_string AS mo_string, s.value AS original, s.gettext_context FROM studiogiochi_com_icl_strings s LEFT JOIN studiogiochi_com_icl_string_translations st ON s.id=st.string_id AND st.language='en' AND s.language!='en' WHERE s.context = 'default' LIMIT 1000 OFFSET 6000
I also see that it works if you change the filter to not update the values and hence show them all at all times.
I then updated the system, and removed Software piece by piece, starting with the non-OTGS Software.
1. After updating WPML the issue went worse and the SQL error bigger.
Errore sul database di WordPress: [Unknown column 'wpml_translations.language_code' in 'where clause']
SELECT studiogiochi_com_posts.ID FROM studiogiochi_com_posts INNER JOIN studiogiochi_com_postmeta ON ( studiogiochi_com_posts.ID = studiogiochi_com_postmeta.post_id ) LEFT JOIN studiogiochi_com_posts AS p2 ON (studiogiochi_com_posts.post_parent = p2.ID) WHERE 1=1 AND ( ( studiogiochi_com_postmeta.meta_key = 'wpcf-pubblicazioni-anno' AND studiogiochi_com_postmeta.meta_value = '2012' ) ) AND studiogiochi_com_posts.post_type IN ('post', 'page', 'attachment', 'autore', 'editore', 'pubblicazioni', 'le-nostre-pagine') AND (((studiogiochi_com_posts.post_status = 'publish' OR studiogiochi_com_posts.post_status = 'private') OR (studiogiochi_com_posts.post_status = 'inherit' AND (p2.post_status = 'publish' OR p2.post_status = 'private')))) AND ( ( ( wpml_translations.language_code = 'it' OR ( wpml_translations.language_code = 'it' AND studiogiochi_com_posts.post_type IN ( 'post','page','autore','editore','pubblicazioni','edizione','le-nostre-pagine' ) AND ( ( ( SELECT COUNT(element_id) FROM studiogiochi_com_icl_translations WHERE trid = wpml_translations.trid AND language_code = 'it' ) = 0 ) OR ( ( SELECT COUNT(element_id) FROM studiogiochi_com_icl_translations t2 JOIN studiogiochi_com_posts p ON p.id = t2.element_id WHERE t2.trid = wpml_translations.trid AND t2.language_code = 'it' AND ( p.post_status = 'publish' OR p.post_type='attachment' AND p.post_status = 'inherit' ) ) = 0 ) ) ) ) AND studiogiochi_com_posts.post_type IN ('post','page','attachment','autore','editore','pubblicazioni','edizione','le-nostre-pagine' ) ) OR studiogiochi_com_posts.post_type NOT IN ('post','page','attachment','autore','editore','pubblicazioni','edizione','le-nostre-pagine' ) ) GROUP BY studiogiochi_com_posts.ID ORDER BY studiogiochi_com_posts.post_date DESC
2. Your archive does not feature the closing "[/wpv-filter-controls]", it's missing. I added it, but this did not fix the issue, however, the error at least now is again like before (short)
Errore sul database di WordPress: [Unknown column 'wpml_translations.language_code' in 'where clause']
SELECT s.id, st.status, s.domain_name_context_md5 AS ctx , st.value AS translated, st.mo_string AS mo_string, s.value AS original, s.gettext_context FROM studiogiochi_com_icl_strings s LEFT JOIN studiogiochi_com_icl_string_translations st ON s.id=st.string_id AND st.language='it' AND s.language!='it' WHERE s.context = 'default' LIMIT 1000 OFFSET 6000
3. There is a View on that archive, but it's not inserted in the archive, instead somehow else. How do I remove that view?
(hidden link)
4. I created a new view and there I see all available dates.
The query finds 216 items.
hidden link
As soon you add pagination, then you will "find" only the amount of items per page with wpv-items-count, instead, wpv-found-count returns the full amount of posts.
The options in the DropDown search will be all there if you do not paginate, they will only show the ones on the very current page if you paginate.
This, is not replicable locally. Locally, you will always see all options unless of course, some other filter removes them, but pagination does not influence that filter.
But then, I saw that this is NOT a Post Types archive, instead, it is a TAXONOMY archive, and there, look at that, I can replicate the issue clean and clear on a local install, no big deals needed.
The thing is, it requires always a lot of testing to find the steps for the precise issue, but they are always there (lucky us)
Now, on local, the issue works like this:
1. Create a Custom Taxonomy and assign ONE term to ONE Post. Create ANOTHER Term and assign it to ANOTHER post
2. Both those posts should also have a Custom Field with any value you want (this is what we will use in the search later, and will "break")
3. Create an archive for that taxonomy and in it, a custom search for the field, select mode
4. Choose to always hide non-valid options and paginate by one
5. Complete the loop and observe/use the Archive on the front end
It will show only ONE value in the search select for the custom field.
If you paginate, it will show a new value matching the ONE post displayed on the page.
If you remove pagination, then all items will show in the search
If you add a SECOND Post to the exact same term, then that posts custom field value as well appears in the search
This is exactly what happens on your site, and I am not sure if this is expected!
See, when you load a taxonomy archive the query IS already restricted to ONE term, so only posts of that term are displayed and so only Custom Search options of those posts appear.
What is not expected, is that pagination has an influence on this, it should not by what I know, and that is why I report this as an error.
The current workaround to this is to not paginate, or not limit the search input.
It workes well on post archives.
Note, I above wrote my entire process done on your site, until I had the problem localized
You might ask yourself why I do not just say "I replicated the issue please wait for the fix". I do this for 3 reasons:
- you can learn to troubleshoot and know where to look for next time
- our supporters can see what I did
- other users can see what we do and how we solve issues or narrow down steps and will understand better why this is so important and (sometimes) takes time.
I hope you are fine with my more elaborated style of support and will update you here once I have news from the developers, .about this problem.
Eventually, an erratum will be published which I then also would share here.
Related to the Error (SQL Error), I would suggest opening another thread for this in WPML Forum as it is not related to this issue or Toolset in general. This should instead be an issue that is fixable with WPML's troubleshooting steps and seems not to affect our issue here now.
Beda.
