All Astronauts

Okee-dokie. So, for this to work, I had to add another hook so I could merge the two cookies I have into the essential cookies array. FYI these two cookies exists for, honestly, just a few seconds. When you are on a search results page and click a result to go to, its sets one cookie saying "Hey! Time flag some query terms" and the other cookie is those query terms. Once the content page you clicked to loads, the cookies are read, and then immediately removed. Can't get much more benign than that! And the search light search terms highlighting is working on the latest - except when you have a single hit - if you have more than one hit, the term navigator appears on the side, but not with just one term - so I need to look at that (probably just a poor eval on my part now). These two cookies will appear in the cookies list as well: So, I gotta patch the whatevers first, and then this gets submitted. No idea when the update appears. I imagine there will be a flood of app/plugin updates with the cookie changes. Oh - I'll check the truncate stuff now - hang on... EDIT: Yep - truncate works great and everything is perky.

I put the truncating in long ago, then IPS did their own so I took mine out, then they took theirs out so I put mine back in. Worth a look at least to see if there has not been any silent changes there. Give me a bit.

Without looking I'm betting it's all the cookie stuff that was rolled out in the latest version. Did you enable the cookie consent stuff?

@SJ77 This plugin will NOT be updated. It's old hacky whatevers. I mean, it worked - right? But time marches on. People are still using it just fine though so if you have it carry on and so forth. However... New thing submitted tonight if I feel it. IPS approval time runs about a week if there are not any problems (and Daniel and/or Stuart are not crushed with other work). Then you can give me some money. Backblaze, Wasabi, DigitalOcean, iDrive. Vultr too (if you count tests ran six months ago - I don't wanna spin up another $5 to check again). All tested out. Things are still derpy but more professionally so. Everything still piggybacks on the internal IPS S3 code. Oh, and Backblaze is solid (I bypass the S3 stuff and use the BB API directly for attachment downloads). And since those guys finally pushed out a status page (albeit a not-too-great one) you get this too: Obviously a new support topic and so on but that will come post-release.

Tons of icons on a page can weigh things down pretty fast if you are not careful to limit the number displayed (even with caching on delivery and in browsers) - but yeah this isn't a big deal. To be compatible with the above he'd have to target this plugin specifically (those IPS widgets are doing things different in each one) - but to just show icons and what not st a nothing burger.

@Deep Blue 76 PM me ACP access so I can take a look. Working correctly here.

T'was approved Tuesday. 20.0.1 Maybe find whatever task updates the MP stuff and run it manually?

data-ipsLightbox-group='g{$indexData['index_id']}' Elasticsearch never returns that in the $indexItem array. IN_DEV this will Whoops with missing array element when using Streams or Search. Live it functions but image groupings are broken. Quoting @Martin A. "meat mixed with stats" (lamb chops with hard drive metrics to be precise) The images will display correctly in the snippet, but when you lightbox them out and navigate through them, with a data-lightboxgroup="g" value instead of "g12345" its grabbing all the images on the page and you can navigate through them all. Apparently, (@Martin A. looked here as we troubleshot this just now), MySQL is clear here and returns the index_id in the array. If anyone here is having problems and selfhosts (and is using Elastic) you can patch this by changing the template bit there from index_id to index_object_id (or index_item_index_id perhaps) which is present in the $indexItem array returned via Elastic. This can either be patched in the code to return the correct bit in the array if Elastic is present, or one can hack at the template like we did. There's also the smallest of possibilities of a collision between different apps returning the same item_ids but that's something for IPS to hash out if/when this gets patched. Locally this is Elastic 7.2.0 if this matters.

ol.ipsStream li.ipsStreamItem:nth-child(2), ol.ipsStream li.ipsStreamItem:nth-child(4) You will need to adjust the nths as needed. If things are off by one or whatever, again, just adjust the numerical nths and move on with your life. The above inserts after 2 and 4, and is firing after 1 and 3 - that's because that timeline "earlier" thing is a LI element and is being counted. Like I said, just adjust numericals there and move along... Two things: Be sure to set a position (before, after, etc.) in the radio choices for the ad - I do not have that field marked as required and its not auto-filling a default choice (at least locally) - I'll patch that for the next release - don't be like me staring at the output wondering why its not working and then discovering the above reason as to why. It's not pretty 🙂 The other is when entering more than one CSS selector (like I have above), you do comma sep them, spaces after the commas are fine, but do not have a trailing comma - it will err on that. Again, I'll make sure to clean that on the next release and prevent that by default. Heads up that the CSS above will cover search results as well as streams. If you need to NOT have search results here yell back or figure out the more specific targeting yourself.

Just use the simple css method in Ads Everywhere. I just woke up, Let me gullet some coffee and I'll give you some basic targeting to use here

