@luckow Thanks! Hidden in plain sight 😅

I did quickly try checking documentation first, just not enough, I guess!

Wen CloudronGPT? 😁

@girish 👏👏👏

check out in the options table. I once had a hacked plugin that was writing executable code in the options table, and by that, it was able to reinstall itself again and again.

Well securing the page should be a matter of less than an hour. Just export those pages, make a fresh install and import the pages back in 🙂

Are you talking about https://docs.cloudron.io/apps/#data-directory or some other directory for data within Wordpress?

@humptydumpty Nothing to feel bad for. That's just how GPL works. Plenty of non-GPL platforms they could develop for and not benefit from the size of the market. Microsoft does just fine with a % of unlicensed users, it's just a marketing cost. At the end of the day utility and user counts is worth more. The plugin with 700,000 installs registering on wordpress.org will be getting ample monetisation opportunities. The one with 70 installs likely won't be worth any GPL site unlocking.

@ianhyzy
Update to 6.2 and that message should go away. Other control panels reported this as well but WP saw no need to act on it as there was no likely risk of it being exploited.

@p44 no idea

@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.