Showing results for tags 'pages'.

Those of you doing serious custom work or jumping into other clients Pages installations to design, patch, change things in templates - especially heavily customized forms - probably want easy access to the database field id numbers. Database category IDs as well. Here you go.

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.

Add an image to every Invision Community Pages Database Category for use in your templates! Any settings? Nope. Just install and go. When editing/creating a category in an IPS Pages database this application appends a new tab where you can upload an image. That's it. Where do I add these images? What I just said. When you create/edit a Pages Database Category, there is a new tab where you can upload an image. And how do I use this? Any code examples? Images are stored wherever you have set the Pages Category Images file handler set to store them and you can access the image anywhere the $category variable is available to you in Pages templates. $category->pcimage = The local url to the stored image. You will rarely use this by itself as it will return "uploads/monthly_07/thisismyimagename_34erjfhrufhdheh.jpg" or something along those lines. {file="$category->pcimage" extension="pci_PagesCatImages"} = The COMPLETE url to the stored image. "https://myawesomesite.com/uploads/monthly_07/thisismyimagename_34erjfhrufhdheh.jpg". Just sticking this in a template will output that as a line of text. <img src='{file="$category->pcimage" extension="pci_PagesCatImages"}'> = The image will be displayed in your template at this location at full size. If you are in a record view template where you have the $record variable, just swap out $category in the above code for $record->container() - for example: <img src='{file="$category->pcimage" extension="pci_PagesCatImages"}'> becomes <img src='{file="$record->container()->pcimage" extension="pci_PagesCatImages"}'> You get the idea. From here you can format the image with css, use it as a background element, and so on. NOTE: It is ESSENTIAL when using the {file=...} code that you include the extension="pci_PagesCatImages" within. If you are storing your PCI images on Amazon S3 or any other external server, that extension line ensures you are getting the correct url. Without that, the url generated will always point to your own webserver and externally-stored images will not be linked correctly. Why am I using this again? You can give every category its own image. Format it like an icon and stick it next to the category title in your templates. You could create a large section background for your categories using this image. And so on... Why $category->pcimage and not just $category->image? If IPS ever adds something like this to Pages database categories themselves I predict with 99.999% certainty they would use the word "image". I added the "pc" in front to hedge against that potential future conflict. What happens if I disable this application? Nothing in your templates will break completely, you will just have missing images in those locations (with whatever the browser sticks in to indicate a broken/missing image). And if I uninstall this? All of your uploaded images will be deleted of course. Consider that you will be editing your Pages templates to add calls to these images too. You'll need to edit your templates to remove those calls after you uninstall this. What if I change the file storage handler for these images from, for example, local storage to S3? The files will move just fine, and normally there will be no broken links. However, the Pages databases page in the ACP, and every database's category page in the ACP has a button at the top of those pages that will let you reset the Pages Category Images datastore cache. I have a broken image displaying and when I look at the page html code the img link says NOIMAGE? 99.99% chance you do not have an image set for that category. You should set one. Did this used to be a plugin? Yep. Now its an application with a proper file handler. I have the Version 1 plugin now should I uninstall that or...? DO NOT UNINSTALL THE PLUGIN! You'll lose all of your files and have to re-upload them again. I've set up the install routine for the new application to handle it all for you. Install the app just like any other app and it will automatically take over the file handling from the piggybacked core_Attachments handler, remove the plugin uninstall routine that would normally delete your uploaded images, and then uninstalls the plugin for you. If for some reason you install the plugin again afterwards you're on your own... Seriously, delete any copies of the plugin you have lying around. Only bad can come from those being used after you've installed the app.