All Astronauts

Probably another day or two before approval so hang tight. Also for those watching I'll probably let people set the quicksearch default to whatever they want in the next version after this - I just made the option for forcing Everything without thinking anyone would want to hard-set it to anything else. With the IPS current policy of pushing big changes asap you can probably expect said changes breaking more 3rd-party stuff with any point release going forward. You'll have to pay attention to the app/plugin description for any point release warnings since we can only flag out major versions and not the last point.

@HDiddy 4.7.1 has changed up the underlying code for generating those Quick Search (QS) options so do not upgrade yet if that is important to you. Otherwise... SSSR 7.1.0 to be submitted probably this evening some time: For Invision Community 4.7.1.x + due to underlying 4.7.1 changes FIX! Quoted search terms that had a comma within that quoted text were breaking Search Light, only marking the first portion of text up to the comma. This is fixed now. REMODELED! With the new 4.7.1 Quick Search I had to revamp both the latest searches appendage AND the search filter filter stuff. All good again. NEW! That new 4.7.1 Quick Search FORCES the default option to whatever content item you are viewing. SSSR now provides an option to force it to Everything all the time. The utility of the latest searches next on the QS dropdown is a bit lessened with the whole minimal thing going on. For now I've patched it up to still work along side it but I may just make an optional micro button thing along side the QS to just pop up popular searches, latest searches, etc... some time down the line. This is also now limited to displaying the latest ten searches. Caught a bug with the Search Light marking - if you made a quoted search, and the quote itself had a comma somewhere in the text, the mark was breaking at that point and not marking anything after that. All patched up. And, with the latest QS changes, it is now forcing the QS area search to whatever app you are in instead of everything. I've got an option already set, tested, and working, that will force QS to ALWAYS default to Everything for the search. If you are in a content item the contextual search area options (this topic, this forum, etc.) are still there in the dropdown to choose, but Everything is still set as the selected option.

Good deal. FYI, with the new 7.1 changes inbound on the Quicksearch I'll probably have to do some poking - have not upgraded locally yet to 7.1 but have looked at the files.

502 bad gateway when clicking this: And then moments later it is working again... Disregard, carry on, etc., etc...

Naturally, this will not be compatible with 4.7.1 given the quicksearch changes. The quicksearch filter is probably ok (either as is or a quick fix on my end) but I'll have to think about the latest searches along side.

Pages Category Images is good to go as well. Upgrade away. I did submit a new version to the Marketplace - 4.1.0 - the only change is adding in a template that displays beneath the image upload field providing the ways you can use this stuff - and of course flagged the file out for 4.7 compat.

Pages Searchable Text Fields is fine on 4.7 - I resubmitted a new 4.0.0 version to the Marketplace so I could flag the file out as 4.7.x compatible, but other than the version number the plugin is the same - though I think in the next version I'll stick a flag in on database fields view so you can see that a field is flagged as searchable or not. Looking at PCI now, should be back here in a bit...

Poked. I had to increment the version number from 20.0.0 to 20.0.1 for the resubmit. Other than that, the file is identical to what you have now. All good.

4.7 is mostly a nothing burger internally. Some rejiggering for CIC stuff, bugs stomped, etc. so this is probably perfectly fine as is. I'll have to resubmit to get it flagged up for 4.7 though. A lot of us are taking our time with this release; mainly since there is no reason for any of our things to be broken. I'll poke it tonight and report back.

Viewers 2.0.0 Submitted! NEW! Pages application now supported! Both Custom Page views and Database Record views. NEW! Blogs application now supported! Blog entry views. NEW! Added Member Data Export for Pages Pages, Pages Database Records, and Blog Entries for GDPR compliance! ENHANCED! Adjusted all Member Data Exports to match native IPS data export date formatting! EXPECTED! 4.7.x compatibility sweep. etc... As stated earlier - Pages Pages, Pages Records, and Blog Entries are only widgets for the time being: Drag and drop widgets are locked to their respective "thing". Blog Entries will only show something on Blog entries. Pages Pages will only show on basic pages. Pages Records will only show on record view. Yes, databases live on a "page" but that is accounted for. The GDPR member data export stuff is all set with the new stuff as well so those of you in affected areas, or just needing to comply with user data laws of some type, can rest assured you can dump this stuff will no problem at all. Available when approved.

Submission will be tomorrow sometime (looks previous posts, laughs). I want to sleep on this before submitting and give Daniel and Stuart a break from any derpy things I may be doing in my sleep-deprived state. Large picture: Some of the deeper management things I'm skipping for now - specifically, building out the member view in the ACP - that is still locked on displaying only Forum Topic member view data - though the button that will let you cull out a single member's views lives there (that's new to 2.0.0 - go to the member's page in the ACP, click the Viewers tab, and you can cull what you like there). Also the Pages and Blog stuff is entirely widget based - no modal popups yet. Blogs will be an easy add, but Pages... that might end up being me giving you a bit of template code you will need to insert. While poking this bear, I've come to the conclusion that the cached widgets really don't help all that much so I'm thinking about adding in some form of datastore caching specific to Viewers. I gave the GDPR member data export stuff a once over, tightened up some spots, and of course, it covers all the newly introduced stuff. Works well. A reminder as well that I do log out when stuff is getting messed with. On topic view mods have an option to wipe the viewer data for that topic - that gets logged to the moderators log (who, what, when). The larger data wipes - all content item views, all of a members views, get logged to the administrators log (as those occur in the ACP) Thinking about Gallery. Albums are an easy add. Images are as well to a point but I'm wonder what the value of recording individual image views would be, and also there is the fact that image view defaults to the popup modal and I'm struggling to see where I can insert anything of value in there without it looking like a hot mess. Lastly for those of you wondering if this can be a universal sort of thing for 3rd-party apps, the answer is yes - provided they are serving up content items - I'm using separate tables for convenience right now but a universal table wouldn't be that crushing (just store the content item class is all) - especially if we are bypassing forums which we would be already. The only hitch is where to catch the view - if the app is really straight forward and rides the IPS rails the view data should be correct. If it starts doing wacky dispatcher or output things, or is loose with permissions, the view data will be wrong and you can get members recorded as viewing things they never did and if you are modding based on this stuff I want no part of THAT drama at all...