You can use it as is just fine. If you HAVE to have the template parsing for random template logic and the like I'll... have to revert some code and then push the 2.0 again See, they rejected that 2.0 update saying that the parsing of output (server-side) I do was "too heavy", at least they "thought/think" it was... Thing is, that output parsing was already released in a previous version - the one available now if you purchase - and its not really affecting anything really - currently running on one fairly heavily trafficked site with no impact. Oh, I can see how it might impact things but its really not much different than what they do with emojis. So, when that rejection came I just thought I'd let things lay as it were and get around to "fixing" the update eventually. That said, the initial release of Ads Everywhere had everything inserted via Javascript post-output. Which is what they want now. Which is fine, I just have to revert a bunch of changes (pita but no biggie) and tweak some other things. If I go back to making all the ad inserts post-page load, there are some ad providers that can't handle that (Monumetric for one): they see an ad pop up in the DOM, they run the ad, and their code stops - it's not DOM-aware enough for another ad being inserted (or more) - hence why I did the output parsing in the first place so the ads were in the document on output and the ad network JS code would fire on all of them. Neat and tidy, no mess, no fuss. When I do push the reverted all-JS version of 2.0, this means to accomplish this, I gotta tell everyone that the ad network JS code they typical stick in the header - they will probably need to specifically use my Ads Everywhere header block now for that code (leaning towards MUST). Because in order for the Monumetric (others..) ad networks to work in the revised version is for me to JS insert all the ads into the document and then LASTLY insert the core header JS ad network stuff so that it fires off on all the ads. tldr; Unless you need to parse things like member variables and custom Pages blocks and stuff like that, go ahead and buy now and have fun. Otherwise, my skies will be "clearer-ish" in like two weeks or so to swing back to get this patched up.

Spacious ACP 20.0.1 submitted! Patch for retrieving Elasticsearch instance metrics and the instance returns NULL and an array is required down the line anyways. If this does not clear up your problem @Joey_M I'll need to poke your server or get more information from you. Installed the latest locally, tested fine with a working Elastic instance. All the err'd method does is poke your Elastic server for stats and json_decodes them. NULL is "possible" there if something is off (specifically "null is returned if the json cannot be decoded or if the encoded data is deeper than the nesting limit") so I just added some protection for that. Also this method was written with new type declarations so returning null was why the error was thrown (it's locked to array) Still somewhat curious as to the what and why you got this error - as said, first I've seen in forevers on this. Available when the usual suspects approve it (if $elastic == NULL, return array() is the extent of the changes)

I see it. Mostly. I'm going to make sure nothing changed elsewhere as I would have thunk this would have popped up sooner so I'll upgrade locally and see what explodes first before submitting. You didn't upgrade PHP on your end by chance did you?

Like, the Invision Community JUST released an hour ago?

You're not going to make us... are you?

AcTuAlLy... yes, the 1000 does come from me - never read your first post here. To get this to work I have to explicitly state an "unlimited" amount, which as Randy pointed out, is what attachments are anyways - unlimited. I just use a 1000. Since the "ask" eons ago was for limiting forum post attachments, that's all that gets limited (and everything else is "limited" to 1000). Pretty sure everything would simultaneously melt and freeze if someone threw a 1000 attachments at an editor. If you did them a handful at a time it might work, not sure about the post save part though.

Should be. That said, looking at the code for the first time in eons, I don't think this ever limited in status posts as I have checks in place to only apply the limit on forum posts.

If any users reading this would like one, Spacious ACP has had patch notifications on the Dashboard for years now. Years...

Set it to a very large number. If you are showing 900, 2000, whatever number of names just be aware that the page load will probably be affected.

@Stuart Silvester not to derail this but do you have an internal guesstimate to PHP 8.1 required? Are we looking at months or further out?

@TK1990 Not sure where the hitch is as there is nothing identifiable in those messages back to this. PM me an ACP account so I can pop in and take a look.

Yep, if that is coming directly from those templates and you didn't change them (I did not know he was directly supporting this app in that stuff). You *can* change them in your theme, but when upgrades come around then you have to deal with them maybe updating, maybe not as they will then be flagged as "modified". Either way, a miss on my part with the docs. It's clearly there in the template tags stuff in the official IPS documentation here; I just spaced them when including same in my app description and inside my app itself.

@CheersnGears Well that's some interesting file permissions. That permissions number ain't in the suite anywhere that I can find, including my apps, so where that's coming from :shrug: Anyhoo... So, one of the things I did with the last version was touch up the documentation and such, including adding it to the add image tab in the ACP itself. And... ummm... I might, MIGHT..., maybe, left a bit off the file call there. Probably. {file="$category->pcimage" extension="pci_PagesCatImages"} You need the extension there otherwise it will flail about and so on. I tested moves to Wasabi from local, confirmed it moved fine, deleted the local copy fine, but the url in the article page was still wrong. The file is stored with only the folder/filename in the db, so that was fine, that left why it wasn't getting the actual web storage url correctly and well..., etc. etc... Touch up your insertion code to have the extension= bit as seen above, and you should be fine, excepting whatever the hell is going on with your actual uploads and permissions.