Showing results for tags 'search'.

A wide assortment of modifications to improve the search and stream experience including highlighted, navigable, search result terms on content pages, highlight text in some content areas to search that text, more precise search result snippets, faster results, and more. Searchlight Highlights searched-for terms on search results content pages. When your users click a search result link, the content page that loads with those results will have their search terms highlighted! SSSR has some major improvements over the earlier standalone Searchlight plugin. Marked terms can be navigated via a side-page navigation element that also notes how many marks there are on the page and which mark is currently navigated to. Admins can configure not only the mark styling but create separate styling for the "active" mark on a page. Version 4 of SSSR incorporates major improvements into the marking routine I've reworked the Searchlight functionality to effectively remove any double marks that would break the Searchlight highlighting and navigation, added more formatting options for the search mark navigator, and a few other things. SSSR now includes a toggle to turn the marks on/off and also will no longer mark out common small inconsequential stop words (the, a, an, etc...) when marking words separately. They are still marked when the full query term is marked out. Version 8 tightens up (shrinks) the size of the navigator a bit, is faded until hovered over on desktop, and also has a magic wand to hide/show the navigator (see screen shot for latest - gif above is older). I still want to do more here but we'll see if I get the time. Select-a-Search On comment content, which are any commenting areas in the Invision Community suite, most notably Forums, IPS provides a feature where you can select text and are then presented with the option to add that selected text as a quote in a new comment/response. SSSR piggy backs on that feature to allow you to instead search that selected text instead! Admins can just add the single option to search for the selected text as individual terms or as a direct phrase (quote). Better, and Faster, Search Results Snippets Invision Community pushes out the ENTIRE content item for every search result. This is then truncated down in your browser via JavaScript to a handful of lines. If your searched-for-term happens to be in those first few lines of remaining text, it will be highlighted on the search results page. SSSR does two things to mitigate this. Firstly, it will truncate the text on the server prior to pushing it out to the page. For very large content items this will massively improve page loads. Additionally, the my truncate process first looks for a matching term from provided search term and then truncates based on that position within the content item text. This works most of the time to provide search results that not only display fast but also provide content that contains at least a portion of the searched-for terms. SSSR skips common English stop words (Elasticsearch list, to skip common things like 'a', 'the', and so on) when looking for something to match. There are some edge cases so expect a few misses here and there with snippets containing matching terms. QuickSearch Filters INVCOM will display every possible search content area available to the user in the drop down filter. You can control which of these actually appear. Limit the choices here for a cleaner, more-focused user experience, remove little-used Pages databases, and so on. This only affects the QuickSearch top-of-the-page stuff - not the advanced search section where all options remain. Latest Searches in QuickSearch Option to present the latest searches from your community along side the QuickSearch dropdown menu. Searches are run through the word filter to prevent any naughtiness from spilling over (provided you are using the word filter). Display Modifications When users make custom Streams, all of their choices for content appear in the description underneath the stream name. That can be a rather large amount of text. SSSR provides an option to truncate all that down with whatever remains available under a 'read more' click. See screenshot. Gallery stream results can be quite heavy, often times loading in 15 or more images per Gallery item. That's a lot of weight for a page. SSSR let's you truncate that all down to whatever level you are comfortable with. When users are on the advanced search / search results page, they probably do not need to be told in the page title that they can 'Search the community'. SSSR provides an option to kill that and replace it instead with the terms searched for with the same appearance as the page title. Notes Make sure you toggle the Searchlight feature ON in the plugin settings. Same for Select-a-Search. Searchlight should work most places in most apps but Gallery has been specifically exceptioned OUT due to the post-pageload image popup modal. I might come back to that later. IMPORTANT! For select-a-search, this piggy-backs on the built-in IPS quote highlight function. That feature ONLY fires if a user is able to actually quote something in a comment area. That means it will not fire for guests if you do not allow guests to post, or any forums/topics where the member is not allowed to post, locked topics, and so on. SSSR is a reluctant sequel to the old Social Search application I had. I will probably be merging some relic stuff still remaining there with this plugin into a new app for the 5x series which will require a rewrite and may limit what is possible. Just a heads up.

