Scott

Punch up those member hovercards! Expansive backgrounds! Yearbook Quote feature! Let your members flash some personality and drive member engagement! Profile Fields available for use on the hovercard! This mod swaps out the usual member hovercard for a new template; one that emphasizes appearance and personality instead of just dumping profile information in a list which they can get by just visiting the member's profile anyways. What's there? Big full-sweep coverphoto (support for default as well), all the new badge stuff, registration, online status, and more. Where's that image coming from? That's the member's coverphoto! If they don't have one the Invision Community default profile background stuff is used. Yearbook Quote Feature? Although I debated sticking in a member's status update as the centered text, there are too many reasons not to, including not everyone is using status updates, often times those updates are throw-away notes about nothing, updated rarely, and so on. With a specific quote feature your members have the opportunity to flash some personality - be it describing themselves, Tinder-like blurbs, using a quote from a movie or video game, and so on. Why not use the About Me feature from the profile? That's a full editor field - images and lots of other things can go in there. This is meant to be simple and direct. Can I change that name to something else instead of Yearbook Quote? Yep! In settings. Hoverboard Quote, Hovercard Quote, Quote, Say Something, Tinder Blurb, whatever... Call it what you want! Is this stuff also on the profile pages? Yes - it's also where they add/edit it. Click the gear icon to have at it. Can I use the Yearbook Quote feature but not the new fancy hovercards? Sure. You can toggle on/off the use of the new hovercards in settings. To completely disable everything just toggle the plugin off in the ACP. Profile Fields Too? You bet! Select which ones to pass through to the template (admin-only and editor fields excluded at the moment). See the support topic for how to customize the display of these. Fields with short (length) text will work best here. All the little content bits are in flex-boxes, including your profile field adds. Look at the screen shots to get an idea how they will flow in. What are "Click Cards"? You can actually disable the hover functionality of these member hovercards. When you do that, users will need to click the member avatar to trigger the display of the card. When the cards are set to hover-mode, they appear when the mouse cursor hovers over a member avatar and these will, since it is a mouse hover action, only appear to desktop users - tablet and phone users never see these cards. When you toggle the cards to click functionality that covers tapping and these will now display to tablet and phone users just fine. This is a usability decision to be made by you and you alone. If you ask for my opinion I'd consider how many of my visitors are tablet/phone based before enabling this feature. If you have more mobile than desktop, go for it! You can always turn this off later. Version 5 adds the ability to apply this functionality to the user names as well. Moderation? Of course. If a member has not entered a quote yet, the box will appear only that member and no one else (mods and admins included), with text telling that member to add a quote. Once a quote is entered, the quote will appear to everyone AND mods and admins will have to power to also edit those quotes. Mod permission is being able to edit profiles, if a mod has that, they can edit these. And yes, mod/admin actions on these items will appear in the Moderators Log in case you have some mods/admins deciding to mess with people instead of actually correctly moderating inappropriate content (whatever that is for your community...) Anything for moderators? Yep! Banned status, posting restrictions, and the like will display on the hover card to the member themselves if they are viewing their own, any moderator with the power to view reports, and all administrators. Anything in the ACP? Other than the plugin settings and entries in the Moderators Log, no, nothing in the ACP Member view or anything like that. All moderation takes place on a member's profile page in the Yearbook Quote block. If you have a member who continually abuses this quote feature by inputting stuff you don't want, the solution isn't adding more permissions to disable this feature on a member by member basis - the solution is to ban the member. Anonymous Users? Yes, accounted for. Anon users can browse with little worry of being "found out". Customs Available? Sure! Some communities may want some community-specific information to appear on the hovercard. Not a problem. Expect to pay a (nominal one time fee) if it is something that can benefit all users of this mod in which case you are sponsoring a new feature for everyone (and paying to get it done now instead waiting for me to get around to it) or a (one-time fee X 2) for a mod specific to your community only, provided it is doable.

