bfarber

There are several factors at play so I can't say "yes" or "no" without qualifying the answer. You may wish to try it out to see if it performs the best in your case in any event.

We will review this, thanks for bringing it up.

We have a general SEO audit/review planned and this is on the list.

If you haven't converted to utf8mb4, there is an option available in the right hand column when viewing the support page in the AdminCP.

On a busy site, a cache time of 1-2 minutes can represent significant savings on database overhead. That seems reasonable.

Yes it is possible. As long as $extra is a different value here, it will register as a new notification
public static function send( $app, $extension, $extra = NULL, $resend = TRUE, $extraForEmail = NULL, $bypassEmail = FALSE )
That said, it's typically best to follow established paradigms where possible. We may, for instance, make a change in the future that disallows this ability.

If you are self-hosted, we recommend taking a backup before applying upgrades as mentioned by @Miss_B.
It is often a good idea to upgrade a test installation first to ensure there are no compatibility problems before upgrading your live site. That said, as a general rule upgrading between minor point releases (i.e. 4.5.2 to 4.5.4) should not cause you any issues, while upgrading major point releases (i.e. 4.5.x to 4.6.0) should be treated with extra caution due to a higher likelihood that third party customizations such as plugins, applications and themes will no longer be compatible.

My only suggestion is to make first a backup of your database and forum folders/files as well, before you upgrade your forum. (Regardless of the upgrade method btw)

The reality is it's pretty rare that a "corrupted" file occurs with software like ours, outside of when someone is manually uploading files and they have connection issues (i.e. the connection drops mid-upload).
That said, if this is something that actually comes up we could look at a "reapply files" button for applications in the marketplace. We wouldn't likely do that unless we see material instances of this happening outside of hypothetical situations mind you, but it's not something that's a blanket "no". It is, however, something completely separate from what was originally requested and discussed.

Thanks, yeah, I went through them one by one. There were about 20 from a deleted account, like I'd mentioned, and a surprising number (of OLD posts) that were marked as -3 in queued. I changed a lot of them to 1 so they'd show up in the approval queue and I could approve or delete them. Who knows… maybe we missed them at the time.
Got the list down to about 40, not counting the 30-50 spammy posts by bots that will be removed if they don't register (they won't) within the next week or two.
So, really, most of the old stuff was just old guest posts that may or may not have had the right flags in the database. But, every action except changing some of those columns was done in the UI on the site, either in the ModCP or the ACP, so whatever needed to be done to affect other tables I'm sure was done.
Thank you for taking the time, @bfarber.

you'd probably need to do something like this in your block
$_SESSION['arrayValues'] = ...;// The array data and then look at $_SESSION['arrayValues'] in the rest of the block/template after. I just used $_SESSION as a globally accessible storage container in this case, you could use other similar paradigms.

This will be addressed in our upcoming 4.6 release.

I can reproduce so I'll take a look. Thanks for reporting!

This exists as a setting in the ACP. Right now, it's all or nothing.
ACP > System > Settings > Email Settings > Truncate Content

Yes, you would still need to configure the CORS headers. The main difference is that you will be sending requests as an authenticated user instead, so they'll only be able to see things that they're allowed to see and perform actions where allowed.

You cannot control what time digest emails are sent out. The task that sends the runs throughout the day and will send them as soon as the previous 24 hour period has passed. Different users will receive digests at different times of the day.

Yes, that's normal (it will run again 24 hours after the last time it did for an individual account), however the time of day an email is sent will vary from account to account.

If you make the request within the client/browser, you need to content with CORS which is designed to allow cross-domain requests to work but also provide protection against javascript-based attacks. Essentially, you'll need to add a few response headers for these requests which is typically done at the server level.
Postman doesn't run in the browser context which is why it works without an error.
One word of caution - running any sort of API requests via javascript exposes the API credentials. We'd only recommend using an OAuth-based client for API requests if javascript is going to be executing the API requests, since the permission level will match the current logged in user anyways.

For the record since this was bumped, this is a current feature (the original topic is 5 years old). This can be enabled in the AdminCP settings for Calendar.

For the record since this was bumped, this is a current feature (the original topic is 5 years old). This can be enabled in the AdminCP settings for Calendar.

Anecdotally I will say that IN_DEV locally feels a lot faster to me on PHP 8 than it does on PHP 7. I haven't measured speeds for both, however.

Sometimes a ticket is the easiest way to diagnose a problem, even if the issue can be duplicated on a fresh install. When you look at the steps necessary to reproduce a problem and it can take an hour to set up your test installation to duplicate the problem, but you already have a live example we can look at, it's often more effective and efficient to look at the live example.
Support is included with your license and we encourage anyone experiencing a problem to make use of our support.

I'm not sure whether we even have a referral program still running, however the license agreement does not allow the copyright to be modified in any event.

The upgrade processes are not ran when installing an application, only when upgrading it. You need to create an install folder and add all the queries necessary for a new installation there. Look at one of our first party apps for an example (Blog, Downloads, etc.). You'll find applications/blog/setup/install/* which has everything needed for a new installation, and then any changes since the first version are individually tracked in the applications/blog/setup/upg_XXXXX/* version folders.

Are you wanting to do this en-masse, or one by one?
It is possible to move individual topics to Pages, but there is no faculty to do this en-masse best I can recall right now.