Set Any Text Field in a Pages Database to be Searchable! How Does This Work? During the indexing process for an IPS Pages database record the field you have flagged as "Content" is processed by the IPS indexing method. After that is complete, this plugin checks that the overall item is indeed a Pages database record and looks for text, text area, and editor fields that are also a part of the record. If those fields have been flagged by you with this plugin to be included in the search index those areas are then collected, stripped of HTML elements to retain only the pure text content (Editor fields only), and then appended to the end of the initial indexed data (that field you have marked as "Content"). That field content is now in the search index and, naturally, searchable! For example if a Pages database content element consists of "Today is a good day to die!", and you have an additional text field where you allow someone to enter a day of some kind, for example, "Penguin Awareness Day", if you flagged that extra field as searchable, the indexed text for this content item will be: Today is a good day to die! Penguin Awareness Day Without the ability to flag these extra fields as searchable and then append their contents on to the content item search data entry, searches for Penguin Awareness Day will return nothing at all, which makes the use of Pages databases much less useful when you can only search for the fields flagged Title and Content. When does this actually apply? When records are saved (initial creation) and when edited of course. Also during search index rebuilds. What happens if I remove this plugin or disable it? Those additional fields will no longer be indexed. Any of those fields previously indexed with records will remain in the index until the record is edited again or you rebuild the search index. On edit or re-index, that additional appended text will not be indexed. I can't stop you or your other admins from doing... interesting things. This plugin does EXACTLY what it says, no more, no less. The plugin also is not psychic so when one of your admins decides to do some server work and disables this (and other plugins) but people are still making entries on the front end into a Pages database where you had extra fields marked as searchable the result will be pretty much what you expect... What happens if IPS decides to finally include this functionality themselves? Remove this plugin, do whatever is required of the new IPS functionality, rebuild the search index. This plugin only appends the additional text to the search index entry (which for Pages database records is whatever the content of the field flagged as "content" is, minus HTML code) and makes no actual changes to the record content itself. Why hasn't this been included by IPS before? Appending specifically? Permissions. Searchable fields in general? A structural challenge with the overall IPS content model. Explain. Every database field can have custom permissions. For example, you can create a bug tracker where there are publicly viewable fields and then other fields that only staff can see. However, there is only a single search index content entity that is searched - not separate searchable entries for every field. That means that every field you append to the search index with this plugin MUST be a field you want everyone to be able to see and search. When viewing a record those field permissions will of course apply, but with this information appended to the single searchable index entry you risk the chance that a search result will display with that formerly staff-only field and now everyone will know your admins are calling other members "buttheads" or worse. Be careful! For IPS to solve this, they would need to treat all additional text, editor, and text area fields as totally separate entities to be inserted into the search index. The management of that endeavor will require some engineering - it's doable but requires some choices to be made along with how to present the final search result. We didn't get additional searchable fields in the 3x line, not with the initial 4.0.x hotness, and with 4.3, 4.4, 4.5 now it still appears to be a distant dream. I got tired of waiting. For my use case I can write a custom app and deal with the problem my way, or I can just use Pages, append the two text fields I need searchable to the main content field with this plugin, and call it a day. Future development? Looking at filtering out content from being indexed by entering a regex equation. If the content of the field matches your regex, this plugin will not append it to the search index entry. This will cut down on search index spam if the text fields you are appending often contain repetitive entries and you'd rather just index out the more unique ones. Maybe numbers? August 2020: Those are still on the table but with only a handful of purchases all these years it's not a priority. If someone wants to throw some money at me to sponsor those features feel free. I actually use the regex tweak on one site but it's currently a simple hardcoded hack. OK, great, but I already have a massive Pages database. I installed this and set the fields I wanted to be indexed in this database. I get that new records going forward will have the field values added to the search index but what about old records? You can click on an option in the plugin settings and fire off a re-index process for the database you select. This will re-index everything in that database and with this plugin enabled and those fields flagged as searchable, those fields will be attached to the content item search text and included in the search index.