@girish I requested the developers to review the query. Meanwhile I changed the setting in mysql and indeed the plugin doe work now as expected!

I have tried to fix this in the latest package - https://docs.cloudron.io/apps/wordpress-developer/#email-setup-multisite . I pushed the update last week but it's been rolling out slowly. A new install (which is required for multi-site) will get the latest package.

I think the WP distribution does not have .htaccess files at all and it's only generated when you setup permalinks. I thought maybe atleast wp-content might have .htaccess inside it but even that doesn't. I guess it's up to the user to set those up, if they want to.

I guess the main danger is if your site somehow allows someone to upload php files, then it might get executed under wp-content. But this of course requires one to install such a plugin that let's someone upload random files.

@robi Oh.....😊 well that went way over my head.

@arungurume I think what nebulon meant is he put you on a premium plan with no charge until the issue is sorted out (and not the existing free plan).

@girish yeah, you have to put sftp:// when using the quickconnect because the default for that is just ftp (although I wonder if that can be changed in the settings... I've not looked...)

When just adding a new site in the Site Manager there is just a dropdown and you don't have to type sftp://

Just to say, I just tried installing WordPress Importer again on a new install and this time it worked fine, so whatever the problem was seems to have been resolved.

@girish I think this can be marked as solved (it's too old for me to edit, turn into a question and mark solved myself).

@freetommy that's strange, I cannot think of a reason why it can ever fail. Are you able to roll back to previous WP version? I don't think the issue is related to ubuntu security updates.

@d19dotca I can confirm his fix works as well!

@lonk said in Apache, OLS and Nginx-Custom Benchmarks:

redis is already apart of Cloudron

Yes & no,
Yes is part of the cloudron addon, but it can be integrated in different way.

You can use it for dynamic cache (as cloudron use in there apps), behind the php, db lvl.

You can use it as a Full Page Cache (similar to what Cache Enebler do but in RAM and not in local disc). php lvl

You can use it for partial page caching, in this case is at webserver/proxy lvl.

Redis is just a "database" in RAM, you can use it to store what you want, Redis is not a cache, but you can use it as it was one.

Perhaps try the All in One Migration plugin, at least couple of us have successfully used that to migrate WordPress to Cloudron.

See e.g. this thread on How to move Wordpress.

@jdaviescoates You can just create app password as your own account, no need to create a new user. The idea of app password is that the password only works for that one app. It won't work on the dashboard or any other app. The usual use case is for mobile apps or 3rd party client apps, which you don't want to trust with your primary cloudron password.

It also has an advantage that you can revoke/delete the password anytime.

Adding my two cents in here for anyone who comes along. You can also access the DB using desktop software like Sequel Ace and it's incredibly efficient to me.

@rahim I think best solution is to do this process via command line. Is clean, safe and you can upload any DB size.

Of course, each installation have specific way to follow, depends on specific case.

Eg. if origin domain is the same or different to destination domain.

Also, If both, source and destination, are live. In this case, you've to approach the DNS A field to validate domain on Cloudron.

This below is my procedure, assuming that source and destination have the same domain name and that domain is live.

From the source server you need to export:

mysql.dump wp-content folder

Then you've to create a new instance on Cloudron called "swap". Eg. swap.mydomain.com.

You upload mysql dump to /tmp/ via terminal, and then you import sql DB using command line (you can find info here).

Then you have to upload "wp-content" folder. You can do via FTP or also via Cloudron File Manager. You can upload zip archive and then unzip inside main wp folder.

When you have swap.mydomain.com working, you can use the function app "Backups", using "Clone" on the main domain.

Just before cloning, you have to change A fields in DNS panel, so Cloudron can validate new domain. (You can skip this step if your domain is configured with DNS provider (Eg. Cloudflare or others listed).

Let me know if is all clear and if I can help you.

There's more deep rooted issues - https://github.com/heiglandreas/authLdap/issues/194 . The package itself is wrong and unfortunately wp admin suggests it as an update. Breaking a lot of things.

@girish Nope, tried to debug it. Tried to even repair it. In the end a reboot fixed the problem, but that was pretty weird.

@jodumont I think just having any recommended snippets in the docs would suffice for most, no? Then just copy/paste any you want to use using the File Manager (after making a backup in case it breaks something).

@dreamcatch22 You might have to restart the app after making php.ini changes. Apart from that, you can install something like https://wordpress.org/plugins/php-info-wp/ which should give you phpinfo output to verify is the extensions are enabled.

Hm surfer will send cache-control: public, max-age=0 so I am not sure why it would cache as such, the etag also should have changed if the source content was updated.

@moocloud_matt Thanks for the heads up. The project is still early enough where I can make the switch.

The amazing self solving topic 😉

Right, for the moment it accepts everything till 403

I agree with both of @girish's assessments of the file for the time being. But that doesn't mean that when Cloudron does support multi-site in the future, we can't assess multisite constants. So thanks for bringing it up! It lead me to that really interesting and eye-opening wp-config.php on Github.

@ketchalegend I see. With the above htaccess, I got

curl -X POST -H "Authorization: Bearer 1234567890" https://wp.domain.com/wp-json/jwt-auth/token {"success":false,"statusCode":403,"code":"jwt_auth_invalid_token","message":"Wrong number of segments","data":[]}

So looks like the route is working.

Follow up from the customer: "The issue here turned out to be that in Wordpress, WP Rocket caching plugin was used. This plugin automatically starts to preload the cache of each page once something in the site has been updated. The preload itself causes some stress on the CPU and maybe some other processes. Turning off the plugin, the products were sent for less than 2 mins."

They are working with the WP Rocket team to find a workaround.

@Lonk said in WordPress Developer vs LAMP PHP 7.4:

could test it in the same conditions

yes, I got that after, I just simply did'nt actived it inside WordPress
but at the end it is doing what the WordPress_Dev container doing manually. 😉