All Astronauts

Is this for attachments?

applications\core\modules\admin\membersettings\reputation.php line 369 catch ( \UnderflowExceptiobn $e ) { }

Spacious ACP 21.0.0 Submitted! NEW! Invision Community 4.7 compatible. No changes really, the last version will work fine too. CHANGE! Amazon Alexa Rankings dashboard widget is still there but now just displays text stating the service has been retired. REMAINS! The Alexa Rankings option remains in the Spacious ACP menu for you to view your previous (if any) historic ranking data. I'll have an export function in a later version. REMOVED! Task that retrieves Alexa rankings... NEW! Members Operating Systems and Web Browsers Dashboard Widget! For the Alexa stuff the end has come. No CSV export yet (does anyone even care about this historical data?) but on my punch list to do sometime. The upgrade routine should check if you have Alexa data at all and preserve the Alexa Spacious menu option in the ACP so you can see that stuff - otherwise it disables that menu option (no need for a menu option that lets you look at, checks notes..., nothing.) The Alexa dashboard widget is now nulled out with just a message stating that all is dust. For the NEW dashboard widget, after you install Spacious 21, you'll need to either wait 24 hours for the task that gets that data (uses member user agents over the last 90 days) to kick off or go to the tasks section of the ACP and run it manually (spacious_userAgents). Task runs daily. It is user agent based so it is what it is. Do not expect devices to come to this Spacious party - device identification via user agents is being degraded quite a bit - Apple leading the way here as Safari is effectively the same between desktop and iPads now. If one wanted to they could throw down some Javascript and start detecting device windows and touch points and so on but that's a whole other deal. This will get built out later on with a historical view and some trend arrows on the widget so you can spot, ya know... trends. For now just plain percentages is what you get. From one of my communities. That Firefox percentage gob-smacked me. Your mileage, I guarantee, will vary. iOS entails desktop, pads, and phones for Apple. Linux also onboards any BSDs out there. Feel free to yell at me about that - don't care. Other is any and all whatevers including game consoles, Tizen, and gods know what else. Internet Explorer I imagine. For browsers the other category will have Samsung Browser, Brave, whatever... You'll see it when you see it. Kitchen Sink is next for my 4.7 sweep, then all my plugins, then back to remaining apps.

I'm on the support list of a CIC client, the Client Area support button clearly states support request must come from my email address, your system bounces it telling me "lol no. You are self-hosted"" If you see these bounces internally just grab it and go, otherwise point me in a direction. The actual site problem should be an easy fix (CMS block will not open for editing - clearly exists and is working - I'd poke it with the SQL tool but... you know...)

So this is good to go? Just making sure this stuff will write out on CIC installs and not get ignored. EDIT: Never mind. Just went ahead and confirmed it myself. Works great. Thanks.

I'm afraid to ask but need to. Applications with custom API code (so we make an API directory under our application and add in our whatevers) - works a treat on self-hosted. Am I going to have a good time installing said-application on CIC or is this a brick wall staring back at me? Given how CIC is structured and the hullabaloo about the interface directory awhile back...

PM your site and ACP login, I'll take a look. I'm not seeing this problem on the latest version that you are seeing.

That's in the ACP marketplace. For some reason when you type the full name it doesn't show. If you type in just "group colors" you will see it:

In the ACP just type in "Group Colors" and you'll see it down there. Why the search doesn't show it when you type in the complete name is an IPS question - @Daniel F just to tag someone. The icon will look like this:

I'm still good here on the latest version PM me your site so I can look.

Pretty sure that's it. I think I have four licenses, maybe/probably more? I know two are just there waiting for me to do something with them and haven't been renewed in forever, others are on separate accounts but they all tie back to me in the end. I always regularly renew the one that has everything, and one organization is on more of a 9 month cycle - updates aren't critical and there is literally an approximately two month period where any/all dev and updates are pretty much off the table as stuff is not allowed to break during that time. If it turns out the one that has to be renewed must be under the account you MP release under I might be boned - however, since Google decided to terminate all the old free Google domain email stuff the other day I have Hell in front of me for multiple organizations anyways, most of them tied to the aforementioned accounts, and if that's the case while I'm burning everything down getting all that resettled I'll just pull everything under one account regardless of the organizational nightmare it will end up being and call it a day. BTW Esther renewed a few hours ago - her apps didn't immediately become available again, but are now, so maybe an hourly task runs that sweeps that particular MP thing. Anyways, you no need to panic about Headstand 🙂 EDIT: Scrolls up, sees the obvious... lol

