I recorded a video containing the steps to reproduce. I think it might've gone to your email by mistake! Sorry - you should be able to access it here. Its about 18MB.
Thank you very much, Simon. I did not notice that update to the sorting filter.
It turns out, that the "Post date" sorting option is always generated by the server when the page loads the first time and after each AJAX results refresh.
But there is a custom Javascript code, run only when the page first loads, that removes this sorting option. When it did the first time, the dropdown falls back to the first option "Last modified". Check this screenshot hidden link
Please note, that this first option, is also the sorting option used, by the PHP custom code, when no other sorting option is chosen.
I would suggest one of the following solutions:
- Remove the option "Post date" from the filter shortcode.
- Implement the same custom code on AJAX results refreshes too. You can choose the necessary events in the filter's Javascript section. Check this screenshot hidden link
I'll let you decide what option you would prefer.
Let me know if there is something else, regarding the existing Javascript code, I should be aware of.
Post Date has already excluded from the filter shortcode by me in an attempt to remove it
- The default ordering in the Ordering section is set to Last Modified.
- And in the [wpv-sort-orderby] and [wpv-sort-order], Post Date was already removed.
Indeed, the bug that Minesh has reported is regarding the first suggestion(Removing post_date ordering option), so we need to implement the second suggestion.
I added the following code to the view's filter Javascript section, it will remove the "Post Date" ordering option after each results refresh.
jQuery( document ).on( 'js_event_wpv_parametric_search_results_updated', function( event, data ) {
/**
* data.view_unique_id (string) The View unique ID hash
* data.layout (object) The jQuery object for the View layout wrapper
*/
jQuery('select[name="wpv_sort_orderby"] option[value="post_date"]').remove();
});
The issue is not reproduced anymore. I'll let you test it from your side, just to be sure we are not missing something.
Sorry I haven't been able to respond until now, been working on other project. Tomorrow I'll be working all day on Native Nanny and can get back to you. I tested it quickly, but would like to do more thorough testing in both languages before I give the green light.
We do not have any visibility on the development deadlines, so, we can't tell when a version of the plugin will be released. This ticket is linked to the internal bug report, once it is resolved, we'll keep you updated.
I'll wait for your test tomorrow, and hopefully, you will find it working as expected. Otherwise, I'll be here to check it further.
I tested this and cannot seem to "break" it any more, in EN or DE :-).. I'd like to have a go at implementing the same fixes for the Nanny Ads before we close the ticket.
Can we somehow start a new ticket together regarding favouriting of the Ads? I haven't heard anything back from the Favorites plugin author unfortunately, and there has been no response on the WP forum (https://wordpress.org/support/topic/using-favorites-plugin-with-wpml/) either.
We love the simplicity of the Favorites plugin and ideally we'd love it to work in a very similar fashion just replacing it with Toolset/WPML compatible code. Our requirements would be then:
- User should be able to simply click an icon on the Ad to favourite it
- The Ad should be immediately visible as favourited without further saving or clicking, (eg like the current plugin does by flipping between two icons, eg empty heart and full heart)
- We should still be able to use Font Awesome icons with it (I imagine that's a given if using Toolset).
- It must be easy to filter for favourited Ads using the built-in Toolset query filtering in Views, so that it's easy to create a Toolset View of favourited Ads
- It should remain WPML-compatible, so if I favourite an Ad in one language it should be favourited in all languages. I think it may be permissible (or even necessary) here to use custom code to enforce this. (One option might just be to use the existing Favorites plugin and come up with this custom code?)
My thinking to achieve this would be:
- Adding a custom field to the Job Ad and Nanny Ad custom post types to hold the favourited flag
- Use JavaScript or similar to force an immediate save on the post after clicking the favourite icon
- Ensure the flag is propogated to all language duplicates or the original if a duplicate was clicked.
What are your thoughts? Can you split this into a separate ticket?
Best regards
Simon
New threads created by Jamal and linked to this one are listed below:
We changed both fields MIN YEARS EXPERIENCE and MAX NUMBER OF CHILDREN to type Select and did further testing. We also added another Ad with "unlikely" values of 20 years experience and 20 children.
Unfortunately the "unlikely" Ad has highlighted the following issues with the AJAX options on:
1) the sorting of the picklists is not correct numeric ordering, eg 1,2,20,3,4 instead of 1,2,3,4,20
2) There is only one Job Ad at the moment in the database with MIN YEARS EXPERIENCE = 20 and MAX NUMBER OF CHILDREN = 20, so I would expect that if I choose MIN YEARS EXPERIENCE = 20 that the picklist MAX NUMBER OF CHILDREN should show 20 (since there are no other valid records in the database with MIN YEARS EXPERIENCE = 20). Instead when I choose MIN YEARS EXPERIENCE = 20, the MAX NUMBER OF CHILDREN is "stuck" on 1 instead of filtering to the (only valid) value of 20.
3) With the numbers turned into Select picklists, I don't see any way to "not" choose a value for the picklists. For example, let's say I don't want to specify ANY value for MIN YEARS EXPERIENCE or MAX NUMBER OF CHILDREN so I can find ALL values for those fields. Is there still a way to do that, other than changing both fields to taxonomies, so they work like the other fields?
Thanks for splitting the ticket off for Favourites.
I only managed only to solve point 1) from the previous update. Points 2) and 3) still need to be addressed.
2) There is only one Job Ad at the moment in the database with MIN YEARS EXPERIENCE = 20 and MAX NUMBER OF CHILDREN = 20, so I would expect that if I choose MIN YEARS EXPERIENCE = 20 that the picklist MAX NUMBER OF CHILDREN should show 20 (since there are no other valid records in the database with MIN YEARS EXPERIENCE = 20). Instead when I choose MIN YEARS EXPERIENCE = 20, the MAX NUMBER OF CHILDREN is "stuck" on 1 instead of filtering to the (only valid) value of 20.
3) With the numbers turned into Select picklists, I don't see any way to "not" choose a value for the picklists. For example, let's say I don't want to specify ANY value for MIN YEARS EXPERIENCE or MAX NUMBER OF CHILDREN so I can find ALL values for those fields. Is there still a way to do that, other than changing both fields to taxonomies, so they work like the other fields?
I wanted to implement this on your website, but it is only rendering a white page on the frontend(for user nativenanny2). I guess that you are working on recovering it.
Currently, I can't check the issue (2). Once your site is back, I'll check it.
We're back online.. 😅Our server was hit by a virus. The virus injected code into some of the files in our wp-content folder, including Toolset Blocks. For that reason I've tried to only re-install what I consider to be essential plugins. That means that File Manager is no longer installed. If you need FTP access, please let me know in a private reply and I can create an FTP account for you.
Regarding both 2 and 3, it seems that you have updated the view to use input fields instead of select fields. So, I wonder if you still need to go through this or not?
At the same time, this ticket has evolved very much since the beginning, and I hoped you would agree, to mark this ticket as resolved and work on a new ticket.
