Behavior Driven Development in WordPress
General Chicken publishes a plugin in the wordpress.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 wordpress.org repo:
https://github.com/johnpbloch/wordpress
Gutenberg and the Future of WordPress: Conditions for Success
The Ultimate Overview of the WordPress Block Editor (Gutenberg) for Developers in 2022
https://dev.to/scottybo/classicpress—a-wordpress-fork-without-gutenberg-2e6f
https://dev.to/scottybo/classicpress—a-wordpress-fork-without-gutenberg-2e6f/comments
https://digwp.com/2017/11/thoughts-on-gut
https://john.onolan.org/project-ghost/enberg/
https://packagist.org/packages/jesseberkhof/wordpress-fork
Time to Fork WordPress for Enterprise Power or Blogger Simplicity?
The human race needs and deserves a true open source CMS system. I believe the time has come for developers to fork the WordPress ecosystem away from the Automattic corporation and the WordPress Foundation.
Is WordPress really open source?
Does the human race need WordPress?
How the WordPress Foundation lies to the deveopers
Fixed Price
You know up front the cost
Generally less expensive
Plugins and Outsourcers
I use commercial plugins where I can. Why re-invent the wheel? I generally do not use commercial themes, but I do use professional designers.
Myself, and many other developers think that the WordPress Foundation has outlived it’s usefullness. I am calling on other devs to help fork the platform away from the this corrupt organization.
WHo owns WordPress.
WordPress is “owned
The WordPress foundation is corrupt.
Now when I say that, I first want to thank them for their fantastic work in the past. However, because of issues of free press, democracy, humanism, and humanity: we need a global, open source, content manangement and publishing platform, that is free, has wide, ubiquituous adoption, and which isn’t controlled by nation state or corporate interests.
Introductin FreePress.
What technologies are you using?
What needs do you think they full fill?
What value do these tech provide?
What is your dev process?
How many people are employed?
What roles do people play in the company?
Do you use outsources?
Plugin domain: server side / client side / mix ?
api?
Networking?
Auth?
What does the plugin do?
Are you using BDD / TDD?
Are you testing post development?
Agile, Srum, mix, face to face, JIRA?
Testing frameworks? Libraries?
Roles in BDD? Same person who writes tests solves them?
Tests written first or after?
Pair programming, Group? mob? cubicle?
The WordPress developer community should overthrow the Foundation and create a truly open sourced CMS platform for humanity to use.
The WordPress Foundation is a mere shill for Automatic, and a serious threat to the platform. Multi-site, and now Gutenberg, are both obvious attempts to inject their own corporate interests at the expense of the community.
More to come. If you’d like to read more, make a comment.
In WordPress 4.9 a new feature was added where a confirmation email is sent when an administrator tries to change the site email. In WordPress, the ultimate role is administrator. There is a flag for an
As will be shown, the new feature actually requires three seperate user roles: an installing-admin, a change-initiator-post-install-admin, change-completor-post-install-admin, and these can be different users with different implied capabilities, although this doesn’t seam to have been considered.
| Role | |
| installing-admin | can set site admin email without confirmation |
| post-install-admin |
cap#1: the capabilitiy to set the site email without confirmation. cap#2: the ability to set it with confirmation. It is my contention this is not clearly understood.
The error comes from the fact that in multisite, there are in fact two roles: super admin, and regular administrator. These roles usually coincide with the different capabilties. Under most work flows using multisite, there is a peer class [usually one induvidual user per site per class, but it could be many users] of users that defines these implied roles. In other words, on multisite, usually there is one super admin, and one regular admin per domain, and the fact that this feature requires two different sets of capabilities wasn’t noticed before because there are in fact two user types in multisite. On single site, there are just “administrators” – one peer class of users with the same [or they SHOULD be the same] capabilities. My contention is that this new feature creates an illogical jumble of the capabilities in single site, and this was not noticed because the bifiracaption wasn’t noticed on multisite [where the feature came from].
There is a business value to the use case pattern on many internet platforms where a confirmation email is sent, and then an encrypted or nonced link must be clicked to perform the confirmation action. The value of the features is:
The pattern confirms the user receiving the email has credential access to the receiving email account, reducing SPAM, and increasing security.
When you signup for Facebook, they send you an email with a link to confirm your account before it become active. This proves to Facebook that the recipient email is alive, and the http user requesting the account has recipient credentials for the email account.
This seams to be the intended purpose behind the admin email confirmation feature as of 4.9, as well as providing additional security to the system. My contention is that this is a confused purpose, and in fact renders WordPress LESS secure for several reasons.
Similiarity to the add user feature
When a user registers for a WordPress site, a confirmation email is sent to him from the site, to confirm the user has access to the email. This valid use case, is identical to the one used by facebook.com, described above. It is the confirmation of some information between two human groups / persons [the stakeholders of the site, and the user who is trying to register].
It is important to understand: THIS IS NOT A SECURITY FEATURE! An administrator can run arbitrary code. There is a check box available for administrators to override the outbound email:
Why can’t this emial be a true security feature?
In computer science, there is a concept called “arbitrary code”. A user who can run arbitrary code can literally do anything on the system, and can’t be restricted.
WordPress introduced a feature in version 4.9 requiring an email confirmation link to change the site email address. While this feature aims to enhance security by verifying that the user has access to the new email address, I argue that it creates confusion and weakens security in certain contexts, particularly in single-site WordPress installations.
The idea behind this feature is to ensure that the person requesting a site email change can access the new email address, preventing SPAM, reducing mistakes, and confirming that the email is active. This pattern is widely used in platforms like Facebook, where a confirmation email is sent to verify identity before account changes are made. However, in WordPress, the implementation of this feature—especially on single-site installations—introduces more problems than it solves.
In a multisite installation, there are two distinct admin roles: super admin and regular administrator. These roles have different capabilities, making the email confirmation feature somewhat logical. The super admin has authority over the network, while regular admins manage individual sites. However, on a single-site installation, there is only one type of admin, and this feature introduces unnecessary role confusion by implying there are two distinct roles: an “installing admin” and a “post-install admin.”
This distinction doesn’t apply to single-site installations, where all admins have the same capabilities. The requirement for email confirmation adds complexity, making it harder for admins to understand their permissions. It also creates an inconsistent experience between single-site and multisite installations.
In WordPress, admins can run arbitrary code, giving them unrestricted control over the site. This means an admin can bypass the email confirmation process by simply running code that changes the site email. As a result, the feature gives a false sense of security. If an admin has the power to run code, the system shouldn’t impose an artificial restriction that they can easily work around. The current implementation pretends to enforce security, but admins can still override it.
During the email confirmation process, the old and new email addresses are both stored in the database, potentially for a long period of time. This creates a window of vulnerability where sensitive information could be exposed, especially if backups are taken during this transient period. Storing two email addresses for no clear reason seems like an unnecessary security risk.
The feature assumes that admins need to confirm email addresses, but this is inconsistent with how other admin actions work. For example, when an admin creates a new user, they can skip sending a confirmation email. This inconsistency makes the email confirmation requirement for site email changes feel arbitrary and out of place. If email confirmation is necessary for security, why isn’t it applied to more critical settings like the site URL?
The core issue with this feature is that it doesn’t make sense in the context of single-site installations, where admins have equal power. The process of confirming the email doesn’t prevent admins from making changes if they can run arbitrary code. This false restriction can confuse admins, leading them to believe they are limited when, in reality, they are not.
Additionally, WordPress allows users to install the platform without outbound email access. During installation, the site email can be set without confirmation, but after installation, the same user is blocked from changing it without email credentials. This inconsistency makes the feature feel more like an oversight than a security enhancement.
One significant concern is that the encryption method used for the site email confirmation link is a custom MD5 hash, which is weaker than the standard WordPress nonce system. This inconsistency introduces potential security vulnerabilities, as custom solutions are typically less robust and harder to maintain than standardized approaches. The user email change system, for example, uses the nonce system, which is extensible and more secure. Why wasn’t the same method used for site email changes?
This email confirmation feature in WordPress 4.9 was likely added with good intentions, but it introduces more complexity and confusion than necessary, especially for single-site installations. The reliance on email confirmation for a setting that an admin can bypass with code creates a false sense of security. Moreover, the custom encryption used is less secure than standard options available in WordPress. While preventing typos in email addresses might be a reasonable goal, the approach taken is overkill and creates more problems than it solves.
In conclusion, this feature should either be rolled back or significantly rethought to align with WordPress’s actual user roles and security needs. Admins with the ability to run arbitrary code should not be subject to artificial restrictions, and any system that claims to enhance security should not introduce new vulnerabilities in the process.