Modifications for improved Non-Amazon S3 service providers, primarily allowing for the correct download of attachments. Tested with Backblaze, Wasabi, DigitalOcean, iDrive, etc. Service Status ACP Dashboard widgets for Backblaze, DigitalOcean, and Wasabi. New Region Setting on S3 Storage Settings: If you are using DigitalOcean or Wasabi, toggle the new "set region" to on, enter the region you have set for your service, and save. If Invision Community displays a pop-up modal warning you that you are making changes and it will init a move process, choose the option stating I already moved the files. All this setting does is aid the IPS S3 code which defaults to Amazon us-east when manipulating S3 things when it cannot detect a region correctly and it needs to. If you get to choose and set a region for your bucket, enter it here. This is NOT essential, but it could be useful if you run into problems (provides certainty) ACP Dashboard S3 Service Monitors: Available for Wasabi, DigitalOcean, and Backblaze. If there is a hew and cry for Vultr that can be written out as well for a future release. Widgets display region and occasionally other service-specific availability (online, impacted, down) along with service alert and status text if available. For services with a history function regarding alerts you can configure how much is available in the widgets in the S3WB settings. In most cases the alert text is truncated with an expand toggle to see the rest if needed. See screenshots. Service logo buttons link to what would be your account or configuration pages at those services. Willing to add additional monitors for other providers if there is a need, and they have something to get on that front (iDrive does not). Code-modifications allowing the correct downloading by users of attachments and Invision Community Downloads file downloads: Simplified header information mostly that fixes signature-breaking structure present in the code. Note that this is due to alternative S3 providers not being fully compatible with the Amazon S3 calls IPS makes by default. For Backblaze I bypass all S3 calls and instead utilize the Backblaze API system for users to download files. Why: The built-in S3 file handling system in Invision Community is programmed exclusively for Amazon S3. Although this DOES work with alternative S3 providers, most of these providers have quirks of their own that break full compatibility with what IPS provides. I wrote out a hacky plugin years ago to address some of these things, and even though that plugin still works, the actual plugin itself has not been updated for at least three years and was last flagged as compatible for the 4.5x series of Invision Community. We're a long ways away from that time, both with the IPS codebase and the S3 providers themselves. As we near the end of the 4x line I thought it was time to get this all updated to something relatively stable and more useful than a plugin. Testing: I have tested Backblaze, Wasabi, DigitalOcean, iDrive, and many months ago Vultr (don't hold me to that one but it should be fine I just don't want to spool off $5 to test again). I should point out I DO NOT make any alterations to the majority of the internal IPS S3 code. Testing included: Moved attachment files from LOCAL STORAGE to ALT S3 SERVICE Uploaded a new attachment Tested downloads worked correctly for attachments Moved attachment files from ALT S3 SERVICE to LOCAL STORAGE. Confirmed files were intact and downloadable. Moved Invision Community Downloads files from LOCAL STORAGE to ALT S3 SERVICE Uploaded a new Downloads file Tested downloads worked correctly for Downloads files Moved Invision Community Downloads files from ALT S3 SERVICE to LOCAL STORAGE. Confirmed files were intact and downloadable. Testing was usually with 10 to 20 meg PDF files and of course the usual embedded images in posts (which are attachments) and all that was fine. If you are uploading massively large files it is up to you to investigate whether 100meg or larger files work correctly with these systems. This gets into the realm of chunking and your PHP/Apache settings and the like. Not my problem and again, nothing to do with this code at all. You'll also notice I did not test with CDNs. Way beyond the scope of any of this. The old plugin is working fine with CDNs if configured properly; you'll have no problems here either - again, the PRIMARY FUNCTION of this is to patch up attachment downloads and makes ZERO CHANGES to anything else. Lastly, transfers from one S3 service directly to another S3 service were not tested. Again, nothing to do with this application. If you have a substantial amount of files to move between storage areas, you are better off using other dedicated tools and then flagging changes to the file systems as "I already moved the files". Backups are not a bad idea either... The above testing was two fold: to confirm the attachments downloaded with S3 Workbench, and that the services nominally worked. The former was required; the latter is a courtesy. Requires: cURL for Backblaze (The 4x line still allows fallback to sockets if you are running an ancient cURL version but the BB stuff is all cURL). You should know how to configure S3 in general. Invision Community Downloads: If you are using this IPS application, S3WB does work with those file downloads (and unlike the old plugin, no longer FORCES them to be public files) but if you absolutely MUST have those file downloads hyper-secure be sure to use your local storage or Amazon S3. If one of these downloads files is an mp3 it will probably load in the browser directly when the user grabs the "file". This is all the same code to generate the URL as regular file attachments, but it appears to be more sensitive for "reasons" that are not worth my time to track down. I know why this happens, but am unsure of its uneven application (pdf's I would image would load in the browser the same but they do not). Additionally, some of the alternative S3 services out there do not do file-level access control (e.g. flagging a file as private) but instead do public and private buckets. I'd just point out that once a user has one of your "private" files, they can do what they want with it - including sharing it it, re-uploading it, and so on, and there is nothing you can do about it. So, again, if this is all hyper-important to you, just use local storage or Amazon S3, otherwise, really, it's fine. Service Specific Notes: All the settings below, including bucket names, are obscured/fake but the configurations are correct. Provided as a courtesy. Backblaze: S3WB uses the Backblaze API, not the Backblaze S3 implementation, for file downloads. An additional change is dropping the amz-acl header calls when a url is doing something with Backblaze - the service DOES NOT WANT ANYTHING TO DO WITH acl. Works great and I'd be fine recommending these guys. Crazy stock price crash since listing, though prob a buy opportunity right now (Mid-June 2023 it's $4 something, it's $5 something mid-July, expected to do $9 something). bucketname: muhbucket endpoint: s3.us-west-004.backblazeb2.com access key: abcdefg1234 secret key: abcdefg1234 set region ON region: us-west-004 Wasabi: Solid. The one that started all this mess years and years ago. I'd consider them stable now; in the 99%'s, which is kilometers (or miles if you prefer) better than they were on initial launch. I still have a $5/month account with them (that's how early I got on the wagon). bucketname: muhbucket endpoint: s3.us-east-1.wasabisys.com access key: abcdefg1234 secret key: abcdefg1234 set region ON region: us-east-1 NOTE: If you are using s3.wasabisys.com for endpoint (which is us-east-1) you can skip the region setting here. DigitalOcean: Not the cheapest but some of you may be in the ecosystem so here you go. bucketname: muhbucket endpoint: nyc3.digitaloceanspaces.com access key: abcdefg1234 secret key: abcdefg1234 set region ON region: nyc3 iDrive: Fairly new on the S3 front, as a company, around a LONG time. Very inexpensive. Configure as follows: In your iDrive control panel, create a public bucket. Then click the gear icon on the bucket in the bucket lists. Get the PUBLIC BUCKET URL! - it will end with .dev - the part WITHOUT your bucket name is what you want So if it is this: https://muhbucket.w8q1.c19.e2-1.dev Then when setting up the new storage setting this is what you use: Bucket name: muhbucket endpoint: w8q1.c19.e2-1.dev access key : whatever secret key: whatever set region: OFF With ALL of these services, please test. Your circumstances may differ and I offer no guarantees. Just covering my support posterior. Again, this a couple tweaks to allow attachment downloads mainly for alternative S3 providers. The core S3 code is still all IPS. S3 Compatible Downloads Users: If you are happy with the old plugin, it still works - and remains working on many sites. The code here is a little bit better plus the Backblaze API downloads bypassing any S3 problems that might be encountered. The last version of S3CD was for 4.5 so if you are looking to get something more up-to-date, support the dev, and get some nifty support widgets, purchase this, make sure it is enabled, and then delete the old S3 Compatible Downloads plugin. That's it for upgrading. I should also note that I do not have any of the hacky http insecure link support here, and those of you with wacky bucket names need to get religion on that if you want to upgrade to this. I'll listen, but support on those fronts is gonna be a wait-and-see-maybe sort of thing. It's not 2015 anymore. Status Widgets Heads-Up: These are scraping, parsing things - either the status pages themselves or the, becoming more rare by the day, rss/xml feeds. If any of these guys changes things up, the widgets will break (or rather the underlying data will). I'll be patching these things as they occur. This app has actually been running on my sites for a couple years now and I think I've had maybe one or two breaks in that time across all the widgets. Invision Community 5: No idea at this stage what is and will not be possible here. Most of my applications will be new purchases for the new framework but THIS ONE, if it is upgradable to the 5.x line, will just get the 5.x version added in to the mix for this purchase.

