All Astronauts

Sorry. You can ask IPS to claw it back I guess? I warned up-topic that this would happen, it's an app now and there is no upgrade path with the ACP Marketplace from a plugin to app. When it releases it's gonna be cheap for two weeks so old hands can grab it without too much hurt.

Brief update, this will be submitted tonight. After that it's not really on me... Again, sorry for the required re-buy, it's the new Marketplace, so it goes. Speaking of which, a goal post has moved - a thing called the Interface directory (a useful thing in applications where we can dump things and they will always be loaded from the server) has, as of two days ago, been tossed out the nearest airlock due to an incompatibility with the newest iteration of Community in the Cloud and this hitch was missed by IPS until, well, just now. So, fun for lots of people to work their junk over. That includes me, but at least my public offerings are only caught up with a few font files. Anyhoo, those of you storing theme resources OFF-SERVER - that means you have them set to be stored and load from an Amazon S3 instance (or legacy FTP if you still actually have that going), be sure your server setup is set to allow all the web font extension varieties on through (woff, ttf, svg, eot) otherwise you will get hit with CORS hitches (server will not load things onto the page if they are coming from places it thinks they should not). The interface folder was a lock for not having this problem occur, but now you guys will need to deal if the problem occurs. That font crap to deal with, one more thing to stick in after that, then screen shot hell, then submit.

@Daniel F Let's get some hard clarifications please. For any submissions going forward, we will have to have completely removed the interface folder and any/all contents within? I do not want to nuke the interface folder, make all the changes, submit, and then find out nope, we aren't ready for the interface folder to be missing. Additionally, will a missing interface folder be "ok" for those on 4.5.0, 4.5.1, 4.5.2, 4.5.3 or is the installer going to just choke on it? EDIT: For those that didn't peak in the dev communications forum, Interface is dead now. I'm just gonna go ahead and cue up a large popcorn for when people start thinking about their apps (customs or otherwise) that have 3rd-party PHP libraries in interface. 🍿

Gonna try wrapping this up Thursday. Compact Rating Stars Display option is back in; tackled that this evening. And yeah, all this stuff is taking a long time. Chalk it up to a lot of things, some of which is in my control, other parts not so much.

Okie dokie. 4.1 submitted. Catch it when it shows for real in the MP (something something approval time) What this one does is guarantees that if you have set a custom url for your bucket then that gets used. Period. It also adds settings that will allow you to FORCE HTTP either on all your compatible S3 links or you can only force them when the bucket has dots in its name and there is no custom url set. This plugin is still kicking out PATH-STYLE urls, so that's url/bucketname/filepath/filename. Eventually those settings might matter but right now they are mainly a hedge. If you have problems, give them a try, but they will mostly matter when this plugin supports VIRTUAL-HOST STYLE urls, the ones with bucketname/domainname/filepath/filename - also known as the style that will cause you endless grief with bucket names that have dots in them. You either write out custom SSL certificate logic, serve HTTP unsecured links, or do what IPS does which is let it be HTTPS secure but nuke the security checks themselves. That's a little upstream for this plugin (at least on first look) and since this plugin is still making PATH-STYE urls, nothing to worry about just yet. Still, you may have a use-case for these settings now, so, in they go. Amazon is now forcing all newly created buckets over to VIRTUAL-HOSTING STYLED linking so it won't be too surprising if others follow suit. Note that using HTTP links work (of course), but on download, where the downloaded item appears on the bottom of your browser window (Chrome, others) you will get a little warning about this being an unsecure download and do you want to keep this file. Well. That's the deal. If your users can handle that, all is well. If they complain? :shrug:

@bfarber One more, than I'm really out on this. RebuildScreenshotWatermarks() queue task Line 91 you run the code for when there is a no_watermark original copy. The method copies that no_watermark copy to an $original variable, deletes the location and thumb files, and then if there is no $watermark (meaning this rebuild method is running when someone is removing watermarks from their screenshots), updates the downloads_files_records table row by storing the url to $original in location, creates a new thumbnail copy off of $original and stores that url in thumb, and then sets the no_watermark column to NULL. At no time do you actually delete the no_watermark file in this situation so those files are now zombies with no url stored anywhere for a FileHandler to grab them.