Almost certainly. I'll test both of these (they are separate things) later today and report back. I have to resubmit the files regardless if there are changes or not to get the Marketplace to flag them up for 4.7 compatibility officially though so that will take some time.

FYI I'm also including Blog Entries as well. Taking some time to put in some management things - you can already wipe all the data and start over, but I'm adding in the ability to wipe any of the specific things individually (topic views, record views, etc.) and also sticking in the ability to wipe an individual member's views. Submission should be today sometime...

<gentle prod> I mean, its not the end of the world, I can just change the extension class name to what it should be and add the entry manually to the extensions.json file. Just weird still hitting this.

Update for 4.7 will be submitted probably tomorrow, includes support for tracking viewers on Pages Database Records and plain, regular Pages Pages.

I totally forgot to make the support topic - derp.

7.0.0 Submitted! Available when approved... NEW! Last Searches made by community members added alongside Quicksearch! NEW! @HDiddy Your Quicksearch filter filter has arrived! CHANGE! The remove content item icon from search results has been expanded into an emphasized search results view option. 4.7.0 compatibility sweep. All good. 6.0.0 users are fine as well. This is an option in settings. Toggle it on and the last searches made by your community members will appear here. Unlike Social Search, I do not believe I am running these through the bad word filter - these are a straight pull from what IPS is saving as searches now. Yell if that is a problem. Otherwise, as long as you have searches this will populate nicely. Looks good when QS is not expanded, the results will pile in when it is expanded. There is a hard-coded three-minute cache on these terms. So after three minutes since the last build, the next Quicksearch user (or more likely page load) will rebuild the cache and so on - so your DB load is pretty much nil on this. This has been sitting in this plugin since December/January I think; sorry bout that. Anyways, as stated above, when you have a ton of pages content every bit gets jammed into Quicksearch. You can toggle some of them off here and just present a lean QS experience instead of overwhelming users with options. This affects the QS EXCLUSIVELY! Users using advanced search will still get all the options they can handle. As for the emphasized search results option, this: Becomes this: No more superfluous icons and photos, slightly enlarged search result text, margins and padding adjusted to fit. Everything is working as before in 4.7.0 - oh, though I did make an adjustment to the search marking terms cookie auto-destruct time. When you click through on a search result with Searchlight enabled, your search term comes through on a cookie that is made on the spot, then read once your content page finished loading, and then is wiped out just as fast. I had it set to autodestruct after 8 seconds just as a safety catch but ya know, if you have a content item loading in that is - oh - say - maybe 1/3 of a book text? A really thick book? It takes time for a DB to grab that blob, and then it takes time for your browser to dump all that text into the window. Unlike when IPS was doing this with search and stream results (remember the whole point of this mod initially?), we do want all the text of the content item to load in. But time. Yeah. 8 seconds was not enough so Searchlight would not run if the page took longer than that to load, which it did on one of the sites under my purview. That number is now 16 seconds - maybe more. So, on the off-chance you have massive content items that Searchlight was not firing on to mark out terms, it probably does now 🙂 BTW I'm way behind checking out my apps and plugins for 4.7 but I really do imagine everything is perfectly fine for upgrading if you don't want to wait.

For those following along at home, Plesk vhosts have their own individual php.ini files, so the overall system php.ini may not have open_basedir set, but those might - and for Plesk, do by default. They lock down PHP processes to the website directory, and the system /tmp directory. Change it in the Plesk vhost panel whatevers to allow /proc, (and restart PHP), and all is well.

Yep, either proc was not mounted (again, insanely rare), or your web user does not have any access to proc. Shoot me a PM with your server provider (not here, IPS will remove posts discussing specific server providers)

Take that back, I bet you don't have /proc/meminfo, or access to it at least. /proc/uptime as well. And even maybe proc/cpuinfo. In fact, you probably don't have access to proc with your user account - that or proc wasn't mounted (rare I think) Click the details button on that widget (lower right) and see if there is anything telling you what cpu you have - that and there should be additional tabs there as well. If they are missing, you need to give your user access to the proc directory

Bring up tasks in the ACP (there is a link where you set how tasks run) - look for spaciousServerStats or something like that - run it. Still problems after that, give me a yell. EDIT: Also, based on that screenshot, I have other questions...

It's not that hard to change the configuration. Elastic is still a better option though.

And I just skipped the toggle altogether and opted for just an admin check. If admin, no limit.

Alright I'll add an admin override and skip the group stuff, just a yes no toggle for admins unlimited

We got rocked with storms late afternoon yesterday and I'm going to take advantage of these next-day high winds (less bugs, great noise) to hit the trails to go running and see the damage so that's me saying I'm too lazy to look right now (on phone) but I'm pretty sure KS has this setting already, just not as a per-group setting. Which would be doable. We're talking about the same thing?