WordPress Plugin: Change Admin Email

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.

Plugin in the .org repo
Plugin on Github


Bonus BDD!
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.

I use this as an example of running tests in multiple environments.

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.

Understanding DNS and localhost

The Domain Name System [DNS] is the system a browser uses to resolve domain names like generalchicken.net to IP addresses like 34.197.171.101. A server connected to the internet generally has one IP address, usually one main domain, but it can also have many subdomains. For instance, this server hosts the domains generalchicken.net and another blog, messagetothefish.com. Both have the same IP address, but different domain names.
When an HTTP or HTTPS request is sent to the server, the request should include the host header which indicates to the server what domain a resonse is expected from. A browser like Chrome or Firefox does this automatically for the user.
Internally, once the request is received by the server, a web server, like Apache, sends each request to a particular directory, based on what subdomain is named in the host header. From there, a file is activated, and in our case, passed to the PHP parser. For WordPress, it is called index.php. On most Ubuntu WordPress setups, the main domain root directory is usually set to:
//var/www/html/
and subdomains go from there:
//var/www/html/sub1/
//var/www/html/sub2/

These are the directories [for their respective domains], which will contain the WordPress root files, especially the index.php, the wp-config.php files, and the other directories like:
//var/www/html/wp-admin/
//var/www/html/wp-content/themes/
//var/www/html/wp-content/plugins/
//var/www/html/wp-includes/

Understanding this is important because if you are setting up a local development version of WordPress, you are going to want to be able to set subdomains up. Normally, you’ll have a sepearte wp-config.php file for each domain, specifying which database the domain points to.

The default setup on Ubuntu, is for the domain localhost to point to //var/www/html . Therefore, to access your local WordPress site, open a browser like Chrome, and got to http://localhost/ and you should get the WordPress install screen.

Another consideration is that most forms of testing work the best when you don’t have any state. That is, the database is either reset to a starting point, or totally scrubbed after each test. If you’re not used to this, you may accidentally delete anything you have on your site, especially if you’re using it for anything.

My personal setup is that I use http://localhost/ for unit testing, and I have another WordPress install, called http://laptop.dev/ where I have a database that doesn’t reset.

Directions: Setting up virtual hosts on Ubuntu 16.04 LTS.

Types of WordPress automated tests

state browser database SUT
WP Acceptance tests carries from test to test assumed headfull JS browser [ie. Selenium with Chrome] not reset after each test entire WP application executed with each browser call
Stateless acceptance tests tests run in isolation assumed headless JS browser [ie. PhantomJS] reset after each test entire WP application executed with each browser call
WP Unit tests tests run in isolation assume no browser or only cURL reset after each test WP application NOT executed
WP API tests tests run in isolation cURL only reset after each test WP application is executed

Live MasterMind BDD Group

Sign up to learn Behavior Driven Development in WordPress!

Hi! I’m John Dee. I’m the BDFL here at WordPress BDD. We have a MasterMind group to meet and do BDD in WP!

As a member of the MMG, you will have an opportunity to learn BDD in WordPress, and even get some free work done for your own projects. We take turns building classes and tests for each member of the MMG, so bring your development issues and we’ll solve them, the devops way!

We do a live screencast on Google Hangouts anytime I get 5 people who want to do TDD.

Topics:

  • Setting up CodeCeption for WordPress in the cloud
  • acceptance testing in WordPress
  • unit testing in WordPress
  • Gherkin feature files

Contact John to sign up!

e. johndeebdd@gmail.com
sms. (702)748-5491