Yep. I'll add it as an option.

Thanks for the update. Would prefer we actually end up with a solution that provides a certain always-local (not off-server S3 or whatever) source to load "stuff". My reason is CORS madness and though that's not something that is necessarily IPS's problem to manage on end-user sites, it is a thing we'll hit if we lose the Interface directory as we will go from always loading and working as our things are loading from the local server to maybe/maybe not working depending on the FileStorage location being local or not and now we are getting yelled at and having to deal with all that stuff. Others may have different reasons.

That response appears to be saying (by not saying...) that CIC users and the interface folder are not gonna fly? Can we get a real answer on this? If the interface folder contents for apps is not going to install for CIC users a lot of us have a lot of work to do. If this is just a hitch with Community Map then carry on but otherwise we are all going to need clarity here.

Addendum: isValidFile() also doesn't account for record_no_watermark files, so if Downloads or the system ever hit that with a record_no_watermark file it would return FALSE of course. fixUrls() as well but we are probably WAY beyond the need for any changes there. Or rather, I hope no one is tooling around with 4.0 right now. EDIT: Also, in Downloads settings, the watermark image file upload helper is using core_Theme for the file extension, which it probably shouldn't. I'll show myself out now.

It's in the ACP Marketplace now.

4.5.3 You do not account for all screenshot image copies; specifically you do not move the original not-watermarked screenshot images when those files are watermarked. record_no_watermark is not accounted for during the move process End result is record_location and record_thumb files are moved, but record_no_watermark, the only copy of the screenshot not watermarked, is left behind. If the actual OLD file storage location is still valid, that record_no_watermark file will still be retrieved as the file and url remain valid since they were not moved. Obviously nothing ideal happening here though.

I honestly did not think this was getting approved (at all). But there it is. The statement provided before still stands. Enjoy this while it remains valid. Not "approved-Marketplace" valid, more like "functional-valid". And also remember the use-case this was generated for. To allow for users to download attachments (and Downloads for non-monetized Downloads instances) without the need for signatures. If your needs are greater, features and security-wise, look elsewhere...

Just an update on this for Pages Category Images. There is zero wrong with using what you have with 4.5, knock yourself out. That aside, I might just submit the old version and see if it will pass even though it does add a column to an IPS table - reason being that IPS does not follow the standards for loading categories consistently in Pages, meaning the standard hook point one would use to join a table on to the categories table is a no-go and I'm not sure I can slip by this without going way upstream and doing crap no one should be doing.

Remaining before submission: Breadcrumbs Edit first posts Profile page cover photos Force the Forums Post Feed Widget to Pull Only First Posts? Star Ratings, Restore the Moderator Checkbox on First Posts will have to wait for the next version, skipping any js adds for the initial submission. A few things are dropped due to IPS doing them, somethings just no longer needed, etc. Some new apps are now a part of KS: a minor gallery thing, small downloads tweak, some blogs love. There is some overall new stuff in places as well, plus improvements. Let's see what the night brings...

4.5 version submitted Friday, September 18, about 4:45pm Central time. In the ACP Marketplace when it's there. Nothing major, a few tweaks, etc. EDIT: Early AM Monday, September 22 it is now available.

