Forum Replies Created
-
Posts
-
Hi Ernest,
Thanks for the confirmation, and I appreciate your thoroughness. I’ll watch for the next update as always.
Happy holidays to you! =)
~ Michael
Hi Ernest,
I’m glad we tried this, because the problem is now solved! You were right in your assumption about the cause being the display property. I had display: block !important; on the p.showmore element. As soon as I removed that this problem disappeared.
I am extremely thorough with my css and almost always define the display property. Add to this that I use !important on every property in my custom css file to make it the authoritative file (it’s my methodology).
I also have display: inline-block !important; on the “p.showmore a” element, and needed to keep that as the inline-block helps me to control the button width. The problem seems to have been limited to the p.showmore element only. I assume I am ok keeping it on the “p.showmore a” element?
Thank you for figuring this out for me. I usually keep an eye out on inline css to make sure I don’t override dynamic css like this, but I missed this one.
So at this point the only thing left in this thread is this item below. I am copying it here so I don’t forget about it.
…..
Missing Label Options for Filter by Format and Filter by Categories
Thank you for letting me know. I will have to cross-check this as well, and make sure to include the options missing in the next release.
I’ve listed this here again so we don’t forget about it. I also wanted to let you know that what is specifically missing are the label text options for Filter by Format and Filter by Categories. Both of these are under this settings screen: Front-End Search Settings > Categories & Taxonomy Terms. I think the reason this was never included is because both of these filters are setup in the same screen.
…..
Thanks again for going above and beyond! You really are the best! =)
~ Michael
Hi Ernest,
This sounds like a plan. I’ve been working a very long night so I am going to do this first thing tomorrow for you. Hopefully we can figure out the cause of this with some coordination. Please check for a response from me tomorrow, and thanks for sticking with me on this one!
~ Michael
Hi Ernest,
Our environment isn’t even reachable via FTP. It is a Docker container deployment on AWS ECS. The only way to interact with the codebase is in our repo.
I can’t provide you with access to our repository for obvious reasons. I could maybe let you into our development site, but you wouldn’t be able to change anything. None of the code can be manipulated from the site itself.
I’d prefer we find another way to diagnose this… Are there any steps/tests I can run on my end?
~ Michael
Hi Ernest,
I’m sorry to say I have not changed any of the template files in the plugin. The only changes we have made to the plugin are via various filters, most of which you know about. I have never modified any of the template files in the plugin itself.
I can provide you with my configuration if that helps (using the export function).
~ Michael
Hi Ernest,
I’m glad you saw this issue as well. I am constantly developing and deploying changes here, which means all the caches are cleared many times over. I’m referring to caching at every level; our CDN, server-side, my local browser, etc. Trust me, this issue is still there. I’m very careful about clearing all the caches during deployments here.
~ Michael
Hi Ernest,
I wanted to follow up with you regarding the latest plugin update. I installed the update yesterday and have tested the items related to this thread. Thank you for including my requests in this update so quickly!
Adding Comments to the Content-Type Filters
The comments content-type filter is working nicely in the new location (with all the other content-type filters). I set up the filter again and tested it, and it is working properly. Thank you for this.
…..
Bug Related to the No Results Container
This was the item that was really troublesome, so I am glad you worked on this. The initial problem with the no results container incorrectly appearing does appear to be fixed. I tested this by going to the last page of search results on multiple searches and flipping back and forth between the last two pages. I did not see the no results message this time, so your fix did work. However, there seems to be a new problem in its place.
New interrelated problem…
Auto-Search Function in Repeating Loop When Reaching Last Page of Search ResultsWhen you reach the last page of search results the auto-search function initiates and never stops unless you leave the last page of results. I’m referring to the same function that occurs when you change search settings (the search automatically starts). Normally when you reach the last page of results it is simply the last page and nothing else should happen. This problem seems to be related to the fix you just implemented for the no results container. As soon as you reach the last page the auto-search starts and is almost impossible to stop. This is particularly problematic on mobile devices where it causes all kinds of ajax errors on the page. I noticed this issue while testing on mobile, but it is occurring on desktops as well.
…..
Just a reminder about this item below, when time permits…
Missing Label Options for Filter by Format and Filter by Categories
Thank you for letting me know. I will have to cross-check this as well, and make sure to include the options missing in the next release.
I’ve listed this here again so we don’t forget about it. I also wanted to let you know that what is specifically missing are the label text options for Filter by Format and Filter by Categories. Both of these are under this settings screen: Front-End Search Settings > Categories & Taxonomy Terms. I think the reason this was never included is because both of these filters are setup in the same screen.
…..
Unless I am mistaken I think that covers everything left in this thread. Thank you again as always! =)
~ Michael
Hi Ernest,
That’s not a problem, as I have other ways to work around this. I don’t think I would have wanted to complicate this with separate JS. It’s preferable to have this all controlled from the single filter. So even if you were willing to do that work I wouldn’t have wanted to make it more complex.
What I’m probably going to do here is use your server-side mobile detection in combination with a smaller font-size starting at 768px. This way those in-between screen sizes are taken care of. Up until now I’ve had only the one title font-size in place for all screen sizes. I’ll just make a smaller font-size to help alleviate this problem.
Btw, I actually have my own outsourced team of developers that I already work with. But suffice to say those hours are very expensive. This is why I appreciate your help so much.
My thanks again for all your help developing this filter. I look forward to showing you everything in a few more weeks.
I’ll keep an eye out on your next updates for everything else we covered in this thread.
P.S. I have installed the mobile detection option and tweaked my responsive css to work well with it. I thought you’d like to know that the mobile detection does in fact work in Chrome’s emulator. I also found that the mobile detection is including tablets like iPads (so it is not limited to phones). This meant I was able to keep a slightly larger font-size for those devices since the lower word limit applied. The only thing I have left to do is test this on the real devices, which I will do after the next deployment. This is all working quite nicely. Thank you Ernest! =)
All my best,
~ Michael
Hi Ernest,
I appreciate that you tried to do this via server-side mobile detection, but this is not the best solution for my needs. Let me explain why…
The main issue with this method is exactly what you were talking about above, the difficulty of detecting mobile devices server-side. This solution must be extremely consistent in order for us to use it. It would have to work perfectly in all situations, which cannot be guaranteed via a method like this.
The other more pertinent reason is that this is not really a “mobile” issue. It is a sizing issue related to screen sizes and search result card proportions. As you know the plugin automatically determines the size and number of cards based upon the available screen space. This means that there are several popular screen sizes that will have cards that are too small (and would require the lower word count), but are not considered mobile devices. Some examples of this are the 768px width (iPad), 600px width, and 480px width. All of these sizes will not accommodate the 20 word count that I want to use for the larger screens.
This is why when I first wrote to you about this that I was speaking about a cut-off point at 768px, because I already worked out the math and knew this is where the lower word count would need to begin. We cannot base this upon mobile detection. It must instead be based upon screen size (viewport), just as we do with css media queries. This way we can be absolutely sure of when the lower word count will be used, and define this to a specific cut-off point that works best.
If you are willing to try this, this is the approach that would work…
We would need two new settings. The first would be a cut-off point in pixel width (max-width) that the lower word count would apply to. We would set this to 768px, and that would mean the lower word count would apply to all devices with a width of 768px and lower. Any screen widths above 768px would use the higher word count. The second setting would be the lower word count itself, where we would define the maximum number of words to be used on the smaller screens.
Beyond the reasons I described above, the other reason this will work better is it will not be dependent upon server-side detection. Instead it will use client-side detection just like css media queries. This will work every single time no matter what kind of device the user is using. It is also more flexible because we can define the cut-off point, and not worry about what devices are considered “mobile.”
I know I’ve asked a lot of you here, but if you can go this one last step it would be exactly what I need to make this work. I also think this is a better approach for anyone else that makes use of this filter.
~ Michael
Hi Ernest,
Did you ever see my last message above? This was the only remaining detail to perfect the filter. If this is something you can do it would be great. Otherwise we can just leave it as-is.
Btw, at this point I am more concerned with completing the other items in this thread that you said you’ll be doing in the next plugin updates. I only mention it here as I don’t want to forget about it myself.
~ Michael
Hi Ernest,
You nailed it this time! =)
This is exactly what I needed and I’m happy to report it is working perfectly. I have tested the title limit and it is counting the words. So the function you looked up works. I also re-tested the entire filter to make sure all the original features were working. Everything we’ve done is working as designed. My compliments… you make this look easy!
I could call this completed, but there was one small improvement we could still do (if possible). I had to set the word limit to 12 because the isotopic cards are a lot smaller on mobile devices. The text size is smaller on those devices as well (as I have media queries in place), but overall there is still less room on mobile devices.
It turns out that on full size screens a word count like 20 works great. But on mobile devices it can’t be larger than 12. So it occurred to me we could have two limits here. One for large screen sizes, and one for small. We could make the smaller limit for screen sizes of 768px width and smaller. My testing shows this would be the best place for the cut-off.
I could just leave the lower limit of 12 in place for all screen sizes, but having the two limits would work better for larger screens. Of course I don’t know how complex this would be to do.
…..
I just want to say that you’ve been an amazing help with these filters. I really owe you one, because these changes greatly improved the search on our platform. I’m really looking forward to showing you our implementation in a few weeks when we go live. You’ve been instrumental in our search customization, and I just want to say thank you again. Of everyone I’ve dealt with (in terms of plugin developers), you have been by far the most responsive, capable, and generous. Sometimes I have to remember you’re not on payroll, and are doing all of this just to be helpful. Speaking of money, I’ll be renewing my paid support again on theme forest!
Thank you Ernest! =)
P.S. Just renewed my support!
~ Michael
Hi Ernest,
Thank you again for working on this filter. The custom names for the taxonomy content-types are working perfectly, but unfortunately you went in the wrong direction for what I needed on limiting the length of the titles.
I spent a lot of time integrating in your changes, but when I tested them I discovered you had misunderstood what I needed. The length limits you added only apply to the custom lines we have added to the title (like the content type and post format). I didn’t need or want to limit those lines at all.
What I need to limit is the total length of the normal titles… not the extra lines that we added. This is really a problem for post titles in particular, but the solution can apply to all the content types.
This is what the HTML structure of a search result titles currently looks like:
I’ve tried multiple times to paste this in here as code and it doesn’t work. I’m replacing the normal brackets with parenthesis so this displays.
[h3]
[a class=”asp_res_url” href=”https://”%5D
“This is the title that we must abridge…”
[br]
[span class=”content_type”]Shares[/span]
[br]
[span class=”post_format”]Article Format[/span]
[/a]
[/h3]The length limit you added is applying to the content_type and post_format spans above. I don’t want to limit these lines at all. What I need to limit is the total length of the original title which you see above in quotes. The other issue here is that I need to limit the total length of the title and not worry about the lines. It makes no sense to limit individual lines since the title wraps from line to line. I simply need to specify a maximum word count for these titles. This will work a lot better with a word count than a character count. But either way it cannot be a per-line maximum. The maximum must apply to the title as a whole, counting from the start of the title. This way I can limit long post titles that do not otherwise fit in the search result cards.
It really doesn’t make any sense to leave in the character count limits you just did. I do not want to limit those lines at all. So we should take this out completely. I only want to limit the main title as described above.
I’m sorry to ask more of you here. I really was hoping we had it right this time. I didn’t even realize this was implemented incorrectly until I went to test it.
This is the only remaining issue at this point. Perhaps one good way to approach this would be to surround the main title with a span and class, and then target it specifically. This makes sense since the other custom parts of the titles have their own classes.
Hopefully this all makes sense. I feel badly asking more of you… but we are so close with this!
~ Michael
-
This reply was modified 7 years, 6 months ago by
.
-
This reply was modified 7 years, 6 months ago by
-
This reply was modified 7 years, 6 months ago by
-
This reply was modified 7 years, 6 months ago by
-
This reply was modified 7 years, 6 months ago by
-
This reply was modified 7 years, 6 months ago by
-
This reply was modified 7 years, 6 months ago by
Hi Ernest,
Thank you for adding the post-formats to the titles filter. The feature is working flawlessly, and I have tested it for all post-formats. It is also working correctly for the default post-format. This has really enhanced this filter, and I am very happy with how this turned out. Thank you!
There is only one thing left associated with the titles filter that you missed again for some reason. This is very important or I won’t even be able to use this filter at all. I think you have been confusing this request with the question I asked about the taxonomy content-type filter (in the settings).
I’m going to rewrite this here to make it clear…
You added this option previously so we could separate the names of the taxonomy types in the titles: $separate_taxonomies = true;
Whenever a taxonomy content-type is displayed in the titles it is using the words “Categories” or “Tags.” The problem here is the name “Tags,” as we do not use this term on our site. We call our tags “Subcategories.” In other words, we have Categories and Subcategories on our platform. Therefore it must use the term “Subcategories” instead of “Tags” when displaying this in the titles.
What I need here are two display options where I can simply specify the names to display. One option will be the name for categories, and the other is the name for tags. This should be very simple since all we are doing here is replacing the name in the string.
…..
Here are two more things of note related to the titles filter:
a. You have an extra space in this line of your code which causes the Gallery post-format not to display: ‘gallery ‘ => ‘Gallery format’,
b. We need to be able to limit the number of words that display in the titles (for all titles in the search results). This would be a maximum word count which we would specify. Any titles longer than that number of words would display an ellipsis where the title is cut off. We’ve had to create this feature over and over again on our site wherever post titles display because some of our post-formats can have long titles (namely Questions). You probably have a filter already created for this purpose somewhere, as I doubt I’m the first person to need this.
…..
Related Question: Separating Taxonomy Types in Content-Type Filters
You actually misunderstood what I was referring to. What I want to separate is the content-type filter option for taxonomies. If you include the taxonomies in those filters it displays a single filter option that includes both categories and tags. What I would like to have is separate content-type filters for categories and tags. As to your point above, yes, we use those filters as well so users can select/exclude individual categories from the search (we don’t use the tags filters because we have endless tags). But we also use the content-type filters and this is where it combines the taxonomies into a single option.
I think I understand this now – you need to ‘separate’ the taxonomy content type filter into two parts based on the taxonomy. Unfortunately this is still not going to be possible. I was thinking of a possible approach, by somehow using the taxonomy field within the terms query, but it is too complicated to make it work on both the filters and the query itself at this state.
I figured this was probably going to be difficult, and appreciate your thinking about this. Now that we are including the separate taxonomy names in the titles this is less of a problem. If someone filters the search to only display categories/tags they will receive a combined list, but the titles will separate the categories from the tags. So this isn’t really that bad a problem anymore.
…..
That covers everything beyond the few issues you’re including in the coming updates. Of all those issues this is the one that is most important since it is a bug affecting all our searches: New Bug Related to the No Results Container.
I’ll keep an eye out on next updates of course.
Thank you for everything Ernest. You’ve been amazing on these filters!
~ Michael
-
This reply was modified 7 years, 6 months ago by