There is probably a third-party app that has a hook on \IPS\Dispatcher directly (and not on \IPS\Dispatcher\Front or Admin instead). This is crashing new code IPS has in the init.php method in this latest version. You are a bit stuck until you figure out which app/plugin it is though. You'll need to look at core_hooks table, and then look at the 'class' column. You're looking for \IPS\Dispatcher there and NOTHING ELSE. Not \IPS\Dispatcher\Front; not \IPS\Dispatcher\Admin. If you see an entry there that's your app; if it is a plugin id, off to core_plugins you go to find the matching ID number and that's your plugin. You'll need to set the RECOVERY_MODE constant (true) to stop all the hooks from loading to get access to everything again. You'll need to disable what you found before taking recovery mode off.... but with recovery mode on you don't actually get access to the ACP so you are in a bit of a loop here. You'll probably need access to the DB via phpadmin or something anyways to find what you need anyways (since recovery mode means no ACP etc. etc...) so once you've found your guy you can just set the application off there in that table, same for plugin. On the off-chance things are still wonky, you may need to hack out the new IPS code in init.php and everything will work again but you'll need to still deal with whatever is crashing out here. If it gets to that point see my post in the dev area (if you have access there) or shoot me a PM.

Did some more digging and caught it. Old application (private), probably from the 4.3 days. The hook that was crashing it was on \IPS\Dispatcher, not \IPS\Dispatcher\Front or \IPS\Dispatcher\Admin. The problem was the hook being on that and not on Front or Admin instead.

This was direct file overwrite - I never upgrade my DEV via the ACP FTP stuff. Either way, the code I pasted is the hitch in these instances.

Did you guys dogfood this with 3rd party stuff? Init.php, line 900 or so if( static::isThirdParty( $data['file'] ) and \IPS\Dispatcher::hasInstance() ) { \IPS\Dispatcher::i()->loadedHooks[] = $data['file']; } Fatal error: Uncaught Error: Class 'IPS\Dispatcher' not found in C:\laragon\www\dev45\init.php:900 Stack trace: #0 C:\laragon\www\dev45\init.php(874): IPS\IPS::monkeyPatch('IPS', 'Dispatcher', '') #1 [internal function]: IPS\IPS::autoloader('IPS\\Dispatcher') #2 C:\laragon\www\dev45\init.php(999): spl_autoload_call('IPS\\Dispatcher') #3 [internal function]: IPS\IPS::exceptionHandler(Object(Error)) #4 {main} thrown in C:\laragon\www\dev45\init.php on line 900 Mayhaps it is local to my dev instance but this was a pretty hard stop on everything. I just hacked out that new stuff and moved on (you are only using it for log entries anyways) but you may wish to give this a close look.

Just FYI, if a dev does NOT RENEW their "package" - whatever it is, the MP stuff is, apparently, automatically deactivated. Esther (Headstand) just let her package lapse and is renewing this week. She's not going anywhere.

It's a hitch with hex2rgb template plugin and PHP 8. I'm pretty sure IPS have patched it with the 4.6.10 release (beta right now but probably final on Monday or Tuesday). After you upgrade, see if this bug still pops - if it does, give a yell.

Version of IPS? Also PHP version.

Some very GENERAL notes regarding hitting the API. May or may not apply to you... 1) Friendly Urls enabled on your site? If not you need index.php? in your url call. 2) Is Python or your code setting a user agent? Doesn't need to be anything real, just exist. I've had servers tell me to get bent solely for lack of a user agent in the Curl call. 3) Shouldn't matter at all but when just starting out you can remove one variable by just poking the default API endpoint - /core/hello - for the basic response. One less thing to have your mind on. In your specific case are you closing that response call ever? That max retries error makes me wonder... Good luck; I've got a tester built out but it's for PHP calls. Not much help for you right now.

Went ahead and set a new Wasabi file storage type. Set Downloads files to that. Enabled the S3 plugin. Uploaded a new file (zip), downloaded the file - successfully. Checked log. One entry. Downloaded again. Two entries. Be sure to check with your users to see if there is just weird behavior going on. You can also just test this yourself. Make a new Downloads file entry and then download it. Wait a minute. Download it again. If you see just your two downloads logged (minus anyone who might just jump in there in the moments after you do all this) everything is fine and your users are just weird or something. If you see yourself logged more than those two times, then something something something ???

It literally does nothing other than bypass a signature check when downloading files that are attachments or IPS Downloads files. That's it. So it's nothing to do with that. Plugin disabled (not that it would matter...), testing locally with Downloads, files stored locally, this behavior you describe appears intended. I downloaded the file, then downloaded it again. And then again later. Three entries as I would expect actually - if someone is downloading the file repetitively why wouldn't that be logged? Person could just be annoying, or maybe they after downloading it were addle-brained and deleted the file accidentally and needed another copy?

FYI I submitted a 2.2.1 version just now. Clears out some javascript errors from the console when the sidebar is not present at all. Also had some dupe code cruft related to this I cleared out. No big deal if you are running 2.2.0 (nothing will crash or anything) but when this revision appears do upgrade.

2.2.0 Released NEW! Sticky Sidebars Pretty much what you see. No more dead space when scrolling down a page when sidebars are enabled. If/when you are editing the sidebar be sure to refresh the page after saving as I don't have a listener to reset everything afterwards. Yell if there are major problems as usual.

Thanks. I'll make a point to add a few more options in the next version for this and other things.

Pending approval...