Currently, the DNS entry is not there: $ host workingghstandard.com Host workingghstandard.com not found: 3(NXDOMAIN)

@argilmour do you mean https://github.com/Setasign/FPDF?tab=readme-ov-file ?

@dev-cb You won't regret. Likely you'll never want to use another theme or way of building again! If I understand what you're thinking, I use Patterns for that. Very versatile. Their Cloud plugin also makes it easy to share design templates form one site to others.

@girish thx, that solved the problem. Problem was that during migration I replaced the whole wp-content-folder with the folder from the instance I migrated.

@imc67 yeah, I have been following the issue closely. We install the plugin directly from GitHub, so it's not an immediate problem. But we will move to OIDC eventually just like all the other apps. Some more OIDC fixes are coming in 7.7

@dsp76 ouch, I can see why that's confusing . I will change the title atleast of the package to be proper! Best way to switch is to use one of those migration plugins like those in https://docs.cloudron.io/guides/migrate-wordpress/ .

@Dave-Swift You're right, also managed in the same place. Glad you found it!

@LittleSofi said in Cannot log in after all in one wp migration: Did I miss something? Usernames may have changed and pw will be as per db you've just migrated. Use WP CLI to check user list to find username https://docs.cloudron.io/apps/wordpress-developer/#wp-cli

@BetterWP This is not really a Cloudron issue but one you could face moving any WP installation to a different domain. WP is unfortunately very closely tied to the domain. You can do search replace on the database even if the app itself is down. You can also access the file system.

Thank you very much, i'm a greenhorn!

You can of course copy/paste block of ip addresses into apache (with the apache config OR htaccess) with 'deny from' rules. I found https://www.countryipblocks.net/acl.php that can generate htaccess rules even.

That seemed to do the trick - thanks so much @girish

Is this still an issue?

@bmann said in WordPress Migrate Feedback, SMTP Mailer Instructions: This is a restriction in the All-in-One WP plugin Like @scooke says, if we're talking about the same plugin, it isn't. As I said, I recently did one over 1GB.

Closing a loop ... The oldest version of LAMP here runs PHP 7.4 The site with old software is running PHP 7.0 I was not sure whether 7.4 is old enough, or whether the backup/migrate would fail on that version difference also. Not wanting to waste time going down unproductive paths, I deployed a docker container running Wordpress and PHP 7.0 and I've managed to get a restore from the AWS site running. Now in process of upgrading PHP so I can then backup/restore to a Cloudron WP Developer with current software versions. Thank you for your suggestions - got me going in the right direction.

Thanks @girish.

@bmann Cal Video does sound good. No objection to paying for anything. It's per-user pricing that often deters, when most users are very occasional, so the value for each is not the same, but the cost is. It corrupt the way apps are used, as you add an overhead for user license management, and often will create shared users to avoid per-user costs. Until the end of time, I will never charge or happily pay per-user pricing. It's a tax on usage, which is the antithesis to value, especially when there's zero marginal costs to the creator.

@imc67 said in Wordpress apps: authLdap plugin Cross-Site Request Forgery: There is a new version with one of two issues patched And I note that the other issue "only impacts multi-site installations and installations where unfiltered_html has been disabled." As per https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/authldap/authldap-258-authenticated-administrator-stored-cross-site-scripting Also from that page, it sounds like it is only people who are already logged in Admins and above could take advantage of it: makes it possible for authenticated attackers, with administrator-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. So if you trust your Admins it doesn't really seem to be an issue (in my case this is normally only me and I both trust myself and don't have the tech skills to take advantage of this potential exploit), hence why the author of the authLDAP plugin doesn't seem to bothered by it.

Are you seeing any errors in the browser console or app logs when that happens?