Use this to verify you are making the proper connection to an Invision Community API endpoint. If you need to get an API connection up to speed, this is your tool. It only uses GET calls, no POSTS. And there is no OAuth testing either or anything beyond what the label says: API testing of GETs. Once you have a simple GET call sorted, the rest is on you and should be simple enough now that you have the basics out of the way You can use this to query the APIs live on your own localhost machine. You can call from localhost to a live site. You can call from livesite to livesite. This is a devtool but it it is perfectly safe, and firewalled, for use on livesites where you might need to track down some connection problems. You can have as many copies of this widget on a page as you like! Test separate individual API calls with each one! ICAPIT is also fantastic for testing your own API rollouts in your applications if you have never made those yourself before. Set up your application API code, give yourself a key and the proper permissions to it, and just call it from the plugin and see what you get! Not only that but you can look at the response modal to see how the exact call was made at the code level. Nothing fancy here; copy-paste as you need - it's all basic PHP code. Great for when you are needing to READ from the Invision Community API. Every step of the way, you should either receive the correct JSON response, or a myriad of error responses which will aid you in tracking down your problems. One tab is dedicated to all the possible error responses the Invision Community API puts out internally - no need to go looking for what they mean, they are all right here. FYI this code is an INTERNAL tool for myself so if you poke under the hood you'll see a LOT of copypasta so leave me alone and you're not my supervisor. It gets the job done quite well. User MUST be in the administrators group to view this plugin. Do not install it, drag it onto a page with someone who has widget permissions but is not an administrator and expect to see the widget/s. Same if you are not logged in as an administrator. For each instance of the widget: Edit the widget's block configuration to enter your API key. API keys displayed in the widget or results modal will only show the first four characters for safety if you are using this in a public setting and someone glances over your shoulder and so on. Click the Configure API Call button on the widget to configure the actual API call. This is where you will enter the site URL, the API call, and set various options. Click the Make Call button to make the call. A results modal will display on the screen showing you the results of the call. To make subsequent calls with that particular widget you must either change the Configure API Call settings and save or refresh the page. If you are encountering problems or spurious returns, make sure to use the direct cURL option in the widget settings (as opposed to the IPS wrappers). This will provide you with the cURL error output which can be invaluable as not all the error responses will be the clean, sanitized, canned IPS API json responses. As an example, your local dev machine will probably have a self-signed SSL certificate. There is a setting that allows you to disable SSL checks when making an API call, and you will need to have this enabled when you are using this to read APIs on your own localhost. Don't believe me? What happens if you turn that off and do make those SSL checks on your local machine with the self-signed cert? Well that "0" is not too helpful for a response. However, I made that call with direct cURL so let's look at that last tab... There you go. I can see many avenues for improvement and expansion with this tool but 5x is inbound so I'm content to let this sleeping dog lie and see what's what in a few months. If you find it useful, I'm glad you did </rattles tip-jar>. Any hitches, questions, and the like, hit the forums. By the way, I do have a companion to this, a plugin that you install on the server where you are reading the API from, that lets you dump $_SERVER output to the system log when the authorizationHeaders() function is hit, which is only hit when API and OAUTH calls are made to the server. You can set how many minutes it will log these for which gives you enough time to turn this logging on, and then hit the API with ICAPIT (or any other way you like) once or however many times you like, and catch those $_SERVER outputs for debugging. I used this to spot missing or malformed headers, bad encodings of credentials, etc. You are probably in the weeds if you need this (or the server you are doing work on is...) so just give a yell and I can add that tool to the freebie pile (after I dredge it up from the 4.5 dev installation lying dormant somewhere around here...) Lastly... This plugin does require you to have your server more or less configured correctly. If you half-assed setting up friendly urls in .htaccess or nginx confs, or have made a mess of other things, don't expect this plugin to magically tell you what is wrong.

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.

Dev Mode on, Dev Mode off. Dev Mode on, Dev Mode off... Configurable on/off icons, alter the colors for the "in development mode" flaring on the left of the ACP, etc. But wait! There is also constants toggling on/off while IN_DEV! The only hitch is you must FIRST add the constants you use/want/need in to the constants.php file manually. A safer, more clean, experience all-around - otherwise I would have to prep every constant available and most of them no-one ever uses. Again, this toggle power is only while you are in Dev Mode. This is a dev tool; not a live site one. This was the first ACP flip-switch for dev mode. Prior to this plugin you would need to edit constants.php every time you wanted in or out of dev. And yes, just like the old Marketplace listing said, I was way drunk when I wrote this. But that was the initial version. All of the subsequent releases I've been quite, quite sober. Probably.