Forum Replies Created
-
Posts
-
Hi Ernest, an additional question related to the missing terms in the dropdown list. How are the terms that I exclude from the taxonomy removed from the filter dropdown?
If they are removed by ASP before passing the list to WordPress, is ASP correctly determining the list of terms to pass? Is there any way of determining the list passed to WordPress? I ask because I noticed that only two of the exclusion terms affect the list of terms returned. One removes the expected top level term, but in error also removes a few child terms. Curiously the excluded top level term ‘UK’, causes the child term ‘Union Street’ to be removed. The second term, ‘Bucks’, causes more to be lost. The issue seems to be with the way the search of excluded terms is performed against the full list of terms.
Thanks for the update. With the change to the taxonomy structure and the example you provided for implementing a sort order frontend dropdown, my site is working well enough to go live.
If the redesign of the filters can include consistent styling across all the different dropdown types, it would be beneficial. I can wait.
Curious, WordPress shows that both the top level terms have records directly associated with them. Other than a malformed data structure when WordPress is retrieving terms, I cannot think of any programmatic way only some of the lowest level terms would be excluded if the top level terms are excluded.
As I am not using these two terms, for the incorrectly showing branches, I flattened the hierarchy and moved the root of these branches to the top level. All the lowest level terms now show as expected. The taxonomy has a weird structure now, but it works.
Related, is there any progress on the new styling of the filters? I implemented your solution for an options drop down to change the results sort order. It works well, but getting the styling of the drop down to be the same as the other filters took longer than implementing it.
Looking forward to the new options interface. Let me know when there is anything to test.
As I’m primarily using multi-select with search, for the same look and feel across all filters, my preference would be to enhance that to handle hierarchical taxonomies with opening and closing sub-categories.
The problem is more than double quotes, it also affects quotation marks on iOS. While out I wanted to look up something on our website and couldn’t find it.
I was looking for >> John’s << with a straight single quote in it. By default iOS changed it to John’s, which made me initially think there were no hits. It took a while to realise it was the same Smart Punctuation issue. This editor dialog is misdisplaying the single quotes!
Maybe not many people are searching using ASP on iOS devices. With Chrome or Safari on iOS, Google.com doesn’t get the same problem. Suggesting there is a way to turn of Smart Punctuation in the text input field.
Ugh, I hate “ and “. Never try copying from a Word document to VSCode. I wondered if it was related to using UK or US keyboards, but I get the same problem on my iphone, using the UK or US keyboards. The touch, or bluetooth keyboard on the iphone and ipad defaults to curly double brackets when entering text into the search field using the ASP shortcode. But using a long touch and selecting the type of double bracket, the default then is straight double quotes and the search works.
The problem is an iOS default since 2017 and is mobile-specific due to rich text on mobile keypads. On the iphone and iPad, the ASP search text input field is supoporting rich text with emojis et al. The issue appears to be as a result of a new feature in iOS 11, Smart Punctuation, that automatically turns straight into double quotes. This has been the default since 2017!
If the url is typed directly into the URL field of Safari, the double quote is interpreted as straight as rich text is not supported as it has to be a url safe field.
The solution does not look to be obvious, though I wonder if the problem stems from the earlier fix, which now with mobiles supporting rich text input and smart punctuation as default, is showing up this latent issue. A majority of mobile users so not need rich text input and like me were expecting the input behaviour to be similar across desktop and mobile. One of the challenges of creating websites that work across mobile and desktop. The behaviour that ASP wants goes against the defaults of iOS. The direction Apple are traveling in with the merger of iOS and MacOS, iPad Pro etc will likely make it visible to more users.
I will put the patch in and at the same time it would be good to add this to the ASP knowledge base. A more nuanced solution would be good to support iOS.
Regards Steve
Hi Ernest, the website is at https://swop-demo.co.uk, though I have spotted the problem. On the phone the search URL is constructed as:
https://swop-demo.co.uk/?s=“Red+cow” with double quotes. It works when the ” is replaced with %22.On my Mac the RUL is constructed as:
https://swop-demo.co.uk/?s=%22Red+Cow%22 with %22On my iphone with the zero results, the returned search URI is:
https://swop-demo.co.uk/?s=”Red+Cow”&asp_active=1&p_asid=3&p_asp_data=1&aspf%5Bsearch_date__6%5D%5Bupper%5D=&aspf%5Bsearch_date__6%5D%5Blower%5D=&device=3&filters_initial=1&filters_changed=0&qtranslate_lang=0&asp_highlight=1¤t_page_id=-1If I construct the search URL myself on my phone, it works and I get the expected 62 results.
https://swop-demo.co.uk/?s=%22Red+Cow%22The full working URL being:
https://swop-demo.co.uk/?s=%22Red+Cow%22&asp_active=1&p_asid=3&p_asp_data=1&aspf%5Bsearch_date__6%5D%5Bupper%5D=&aspf%5Bsearch_date__6%5D%5Blower%5D=&device=3&filters_initial=1&filters_changed=0&qtranslate_lang=0&asp_highlight=1¤t_page_id=-1It looks like the searchtext input field on mobile behaves differently to on the Mac.
Ah, I didn’t find that configuration page. The Display Modes diaglog, could do with a reference to it. As it really influences how the checkboxes work. The single option on the Display Modes dialog to change the default to unchecked, tricked me into thinking that this was the only option.
The settings, as you suggested, with ‘All the selected terms must match, exclude unselected’ did not work. See the discussion below for screenshots 4, 5 and 6. The behaviour I am after is when ‘At least one selected terms should match’.
Currently, I am using ‘Multiselect with search’, checking a child term, the taxonomy returns only those records with the child term assigned. If the parent is selected, the hierarchy includes all records under that term, whether they have the parent assigned or any of the child-terms. Records do not need to be tagged with the parent term, only the child term. WordPress returning the superset, of all child terms and any with the parent term. In my taxonomy, using multiselect or dropdown, and selecting the parent term ‘High Wycombe (outer)’ search returns 10,057 hits. As expected, being a superset of the parent and all the children. The parent term ‘High Wycombe (outer)’ is only tagged explicitly by 375 records. The superset of this and all the children is 10,057.
The Checkbox display mode option does not quite work in the same way. To get the superset of 10.0157, am using the checkbox option ‘At least one selected terms should match’ The result is in screenshot SearchResults1 below. Selecting the checkbox ‘High Wycombe (outer), sub-terms are opened unchecked and 10,057 results are returned. All good.
The way the Checkbox selection is implemented, if one of the child options is selected, the result stays as 10,057, because at this stage both parent and child are selected and WordPress returns the superset. As in SearchResults2. But if I uncheck the parent ‘High Wycombe (outer)’, I get the right number of hits for the child, 255, as only the child-term ‘Abbey Grounds’ is selected. But the hierarchy closes up and there is no indication of which child term was selected. As in SearchResults3. The selected child term could be anywhere in the nested hierarchy. If the user wants to uncheck it, they have to remember where it was and which parent it was under.
A solution to the loss of visibility of the selected child terms, is to leave the subcatergory open if a child is selected and the parent unselected. My preferable solution, would be not to check the parent when it is first clicked, but to just open the child-terms under it. Another issue is that in the selection UI, there is no differentiation between a term that does have children and a term that does not have children. In other solutions, parents with children have a + icon to similar to open the sub-terms without checking the parent. The icon indicating that they can drill down further. The current checkbox support does not allow this.
If I use the checkbox mode ‘All the selected terms must match, exclude unselected’ the results are completely unexpected. Selecting ‘High Wycombe (outer)’ only returns those records which are explicitly tagged with HW (outer). As per SearchResults4, 1942 hits. I had expected the superset. Also its not clear where the 1942 hits are arrived at, the parent only assigned explictly to 375 records. To get the superset, it looks like I have to check the parent and all the children. Which seems to get to the expected 10,000+.
Selecting the first child, Abbey Ground, results in SearchResults5 of 2184. Summing the bad result of 1942 with the child. As per the behaviour shown in SearchResults4, this is not unexpected. But should still be the superset of 10,057.
Where it gets really weird, is unchecking the parent HW (outer), the sub-terms are closed (this is not the right behaviour, as per the above, it should stay open), but very weirdly, the result is 1699 as in SearchResults6. This looks to be the parent minus the child, 1942 – 255. Which is completely the wrong behaviour. Something is broken with ‘All the selected terms must match, exclude unselected’.
In my implementation I interpret the URL search terms and display the terms selected. These appear at the bottom on each screenshot. So its possible to see what terms ASP thinks are selected. These appear as expected. The results returned when using ‘All the selected terms must match, exclude unselected’ certainly do not match the terms when a parent is selected.
Curious. The search box is in a shortcode. Added to the default TwentyTwentyFive search results template. See below.
I added the CSS class and it moved the magnifier to the left, but not to the end. The text clear button and loading icons still appear at the end. I added order 4 for both proclose and prolaoding without any effect.
Search on anything on this page to get to the search results page: https://swop-demo.co.uk/advanced-search/
