Questions Regarding Advanced Title Fields

Home Forums Product Support Forums Ajax Search Pro for WordPress Support Questions Regarding Advanced Title Fields

This topic contains 41 replies, has 2 voices, and was last updated by

 
Participant
3 years ago.

Viewing 15 posts - 1 through 15 (of 42 total)
  • Author
    Posts
  • #19954

    Participant

    Hi Ernest,

    I hope you are doing well! It’s been some time since we last talked.

    Just in case you’re wondering things are going very well here with our platform’s development and the launch date is set for February 1st. I wanted to launch for new years’ originally, but we needed an extra month to get everything done. I’m sure after all this time talking to me you’re more than curious to see the site. I’ll definitely let you know when it goes live, but expect it by February.

    The reason I opened this ticket was because I started taking notice of the Advanced Title Fields functionality in the plugin. I never really paid much attention to it, but now realize it could be very helpful for us. I’ve already used it for the member search to display the @ symbol before usernames. That’s actually how I stumbled into this today.

    I have a few questions for you regarding this…

    1. I’m interested in possibly using a BuddyPress xProfile field to display in the member search results just under the person’s username. Right now I just have the title set to display @username (which is working nicely). I was thinking it would be neat if I could maybe display a single xProfile field below the username. I tried doing this using the meta field names, but nothing would display. Keep in mind we only display titles in our isotopic results.

    This is how this would look:

    @Username
    xProfile Field Content

    2. I’m alternatively interested in displaying the user’s BuddyPress Last Activity below their username, but I can’t figure out a way to do this either. There’s a setting for the BuddyPress Last Activity for the description field, but as mentioned above we only display titles in our Isotopic search results.

    This is how this would look:

    @Username
    Active 1 hour ago

    3. I had a really neat idea to apply to all the search results. I was wondering if it would be possible to display the Content Type directly under the search titles. I’m referring to the content types as we have them named in the Front-End Search Settings > Content Type. Then we could display search results like this:

    Share (Post) Title
    In Shares

    Media Title
    In Media

    @Username
    In Members

    Subcategory (Tag) Title
    In Categories & Subcategories

    We are using a number of different content types in our search and they are all filterable. But when running a default search all of the content type results are mixed together. Being able to display the content type just below the title would be very helpful for users.

    …..

    I think that about covers it. I’m always finding ways to make the search even better. Your plugin never ceases to amaze me!

    Talk soon,

    ~ Michael

    #19968

    Hi Michael!

    I am not sure if I answered in your previous topic, let me know if you want me to check back on that.

    1. & 2.
    Okay, I think I see where the issue is. The advanced fields in this case won’t work with the xProfile fields, as those are different from the user meta fields. Both could be doable by using a custom code. I have constructed the following to help you resolve this one:

    Change the first 4 variables within the code as instructed to get the appropriate results.

    3. Actually, it might be possible as well.

    Just change the texts in the first variable, or remove a line, if you don’t want the text for that content type.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #19979

    Participant

    Hi Ernest,

    I left this for the end of my work day because I knew it was going to be fun, and it sure was! I haven’t been this excited about the search in a long time. I was able to combine your code above with some targeted styling changes and it made an amazing difference to the search results. Thank you so much for providing this. You my friend are a genius! =)

    All of your code is working beautifully. I only wrote down a few things to ask about…

    1. This was the one bug in the code. For the code that returns the content type it is displaying the “post_page_cpt” instead of the “attachments.” The attachment search works just fine, but it is simply saying the incorrect content type below it. I wonder if this is issue is related to the code we use to forward attachment results to their parent post?

    2. For the content type, is there any way to separate the categories and tags into separate types? This issue has actually come up before in the content type filters. I’ve been wanting to separate the filters for categories and tags, but you told me a long time ago this wasn’t possible. Do you still think that’s the case? Now that I think about it the content type displayed in the title should really match the content type in the filter options. Right now we call this “Categories & Subcategories,” but it would be great to be able to separate these into two types.

    3. For the custom field code on the member results, I’m using an xProfile field. However, I did try the last active option as well. I noticed that this displayed an actual date and time which wasn’t really user friendly. Usually in BuddyPress it displays the last active time in a more readable format like, 1 day ago, or 1 day three hours ago, etc. Would it be possible to get this to display the last active info the same way BuddyPress does it?

    4. I don’t know why I didn’t notice this before, but there doesn’t seem to be a content type filter options for post comments. I really didn’t take notice of the post comments showing up in search until today. This could be useful for us, but I’d like to have it be a content type filter (since it is a content type). I noticed you had this as one of the options in the content type title code, so I looked for it in the search results. The title is working perfectly, but there’s just no content type filter available for it. (See my update below under #5, as it is related to this)

    5. It turns out that the comments search results are showing up in the results even if I select only one content type filter. As mentioned in #4 there isn’t a content type filter available for the comments. I just found that if I filter the content type to only display one type it is mixing in the comments.

    UPDATE:
    Ok, I see you can turn off “Search in Comments” from the Search Settings. This prevents the comments from showing up in search results. I think what is confusing here is that the comments now have a content type title, but you can’t filter them under the content type filters. Instead that is under the search settings area. It’s a little counter-intuitive. To be able to search in the comments (as the option says) means to return a search result that is a comment. Anyway, you can see why I missed this at first. Perhaps this makes more sense to be under a content type filter? Just thinking out loud here.

    6. I modified your code in both scripts slightly to add in a <span> with a css class. It’s working perfectly, but I wanted to run it by you. I’m never 100% sure about those periods in the code for separating strings.

    This is what I have:
    $r->title .= ‘<br><span class=”content_type”>’ . $content_types[$r->g_content_type] . ‘</span>’;

    7. Very small thing I just noticed while trying to change the term “Filter by Categories” to “Filter by Category” in the search settings. It seems there are no label options for either filter by format or filter by categories. I noticed that the only filter label that was plural was categories, so I tried to change it, and then saw there was no label option for it.

    …..

    As for the original thread, yes, there are some things left in there still. I really need to review what is still a problem to let you know. I can tell you that the problem with the cards shrinking on subsequent searches is still occurring. That’s probably the most annoying issue. I’ll get back to you on that thread when I have some time.

    You’ve been so amazingly supportive in the customization of this plugin. I can’t tell you how much I appreciate it! The search looks incredible in the site, and these latest changes just took it up another notch. Thank you so much! =)

    ~ Michael

    #19991

    Hi Michael,

    1. Indeed, and I think it’s because of the index table. I have made a change to the code, so now it recognizes the attachments and corrects this mistake.

    2. In this case, that could be possible. There is also another change in the code above, so that when you se the $separate_taxonomies variable to true, then the taxonomy names will be used in the title instead.

    3. This took me a while to check. There is a buddypress function for that, I have made a change to the code to include that as well.

    4. & 5. Yep, the comment content type filter is indeed missing as it seems. I will make sure to include it in the upcoming release, that should resolve this completely.

    6. This is perfectly fine, I have included in the changed file as well.

    7. 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.

    Thank you again for your kind words, and sorry for the short-answers. I am trying to be more effective and anwser as soon as possible, so I don’t make the mistake of forgetting answering your queries.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #20000

    Participant

    Hi Ernest,

    There’s no need to apologize for the concise responses. I actually appreciate your efficiency and don’t mind short answers so long as they fully address the issues (which these did). With that said I will do my best to keep my answers concise as well. I know I tend to be very descriptive in my writing (I have a detail-oriented nature).

    I have to say how appreciative I am of you providing these custom filters for me. I realize these can be used for other customers of yours, but you are basically providing me with custom programming. I pay a lot of money here for programmers, so having your help with things like this saves me a lot of time and money. It’s also much more efficient as you know your plugin extremely well, and are fast with writing functions like this. We’ve written a number of custom functions for ASP as well, but you are much better at it because of your familiarity with the plugin. With that said, my continued thanks!

    ITEM 1

    Indeed, and I think it’s because of the index table. I have made a change to the code, so now it recognizes the attachments and corrects this mistake.

    Your corrections for this problem worked perfectly. The attachment results are now displaying the proper custom title. Thanks!

    ITEM 2

    In this case, that could be possible. There is also another change in the code above, so that when you se the $separate_taxonomies variable to true, then the taxonomy names will be used in the title instead.

    This too is working very nicely for separating the taxonomy term titles. There is only one remaining issue:

    We use the term “Subcategories” instead of “Tags,” and right now this is displaying the word Tags. Can you add two fill-in-the-blank options to the filter so that when this option is enabled we can specify the names for the categories and tags taxonomies? It is displaying the correct word for categories by the way, but I figured we should include options for both taxonomy names.

    Related Question:
    At some point in the future would it be possible to separate the actual filter option for taxonomies, so users can filter by categories and tags separately in the search settings? Right now it is a combined option. It would be very helpful to have these separated in the filters if its technically possible.

    ITEM 3

    This took me a while to check. There is a buddypress function for that, I have made a change to the code to include that as well.

    Just letting you know that this worked perfectly, and the BuddyPress last active option is now displaying the proper BuddyPress time format. Sorry this took you a lot of time to figure out. I could have told you there was a custom function for that.

    ITEMS 4 & 5

    Yep, the comment content type filter is indeed missing as it seems. I will make sure to include it in the upcoming release, that should resolve this completely.

    I’ve been thinking more about this and I believe it would be best to include the comments content type as a possible content type filter in the search settings. The filter should have the ability to be custom named like the other filter options do (we call comments “contributions” on our platform). The reason I think you should add this is there is an inherent difference between saying “search in comments” and “filter out comments.” It makes sense that if you don’t search in comments that comment type results should not display. However, it is still not a filter, and since comments are a content type it should be filterable.

    ITEM 6

    This is perfectly fine, I have included in the changed file as well.

    Thanks for the confirmation. I have actually added similar css classes to the custom fields filter as well.

    ITEM 7

    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.

    These are just missing label options, for Filter by Format and Filter by Categories in the search settings. Thanks for adding them to the next release!

    …..

    And this is what I call concise answers… 😉

    I am really looking forward to showing you our implementation of ASP. I think it will be the most fully customized implementation you’ve ever seen. Choosing your plugin was one of the best decisions I made for our platform! 🙂

    ~ Michael

    #20016

    Participant

    Hi Ernest,

    Please read my post above first… 😉

    I just had one other idea to further improve the content-type in titles. The posts on our platform have eight possible post-formats. It occurred to me that it would be useful for post content-type results to also display the post-format.

    It would look like this… (we call posts “shares” on our platform)

    This is the Post Title
    Shares
    Article Format

    So just underneath where it says Shares (indicating the content-type) we would display the post-format. In order for this to work I would need to be able to specify the proper name for each post-format in the title. This would also have to function for the default post-format (Article), which as we know is really a lack of any format. This is where I am worried this may be difficult to accomplish.

    If this is something that can be done I do think it would be very helpful on our platform. As I said we have eight different post-formats and posts will make up the bulk of search results.

    Everything we’re doing here with titles is to make mixed search results more clear. I doubt everyone will be using the settings screen (or even notice it), so having the titles help to differentiate the search results is a good thing!

    …..

    New Bug Related to the No Results Container

    Over the last few days I’ve been noticing this new bug in the search and just figured out what was going on…

    It seems that the no results container (div.asp_nores) is displaying when it shouldn’t. I’m noticing this happening when I get to a higher number of page results in the isotopic display. If I switch between various ajax pages suddenly the no results text and container starts to display behind the actual isotopic result cards. It looks really bad when this happens, and I can make it happen every time simply by going to a higher page and switching back and forth between pages. You should be able to reproduce this on your end. I may be able to hide this container with some conditional css, but this should really be fixed on the back-end.

    I took a look at the css btw, and there’s no way to hide this conditionally…

    ~ Michael

    #20040

    Hi Michael,

    Thank you for your kind words, again!

    2. Well the category and tag filters are actually separate, so I am not exactly sure, you might be reffering to something else here. I mean the filter by tags option, which is a differnt option from the category filters: https://i.imgur.com/Yrrh45Q.png

    4-5. That is exactly what I am going to do, include it as a separate element within the content type filters. (as it should have been there arleady)

    Post format in titles
    I might be able to modify the previous code to include that in the titles as well. Let me know, if you are interested in that.

    New Bug Related to the No Results Container
    That is a very rare issue, I have actually investigated and fixed some instances of it before. It happens, when the predicted number of results is not accurate, and the plugin tries to load more – but instead it gets the no-results box.

    The inaccuracy is usually due to a custom code, that may affect the results count after the search is finished. I don’t recall if I suggested anything similar to you before. But if there was any custom code that may alter the number of results in any way, that I suggested, then that would explain it.

    I have noted this as an issue, and I think I know a way to fix it once and for all. Expect a bugfix for this in the upcoming release.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #20048

    Participant

    Hi Ernest,

    I just wanted you to know that I appreciate your support and don’t take it for granted. I work with a lot of developers and plugin authors, and very few of them are as generous with their time as you. It’s greatly appreciated.

    ITEM 2
    Content-Types in Titles

    You actually missed the important part of this item. I’m copying it below for you…

    There is only one remaining issue:

    We use the term “Subcategories” instead of “Tags,” and right now this is displaying the word Tags. Can you add two fill-in-the-blank options to the filter so that when this option is enabled we can specify the names for the categories and tags taxonomies? It is displaying the correct word for categories by the way, but I figured we should include options for both taxonomy names.

    To further clarify, this is for the content-type title option that allows us to separate and display the taxonomy types. We simply need to be able to specify the names of those separate types. Without this ability I couldn’t even use this option as we don’t use the term “tags” on the site at all.

    Related Question:

    Well the category and tag filters are actually separate, so I am not exactly sure, you might be reffering to something else here. I mean the filter by tags option, which is a differnt option from the category filters: https://i.imgur.com/Yrrh45Q.png

    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.

    …..

    ITEMS 4 & 5
    Adding Comments to the Content-Type Filters

    That is exactly what I am going to do, include it as a separate element within the content type filters. (as it should have been there already)

    Thank you for adding this. When you do add it please make sure the name of the filter can be customized as we can currently do with the other options. I’ll be naming this “Contributions” instead of “Comments.”

    …..

    ITEM 7
    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.

    …..

    Including the Post-Formats in Titles (In Addition to the Content-Types)

    I might be able to modify the previous code to include that in the titles as well. Let me know, if you are interested in that.

    Of course I am interested! This is why I asked about it . This would be extremely helpful for our platform. If you can add this to the content-type title code that would be perfect.

    I think this should be structured as another option, with the ability to turn it on/off. Please keep in mind:

    – The post-format would have to display beneath the content-type (this only applies to posts).
    – All of the post-format names need to be customizable.
    – This will have to work with the default post-format as well (we call it “Article”).

    If you can accomplish this it would be amazing (and very much appreciated)!

    …..

    New Bug Related to the No Results Container

    That is a very rare issue, I have actually investigated and fixed some instances of it before. It happens, when the predicted number of results is not accurate, and the plugin tries to load more – but instead it gets the no-results box.

    The inaccuracy is usually due to a custom code, that may affect the results count after the search is finished. I don’t recall if I suggested anything similar to you before. But if there was any custom code that may alter the number of results in any way, that I suggested, then that would explain it.

    I have noted this as an issue, and I think I know a way to fix it once and for all. Expect a bugfix for this in the upcoming release.

    I don’t know of any custom code we have that would affect the number of search results, but we are using a great many options in the plugin and have a lot of custom code in place that affects the images displayed in the search result thumbnails.

    There is one filter we are using that may have something to do with this. It removes the default (article) post-format from search results if it’s not selected in the search settings. We had to use this filter because of some of our other configuration options. Perhaps this is responsible.

    I can tell you that this issue is happening for us on every single search. I think you’re correct that it has to do with the predicted number of results. We definitely need to fix this one as it is a very visible problem. I hope you can solve it!

    …..

    I think that covers everything…

    Thank you as always Ernest!

    ~ Michael

    #20087

    Participant

    Hi Ernest,

    Have you seen my response above? There’s no immediate rush, but I do need to complete these items since they are mid-project.

    I look forward to hearing from you!

    ~ Michael

    #20089

    Hi Michael,

    Sorry about the late response, I did see your requests. I was trying to come up with something for the content type/taxonomy request, but unfortunately I could not find a suitable solution.

    Content-Types in Titles
    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.

    Including the Post-Formats in Titles (In Addition to the Content-Types)
    I have updated the code. You will notice three new variables there:
    $display_post_format (true) -> If you want to display the post format
    $display_pf_post_types -> array of post types, on which the post format should be visible
    $post_formats -> array of post format slugs -> labels. You can add/edit format slug->label combinations here.

    I believe the rest of the points were discussed. Let me know!

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #20096

    Participant

    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

    #20130

    Hi Michael,

    Content type/Taxonomy titles
    Okay, I think I understand it now. You want to display your own taxonomy labels, instead of the ones that WordPress returns within the code.
    I have made a change to the code, there is an additional variable $taxonomies, where you can define taxonomy -> label key pairs. It works the same way as the other ones, where a key pair is found, the custom label is used.

    Notes
    a. Thank you, fixed
    b. There was an actual option a long time ago to limit titles, but it caused so many issues – some plugins used shortcodes, tags etc.. on title outputs, and it was a nightmare to manage that, as the visual length and the code length were different.
    Your case is a great example, since there are HTML tags in the final title. So visual title does not equal to the actual title. I resolved this, by implementing two new variables $title_limit_per_line and $title_limit_suffix. The length limitation is applied per line, before the HTML tags are appended, so that the characters can be counted properly.
    Please mind that it uses character count, not word count – but it will still cut the string at word endings, as I used a built-in method for that, not a simple string cutting method. The title $title_limit_suffix string is printed after each line, where the title was cut.

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #20156

    Participant

    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://”]
    “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

    #20192

    Hi Michael,

    Got it, you only want to restrict the original title (the first line). I had to look up a function to limit a string to words for that, I am not sure how well that works. You might have to pass this to a developer to review it.

    The $title_limit_per_line variable was removed, instead there is now only a $title_limit variable. Change that one to the number of words you need to reduce the original title to, before the additions.

    I have not overwritten the previous gist, so the new code is here:

    Best,
    Ernest Marcinko

    If you like my products, don't forget to rate them on codecanyon :)


    #20200

    Participant

    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

Viewing 15 posts - 1 through 15 (of 42 total)

You must be logged in to reply to this topic.