adrian

So, some good news - I upped the DB clusters to 4 GB RAM / 2vCPU machines and now the performance is on par with the local DB. The downside is that this is quite expensive but I am thinking it will be worth it for the: Daily point-in-time backups. Full cluster backups are taken daily and write-ahead-logs are maintained to allow you to restore to any point-in-time within the previous seven days. High availability with automated failover. In the event of a failure, managed databases with a standby node will automatically switch data handling to the standby node to prevent unplanned downtime. Obviously not needed for most sites, but I think when you have frontend users regularly modifying info in the database, having the ability to restore to any point-in-time is quite reassuring.

Thanks @elabx and @Craig - I hadn't seen that particular post, but I had seen others complaining of performance issues. I have been in contact with DO via a support ticket and so far they haven't been very helpful - first response basically said that it's expected because their managed DBs run on low spec'ed servers. The next response wanted me to provide examples of queries that were slow. The reality is that all queries are significantly slower and they are even worse when connecting to one of their readonly nodes. At the moment I am considering ScaleGrid, or maybe manually setting up replication something like this: https://www.digitalocean.com/community/tutorials/how-to-set-up-replication-in-mysql - although that doesn't provide all the features of the managed DB setup. I'd love to hear from anyone else who has a good solution for having instant DB replication, fallover/standby nodes and readonly nodes that are at least as fast as a local DB - thanks!

@rick - did you try Robin's version: https://processwire.com/talk/topic/19913-solved-page-reference-field-unpublished-pages-not-visible-by-non-superuser-rolesusers/?do=findComment&comment=172578 That's what I've been using for a long time now.

@StanLindsey - I've just started experimenting with Digital Ocean's managed DB clusters, having one standby node and one readonly node. Everything works, but the site is quite a bit slower when I use these vs a normal MySQL DB on the droplet where the PW install is hosted. I did go for the lowest end DB cluster they offer, so: 2 GB RAM / 1vCPU Compare this to the main droplet which is: 8 GB Memory / 4 Intel vCPUs (with an innodb_buffer_pool_size = 4G setting) So obviously the managed DB has potentially fewer resources, but I am wondering if it's the DB's lack of resources or if it might be something else - perhaps just the requirement of connecting to another server. I see I am not the only one who has experience this issue: https://laracasts.com/discuss/channels/servers/same-query-in-digital-ocean-managed-mysql-db-more-than-doubly-slow-than-on-droplet but I would love to know your experience and if you might have any tips to share. Thanks!

PW doesn't output anything on the frontend by default, so it's just your code. Perhaps you need to make sure the JS animate function isn't triggered until the DOM is ready.

Did you see my screenshot above - you need to whitelist the svg extension in your image field settings.

Ok, so I assume you have clicked the "Refresh" button at the top right of the upgrades module?

You may need to log out and back in again. Not certain if that is still the current behavior but for quite some time it didn't pick up new PW versions without doing that. Also, what version of the upgrades module are you using? The new one requires a manual refresh, but I am sure you've seen that.

PS - that said, I don't see any issues here on Safari, but I am using the latest PW dev version so maybe something has been fixed in the last 6 months, so I would try an upgrade first.

You can use SVGs without that module - I don't recall exactly, but if you uninstall it, you'll get a warning that tells you the alternative option. There a few discussions online about Safari having issues with fetch (and sometimes XMLHttpRequest) with https. CORS might be coming into play, but it's hard to tell for sure. Google: safari "failed to resource: cannot parse response" AND safari fetch https (even though I don't think this is actually fetch, there are still some posts that seem relevant). In reality I steer all clients away from Safari because I still find lots of random issues with it here and there.

Take a look at this: https://github.com/processwire/processwire-issues/issues/674 I think it should help you fix the problem.

Ah - sorry, I missed the point about it being Safari specific - are you seeing JS errors in the dev console?

@Claus - do the same SVGs consistently fail and others consistently work, or is it random with a file working sometimes and not others? If the former, can you post one that fails so we can test it?

Thanks @flydev ?? - I've been using 1.4.16 for quite some time (with some sqldump command changes) and it's been working great. I just updated to 1.4.17 and all looks great running on pHP 8.0.

Depending on how many locations you have findRaw() might be a useful alternative to find()

Hi @Ivan Gretsky - thanks for your monthly donation to Tracy - it's always appreciated.

@Gideon So - I've fixed that error in the latest version of my fork of the module: https://github.com/adrianbj/processwire-fieldtype-assisted-url BTW, the reason is that prior to this version, you needed a Ckeditor field on the same template - now you don't.

Have you guys tried combining findRaw() with url hooks - https://processwire.com/blog/posts/pw-3.0.173/ ? I find it a really easy way to take care of this stuff.

Is this the issue? https://github.com/processwire/processwire-issues/issues/1511 - if so, it is fixed now.

The first one of those was basically due to index issues in my DB - running optimize on all tables fixed it, although I still found some significant improvements to speed that could be implemented. The second one is very weird - certainly seems like findMany seems some attention.

Not sure, but it seems like it might be further away: https://caniuse.com/jpegxl I feel like it's the mid 2000's again and I am waiting on browser support for SVG!

I had a similar experience with WebP - most often not significantly smaller, and often larger, so I kinda gave up and am waiting on AVIF to be supported widely enough to start using: https://caniuse.com/avif

That's because my repo is a fork of the original and not in the modules directory - you need to install from Github. Does that help? Actually, I see that is what you installed. Not sure why it's reporting 2.0.0 still. I guess the key thing is it now working without a separate CkEditor field? Also, can you see the updated file (with those changes I committed) in the folder under site/modules ?

Does a modules > refresh help?