@d19dotca @girish X theme, may also be called Pro

@girish WHOOP!! deleteing object-cache.php solved it! Thank you so much!!!

This is how I do it, personally. Though I delete the dev.tld.com app when I no longer need it.

@p44 for me personally I wouldn't want that. When I use the clone feature, it clones an empty WP with a few basics installed to start the development process. When I migrate that to prod, I use duplicator, which does the heavy lifting and replacing.

It's mostly this way already. The credentials given to an app do not allow the app to operate outside the scope of the database. The app cannot drop the database as well. But it's allowed to do whatever it wants inside it's own database.

In managed WP, the file is not writable.. But in Developer edition, a user has to change that file themselves, from the filemanager. This is by design though - the developer edition is vanilla and developer sets it up as they see fit.

Are you suggesting this for the default setup? There are already plugins that do this (and indeed many of our customers have randomized tables). IIRC, it's one of those security plugins. The Developer edition is vanilla, the intent is not to change the defaults. On a side note, this whole table name randomization is .. questionable. Pretty much no app outside WP does this, it's not really needed when apps are deployed properly. But only needed maybe because people install plugins. Also, see https://www.wordfence.com/blog/2016/12/wordpress-table-prefix/

As expected it worked as expected with the above code in Developer Edition. Didn't noticed that before, so thanks for your help and sorry for the noise..

@girish Just wanted to say I finished testing and yes this works great! Thank you so much for the fix!

@jagan by default, Cloudron doesn't set any CSP or CORS headers for apps. The apps set the appropriate CSP for themselves. The CSP setting in Cloudron is only meant to used as an extreme measure (i.e no way to change an app's hardcoded CSP). With this mind, I would remove any custom CSP setting you have added in Cloudron dashboard. This is most likely the wrong approach. Next, I would investigate the CSP/CORS headers sent by WordPress. Per, https://community.adobe.com/t5/acrobat-services-api-discussions/pdf-embed-api-got-error/td-p/13142824 , you need something like Access-Control-Allow-Origin: * sent from WordPress.

@Vladimir Can you explain a bit more what the issue you are trying to solve is and what is that config you have posted? I see that it's some redis config, but what are you looking to achieve?

@girish said in Feature request: Allow choosing PHP version for WordPress (Developer) app (was How to enable CORS on WordPress (Developer)): Feature Requests is for platform code (that's what I think anyway). Wouldn't it take some platform code to enable this in the same way it's been enabled for the LAMP app? In my mind "Feature Requests" is just for "features" as that's what it says on the tin. But no biggie, as you please

@jdaviescoates said in Installed at map.bridport.coop then deleted, then reinstalled on same location: server not found: Is there a way to flush the NXDOMAIN cache on routers/ computers? Not that I am aware of. These days browsers also do their own DNS caching complicating things even more.

@girish strange that you don’t see that error on a fresh instance, that’s how I reproduced the problem before to compare a fresh DB with my used ones and noticed it on the fresh one too. I’ll look into that further. Thanks

@privsec 512mb is the highest I've got any of mine set, and that's mostly just me ramping up things for Nextcloud in the hope it somehow speeds it up. In reality it's not even using half of that. Most I've got on any WordPress website is 256MB. But again, seemingly not even using half of that most of the time. So strange that you're went up so insanely high.

BTW, once configured to use Cloudron mail, you can track the activity in the mail server event log - https://docs.cloudron.io/email/#event-log

Perfect! I ran some tests today with tweaking various numbers and looked at recommendations online too. It's mostly a copy of yours @imc67 in the end but with a lower MaxConnectionsPerChild. Ran a bunch of different tests with different numbers but concluded that was the best bang for the buck so-to-speak given the 4 GB memory max set on each WP app. It's a mix of default values from the Ubuntu install and the default Apache values in the original package too (for the 256 MaxRequestWorkers for example). I'm pleased with the results. Here's what I have for reference now, and I used ab (Apache Benchmark) to run some performance tests and had significant improvements over the defaults. Thought I'd share the testing results in case anyone was interested. New mpm_prefork.conf I'm using: # Restart the app if you make changes to this file <IfModule mpm_prefork_module> # On startup, start these many servers StartServers 5 # At any given time, keep atleast these many servers MinSpareServers 5 # At any given time, keep atmost these many idle servers (this is always >= MinSpareServers+1) MaxSpareServers 10 # Maximum number of servers at any given instant. Requests will be queued after this MaxRequestWorkers 256 # Recycle process after handling these many requests. This protected against accidental memory leaks MaxConnectionsPerChild 500 </IfModule> Resources: https://httpd.apache.org/docs/2.4/mod/prefork.html https://exampleconfig.com/view/apache-ubuntu20-04-etc-apache2-mods-available-mpm_prefork-conf https://www.woktron.com/secure/knowledgebase/133/How-to-optimize-Apache-performance.html https://www.maketecheasier.com/optimizing-apache-part-1/ Results from ab with default settings that come with Cloudron's WP package: (note the rather large spread between min and max request times) Concurrency Level: 50 Time taken for tests: 12.391 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 84813000 bytes HTML transferred: 84205000 bytes Requests per second: 80.70 [#/sec] (mean) Time per request: 619.574 [ms] (mean) Time per request: 12.391 [ms] (mean, across all concurrent requests) Transfer rate: 6684.04 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 227 291 36.4 287 401 Processing: 220 281 122.2 252 1039 Waiting: 144 190 120.0 161 954 Total: 451 572 127.3 546 1285 Percentage of the requests served within a certain time (ms) 50% 546 66% 570 75% 584 80% 594 90% 624 95% 818 98% 1091 99% 1261 100% 1285 (longest request) Results after tweaking to the above new configuration: (note that the max request time here is about 60% faster still than original config results and overall a much more consistent behaviour too!) Concurrency Level: 50 Time taken for tests: 11.358 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 84813000 bytes HTML transferred: 84205000 bytes Requests per second: 88.04 [#/sec] (mean) Time per request: 567.899 [ms] (mean) Time per request: 11.358 [ms] (mean, across all concurrent requests) Transfer rate: 7292.24 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 230 287 26.9 283 389 Processing: 220 252 17.3 249 329 Waiting: 144 160 10.0 157 217 Total: 467 539 33.0 538 649 Percentage of the requests served within a certain time (ms) 50% 538 66% 550 75% 559 80% 567 90% 584 95% 599 98% 618 99% 622 100% 649 (longest request)

@d19dotca that was too easy. Thanks a lot!

@jdaviescoates That did the trick. Thanks for the prompt feedback and suggestion!

@girish okay I’ll try that, thanks for looking into it Girish! It’s definitely odd and I’m surprised I only recently discovered this concern. Some of them definitely existed before Cloudron days and came over as part of the “all in one migration” plugin which I have a feeling overwrite the database to match the original source, so likely is part of the reason there. Some newer ones also have it though but thinking further I think it’s because it was an issue in the template one I spun up new site builds from. I’ll try converting and hopefully that’ll help with some stuff. Will report back on whether it’s successful or not