/** * Save translatable language strings * * @param string|int|\IPS\Application|\IPS\Plugin $appOrPlugin Application key or Plugin ID So alright, string or int. For plugins hitting the settings method or the uninstall routines will give us the plugin_id via the request var. \IPS\Lang::saveCustom( \IPS\Request::i()->id, 'muh_word', $values['muh_word_setting'] ); If you do that, you're setting things up for a bad time down the road. That will set both the word_app AND word_plugin entries, together, to the plugin_id value instead of NULL, plugin_id respectively. if ( $appOrPlugin instanceof \IPS\Application ) { $appOrPlugin = $appOrPlugin->directory; } elseif ( $appOrPlugin instanceof \IPS\Plugin ) { $appOrPlugin = $appOrPlugin->_id; } $insert = array( 'lang_id' => $langId, 'word_app' => ( \is_string( $appOrPlugin ) ) ? $appOrPlugin : NULL, 'word_plugin' => ( \is_numeric( $appOrPlugin ) ) ? $appOrPlugin : NULL, 'word_key' => $key, 'word_default' => $default, 'word_custom' => $value, 'word_js' => $js, 'word_export' => FALSE, 'word_is_custom'=> ( $isCustom === TRUE ) ); If you were to throw instances at this method you are probably alright, but your use of is_string and is_numeric is problematic when passing through "numerals" as that request var, passed through settings as is, will evaluate true on both of those. \IPS\Lang::saveCustom( (int) \IPS\Request::i()->id, 'muh_word', $values['muh_word_setting'] ); Explicitly casting to INT will save you here for those you coding custom language bits with plugins right now. If you already are in the wild with a plugin and you are using the request entry raw, your end users probably have some possibly problematic lang table entries. No idea what (anything?) can happen down the road with both app and plugin entries set. You might want to bulletproof this a little more or require instances explicitly.

Naturally this is taking time, nothing for it, and no blame or anything, they have to spin up alt-S3 service and test and so forth. If you gotta have it due to DL problems shoot a PM. EDIT: If you saw another post by me after this one, apparently, you, and I, didn't...

Ignore him. Button pushed at 3:08pm Central USA time.

<two weeks later...> So, I've sat on this for a week or two. Pulled some things that might make IPS grumpy, waited around for IPS patches to appear to make sure that Spacious patch alert feature was working, and so on. @Joel R has a near-final build and he seemed pretty perky about it so it can't be all bad. Now, as far as Marketplace approvals go, there are multiple people doing the work, and it seems to be a take one and go (or take the next on the pile and go). Some stuff of mine has taken many days to get approved. One thing today leap-frogged something utterly trivial today and was approved in something like two hours. I've not had a rejection yet. Not expecting that trend to continue... Also, this will not be approved in two hours. Devs currently do not get alerts when a file is approved and I'm not checking 24/7 to see. I'm hesitant to update the description as that flags the file as recently updated and people download it and nothing has changed except the description and blah. So no new description until it's actually approved. When you see this in the ACP Marketplace, you'll know it's good to go: I'll have to upload a metric ****-ton of new screens when I submit so I might just do a running log of changes with those here after submission. I'll be doing the submission in the morning while watching bike riders in Europe experience a tremendous amount of pain. Lastly, as far as I can tell there is still a bug with templates not clearing out when you enable/disable an app or plugin on the ACP side. Which is to say post-install you are good to go, but if/when you go to the app page and toggle an app off, if there are hooks on templates on the ACP side, those hooks will remain ACTIVE until you hit the Spacious refresh caches button (if available) or use the support tool to do the same. If you do this with Spacious you might get some weird looking ACP (since the CSS is disabled so included images might be stupid large) but, again, support tool or refresh caches button and all is well. Not my bug, not my problem; t'was reported in the alpha/beta tracker. Fairly warned be ye sez I. No, there is no re-buy required for this upgrade though the work probably demanded such. Kitchen Sink, another full re-write, will probably require one just for the fact that it is moving from plugin to app.

4.5 submitted. No real changes other than a few code tweaks. In the Marketplace when it's there. The usual caveats about your browser being a dick and so on. I HAVE tested again to verify its all working, back and forth messages between a Chrome user with a custom sound and a FireFox user with no custom sound but pulling a custom community default sound. The first message to the FF user didn't play the sound but the second (and onward...) did and I can only assume the diabolical innards of the whole web notifications process are still roaming the Earth freely. I can't fix things if your browser decides to not play audio due to ajax timeouts and so on. Which is to say, the ancient Sound Board note about this only swaps around the audio files and has absolutely nothing to do with the when, where, or hows of notifications being generated or what your browser does with them still apply. Any one interested in a giant page (paginated table) with every custom notification sound on it? I'd probably add a field for users to add a Twitter length description of the sound as well. So few people recognize the opening strains of Galaga these days... Note: description will be updated post-acceptance. Devs can still update the description while the file is pending but people just download anyways when they see it "updated" and that's not helpful.

Well... either IPS staff was reading this and did you/others a solid or the approval gods are various and unknowable (or they all have their own to-do piles...). I've been spooling out my additions to the new marketplace just to keep the work low; for them and me. Of the (formerly) three pending, I didn't think this one would would jump over the similarly requested update to Remove Forum Title from Forum Index - that one is literally two lines of CSS - this one has at least some meat on its bones. Who knows? Anyhoo, this was approved super-fast. Enjoy. Also update is for 4.5 only, will not work on 4.4.10 and lower.

Submitted. All up to the ACP Marketplace gods now.

There is a chance I'll be pushing this to an application, and that's going to mean almost certainly, a re-buy (no way to sync with the new ACP Marketplace). If I have to do that, I'll be leaving the purchase price at like $10 for a month or two to ease the pain. Why? Standards are up considerably with marketplace code reviews and there is a nominal chance, possibly reported once before but most sites using this plugin never usually hit this, that a deleted/merged member causes problems... and I can't handle those problems with a plugin - only apps have the capability to deal correctly with these hitches (well, the way IPS wants them dealt with anyways. I can get around it easily enough but I doubt it would pass review...) On the plus side, you'll be getting more options, ACP previews, a name-only table popup option (vs. avatar display) and I think I'll throw a super wide table view option on that as well for those that are using this more for mod purposes (that might have to wait for the version after though). Yes, old data would be retained of course (database table copied over, then the plugin removed after the app is installed automatically). I was 85% through the re-write for 4.5 when I saw my old note about this hitch and was like... yeah... EDIT: You know what? This plugin does work fine as-is with 4.5 so all y'all are safe, it's just not going to be in the ACP Marketplace. I'm pushing this to an app, and I'm going to roll it all in: Forums, Blogs, Gallery, calendar I guess. Downloads, Commerce and Pages will be low-priority, but Forums out of the gate and then the others.

You know that thing where you casually mention something that's relevant to the problem but you are totally oblivious to the fact that you actually didn't account for that thing you just talked about? And then someone comes along and says "why didn't you deal with that thing you just talked about here..."? That was yesterday. @Martin A., with the oblivious assist from myself, got a handle on this. This has been cleared by at least two live sites experiencing this problem. A new version will be submitted to the Marketplace asap. Now, just as a heads up to everyone: we are nudging, but not rushing, towards the end of the usefulness of this derpy thing. Amazon S3 is forcing everyone on over to the new styled urls where the bucket name is IN FRONT of the endpoint url. So, my.bucket.s3.awesomes3service.com/.... (this is virtual hosted-style) vs. ye'olde path-style urls, e.g. awesomes3service.com/my.bucket/.... The thing with the newer style is you gotta have wildcard support set up for your domain with your DNS settings. You gotta deal with your CDN settings. And naturally, your SSL certificate. Got dots in your bucket names? Shouldn't do that... Dashes are better but now you have some other hitches and so on. In a perfect world you would just have a single non-dotted, non-dashed alphabetic "word" for your bucket names and things work much more smoothly. The patch here, as it were, is to account for dots in a bucket name and if present, flip things over to http instead of the likely secure SSL https. That stops all the yelling. The point is, as Amazon S3 standards change, and web/browser security changes, and CDN requirements and changes, and so on, we're going to hit a point where this isn't going to be a viable hack anymore. We are not there now but in a few years? Who can tell...