Category: Uncategorized

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.

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].

Security Flaw in WordPress: A Flawed Email Confirmation Feature

Introduction:

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.

Purpose of the Email Confirmation Feature:

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.

Issues with the Current Implementation

1. Confusion Between Roles in Single-Site vs. Multisite Installations:

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.

2. Arbitrary Code Execution Makes the Feature Pointless:

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.

3. Transient Data Exposure and Security Risks:

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.

4. Inconsistent Logic for Admin Roles:

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?

Fundamental Flaw: False Security in Single-Site Installations

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.

Encryption Problem: Non-Standard and Insecure

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?

Conclusion: A Poorly Implemented Design Choice

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.

A shortcode is a system object, so I use the naming convention:

ShortcodeMyCode.class.php

class MyCode

public function returnShortcode(){
$stringHellowWorld = __('String hellow world!', 'textDomain');

$shortCodeOutput = <<