General Chicken publishes a plugin in the .org repo: Change Admin Email Setting Without Outbound Email
As of WordPress 4.9, the administrator cannot change the site admin email without outgoing email setup on the server, and recipient email credentials. This plugin restores the admin’s ability to change this setting without sending a confirmation email.
As a bonus, for developers I’m distributing some BDD Codeception tests with this plugin. The tests are designed to run via the WordPress module from Codeception. To run them, you’ll need composer, selenium, and chrome. To pull the framework, use the instructions here.
When building this, I used TDD / BDD by creating an acceptance test that worked on v3.9 so that I could run the same test against v4.9. This is overkill, but I wanted to show how to run tests against different environments.
WordPress has some very simple i18n functions that can spit out manuals translations of anything into the user’s local language. i18n is a programming acronym for Internationalization and localization. That’s 18 letters between the “i” and “n”.
__() and _e() [note, that’s two underscores “__” and one underscore “_”]
Here is the reference in the codex:
I18n for WordPress Developers
Basically, WordPress has a tremendous i18n system that scans all the PHP files in the request BEFORE there are sent to the PHP engine. Translations are stored in web standard .po and .pot files, and are rendered based on the language set in the browser.
Now for content, you don’t need to re-invent the wheel as there are already plenty of good i18n plugins to choose from.
It can be done, but this is a seriously bad idea. If something is causing the site to crash when core or plugin updates happen, you need to solve the issue that is causing the problem, not rollback updates! If it’s a commercial site with value in any way, it’s pretty insane to setup a policy to keep updates rolled back. I suppose there could be a research reason or testing reason to do this, but I’m baffled by anyone doing this on a forward facing production site. DON’T DO THIS. KEEP YOUR SITE UPDATED.
1% of problems we won’t talk about here. None of this advice applies to you.
98% of “I have a slow WordPress site” problems:
Cache plugins will NOT speed up your website significantly.
The number of plugins will not effect your site speed.
Putting your site on a CDN will not speed up your site.
Slow shared hosting – This has nothing to do with WordPress per se. It’s just that there are many WordPress blogs on shared hosts and they are often slow. You can run any kind of website slowly on a shared host. Some companies like GoDaddy or BlueHost can have thousands of websites running on one physical system. The interesting thing is that high speed, cloud based servers on Amazon or Google are actually cheaper than shared hosts. Of course, you have to learn how to setup a server! So this is a funny issue because it isn’t really about WordPress, it’s more about the economics of computer systems and the economics of knowledge. Anyway, if you’re a human being raising your hand saying, “My WordPress website is slow” the answer to your problem is to learn how to setup a WordPress server, or hire someone who can. Your problem is you just don’t know how to do something simple. It’s like not knowing how to put gas in your car, and not understanding why it won’t move.
Improperly uploaded or linked images
The other 1% of WordPress speed problems come from improperly adding images. When you upload to the media library, dy default WordPress rescans the image into three different sizes. If you use a properly coded theme from the free repo, your theme will serve the correct image to the user.
Solution for 98%:
Properly upload images via the media uploader.
Simply pay for faster hosting.
Yes. You can restore previous changes made on “pages”. By default, WordPress has two post types. You can also have custom post types called anything [i.e. tickets, or calendars etc.]. The two default post types are “posts” and “pages”. Pages have a screen option called revisions which allow you to browse through previously saved pages. You can restore any previously saved post if you have the role “editor” or above. This feature can be enabled on any post type by a developer, and is enabled by default on pages.