classicpress / classicpress

The CMS for Creators. Stable. Lightweight. Instantly Familiar. Forked from WordPress.

ClassicPress: The CMS for Creators. Stable. Lightweight. Instantly Familiar.

ClassicPress is a community-led open source content management system for creators. It is a fork of WordPress 6.2 that preserves the TinyMCE classic editor as the default option. It is half the size of WordPress, contains less bloat improving performance, and has no block editor (Gutenberg/Full Site Editing).

For more information, see:

• The official ClassicPress website ›
• The ClassicPress documentation ›
• The ClassicPress governance ›
• Suggest features ›

Contributions

This project exists thanks to all the people who contribute and who have contributed in the past, whether as part of the long history of thousands of contributions to WordPress from many different people, or as contributions to ClassicPress itself.

Would you like to help? Here is how you can start ›

Sponsors

Corporate sponsors that believe in ClassicPress. Become a sponsor › All donations are tax-deductible in the United States.

Financial Contributors

Support the ClassicPress project by making a donation › All donations are tax-deductible in the United States.

Individuals

Organizations

classicpress's Issues

ClassicPress updates should not overwrite composer.json

On sites that use a customized composer.json, this file will be overwritten when ClassicPress is updated (manually or automatically). This is not the desired behavior as any dependencies will be lost.

We need to modify the update code to avoid overwriting composer.json. A couple of options:

• Never overwrite composer.json
• Detect whether composer.json has been modified and overwrite it if no customizations have been made

Add constants to support SSL connections for mysqli

As per this requested and pretty much ignored ticket #28625 (Enhancement: Add constants to support SSL connections for mysqli) – WordPress Trac 3 Allow SSL connection to mysqli - absolute madness this is not in core.

Original Petition

Load wp-settings in wp-load vs at end of wp-config

This issue was split off from ClassicPress/ClassicPress-v1#192 and I am copying over and attributing the relevant comments thus far.

The idea is to make /wp-config.php just a file to contain configuration and not part of the a persistent part of the callstack for the entirety of a page load.

Doing this will make it easier and more reliable for tools like WP CLI to load a site's configuration without having to eval() a hacked version of /wp-config.php. However, that is only one reason for this.

Given the currently architecture, it is hard to establish a configuration file or set of configuration files that can be committed to version control that can be deployed reliably to different managed web hosts and without a build step.

All of the major managed hosts have chosen to implement their own configuration which makes this even more difficult. Since WordPress as a project provided no guidance for what parts of the configuration needed to be defined by the user and which parts were available to be defined by the host.

Upon reflection I do not believe the simple change of moving the loading of /wp-settings.php from the end of wp-config.php to the end of /wp-load.php will break any sites or any tools. We can even wrap the loading of /wp-settings.php at the end of /wp-load.php with an if (defined('WPINC')) so that any ClassicPress site using a WordPress-style /wp-config.php that ends with a call to /wp-settings.php will still work correctly.

OTOH making this change will allow for innovation that has thus far been stifled by the current structure.

NOTE: This is more detailed than the original mention in ClassicPress/ClassicPress-v1#192 so neither @Mte90 or @nylen whose responses I copied did not have the benefit of reading the full justification above.

Core Plugin: Embed API

Move embed API to a core plugin (discussion).

Make Grunt files compatible with Windows

I'm not 100% sure, but I believe my issue with Grunt is due to Windows. Reading up on the error, I found this:

Istanbul assumes that the command passed to it is a JS file (e.g. Jasmine, vows etc.), this is however not true on Windows where npm wrap bin files in a .cmd file. Since Istanbul can not parse .cmd files you need to reference the bin file manually.

It's instructions from a different package on how to make it compatible with Windows, which was the answer to the same error I have.

Expected behavior

grunt precommit works as expected.

Current behavior

grunt precommit errors out:

PS C:\WinNMP\WWW\ClassicPress> grunt precommit
Running "rollup" task
Fatal error: C:\WinNMP\WWW\ClassicPress\node_modules\.bin\rollup:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^

SyntaxError: missing ) after argument list
    at Object.compileFunction (node:vm:352:18)
    at wrapSafe (node:internal/modules/cjs/loader:1031:15)
    at Module._compile (node:internal/modules/cjs/loader:1065:27)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

Possible solution

Refer to description. It should help figuring out the issue.

Tiny MCE tooltip for adding links in classic editor disappears and is not clickable.

Expected behavior

Tooltip pops up, lets you add link and click the return icon button.

Current behavior

Tiny MCE tooltip for adding links in classic editor disappears and is not clickable. This occurs with certain window heights and widths and not others. Bug seems to occur above window height of around 800px.

cp-bug.mp4

Possible solution

Probably an errant onmouseleave event handler?

Steps to reproduce (for bugs)

Install fresh copy of Classic Press

Edit Hello World Post.

Try and make a link out of 'writing' in the post content and save it.

Context

Confirmed in

Chrome 88.0.4324.77 (Official Build) beta (x86_64) on MacOS Big Sur 11.1 (20C69)

and

Safari Version 14.0.2 (16610.3.7.1.9) on MacOS Big Sur 11.1 (20C69)

Don't show "database upgrade" screen after migrating from WP 5.0

When migrating from WP 5.0 to ClassicPress using the migration plugin, a database upgrade screen is shown. This is because in WordPress 5.0.0, the $wp_db_version variable was changed from 38590 to 43764.

However, surprisingly enough, there were no database changes with the introduction of Gutenberg in WP 5.0.0. This change is instead used to deactivate the Gutenberg plugin when upgrading from WP 4.x to 5.x.

So, in the ClassicPress upgrade routine, we can ignore this particular pair of $wp_db_version values and avoid showing this screen.

See also:

• ClassicPress/ClassicPress-Migration-Plugin#44
• WordPress/wordpress-develop@583e422

Implement Clean URLs in the Admin

WordPress’ admin console with all the .php URLs is a rat’s-nest of usability issues.

I propose we consider adding in a Front Controller and make simplified, clean and hackable URLs for the admin. This would be a combination of retrofitting existing admin URLs where there UX is salvagable, and creating new admin page functionality to replace some of aging admin functionality in WordPress.
https://en.wikipedia.org/wiki/Front_controller

Original petition

Fields

If ClassicPress is really going to be a CMS it needs to have simple custom fields and custom views (see Drupal).

Fields API was a feature project 2 years ago: https://github.com/sc0ttkclark/wordpress-fields-api

"Future security updates will be applied automatically" message is not shown

Currently, the following code indicating that "future security updates will be applied automatically" will never be triggered:

ClassicPress/src/wp-admin/update-core.php

Lines 186 to 199 in cf5f3de

	require_once ABSPATH . 'wp-admin/includes/class-wp-upgrader.php';
	$upgrader = new WP_Automatic_Updater;
	$future_minor_update = (object) array(
	'current' => $wp_version . '.1.next.minor',
	'version' => $wp_version . '.1.next.minor',
	'php_version' => $required_php_version,
	'mysql_version' => $required_mysql_version,
	);
	$should_auto_update = $upgrader->should_update( 'core', $future_minor_update, ABSPATH );
	if ( $should_auto_update ) {
	echo '<p>';
	_e( 'Future security updates will be applied automatically.' );
	echo "</p>\n";
	}

More info about this code path:

ClassicPress/src/wp-admin/includes/class-wp-automatic-updater.php

Lines 130 to 152 in cf5f3de

	public function should_update( $type, $item, $context ) {
	// Used to see if WP_Filesystem is set up to allow unattended updates.
	$skin = new Automatic_Upgrader_Skin;
	if ( $this->is_disabled() )
	return false;
	// Only relax the filesystem checks when the update doesn't include new files
	$allow_relaxed_file_ownership = false;
	if ( 'core' == $type && isset( $item->new_files ) && ! $item->new_files ) {
	$allow_relaxed_file_ownership = true;
	}
	// If we can't do an auto core update, we may still be able to email the user.
	if ( ! $skin->request_filesystem_credentials( false, $context, $allow_relaxed_file_ownership ) || $this->is_vcs_checkout( $context ) ) {
	if ( 'core' == $type )
	$this->send_core_update_notification_email( $item );
	return false;
	}
	// Next up, is this an item we can update?
	if ( 'core' == $type )
	$update = Core_Upgrader::should_update_to_version( $item->current );

ClassicPress/src/wp-admin/includes/class-core-upgrader.php

Lines 318 to 330 in cf5f3de

	public static function _auto_update_enabled_for_versions(
	$ver_current,
	$ver_offered,
	$auto_update_core
	) {
	// Parse the version strings.
	$current = self::parse_version_string( $ver_current );
	$offered = self::parse_version_string( $ver_offered );
	// Ensure they are valid.
	if ( ! $current || ! $offered ) {
	return false;
	}

See also ClassicPress/ClassicPress-v1#156, #357.

List and recognize ClassicPress contributors

We need to come up with a better way to list and recognize ClassicPress contributors.

Previously we were using OpenCollective to show a list of all code contributors, but as pointed out in #271, this shows past WordPress contributors together with active ClassicPress contributors, which is not ideal.

Ideally our contributions list should include people who have participated in discussions, helped with marketing efforts, donated, etc.

GitHub is a good data source for a lot of these items. Commits, issue and PR body texts, discussion and review comments, etc can be fetched using their API.

Once we build something to collect this data, we can also use it to assign badges on our forums.

See also:

• https://opencollective.com/classicpress/contributors.svg?width=890&button=false (the previous list of contributors)
• https://github.com/opencollective/opencollective-images/blob/2ab6fdf92e8496465bce507fe22fe2fd7b574895/src/server/controllers/collectives.js
• LAST_WP_COMMIT...develop (a list of code contributions to ClassicPress)
• https://github.com/discourse/discourse-github/blob/50c42d8a0b39106bce72935eb8c216a5c522b50d/app/lib/github_badges.rb (a Discourse plugin to add badges based on the history of a git repository)

💡 Add an Object-Relationship Table

Context

The two things missing from WordPress to make it a stellar CMS is Fields functionality and Posts (and other objects) Relationships functionality.

I requested this 8 years ago for WordPress, and we still don’t have one (one of the reasons we can’t have nice things.)
https://core.trac.wordpress.org/ticket/14513

Back then I called it posts_relationships but really it should be object_relationships to support many-to-many relationships for post-to-post, post-to-user, post-to-taxonomy, post-to-term, user-to-user, user-to-taxonomy, etc. etc.

Original petition

Possible implemantion

@KTS915 created a plugin for object relationships, which can be used as a basis for core implementation:
https://github.com/KTS915/Object-Relationships

I think it’s the basis for core implementation. The reasons are (a) it’s very flexible, (b) it works in a very similar way to current tables, and (c) most importantly, putting it in core would mean devs could rely on its existence and use standardized functions to make use of it.

Possible Solution

Object relationships plugin (see above)

Will you be able to help with the implementation?

Migrating petition from the forum.

Implement usage of composer autoloading

As business developer i use often the composer autoloading feature, especially when adopting a private repository like satis. This is a missing feature on wordpress since the fact it has been started in "old php times" when composer was just a dream.

I think it would be a brilliant feature enabling the composer autoloading including hooks from wpackagist.

NOTE: bedrock already does it https://roots.io/using-composer-with-wordpress/ in some sort of way

Core Plugin: XML-RPC

Move XML-RPC to core plugin (orginal petition).

Show error notice in admin when debugging is enabled

A lot of users, including developers, forget to disable WP_DEBUG after they finish troubleshooting. A simple error notice in admin would be a helpful reminder that debugging is enabled. We do that for all of our hosting customers. It’s very helpful, reminds me to disable it frequently.

I’ve seen debug.log files in GBs in size because people forget to disable it for years.

Original petition

Core Plugin: Gravatars

Move Gravatars to a core plugin.

Image build differences, maybe platform based

The grunt precommit:image command invokes image minification on core images in the wp-admin and wp-includes folders. The process should be platform agnostic and produce the same results.

Expected behavior

There should be no changes recorded by git running this command on the develop branch on any platform

Current behavior

When I run the above command on MacOS (12.0.1) I get changes captures in git for 39 images (diff below)

diff --git a/src/wp-admin/images/bubble_bg-2x.gif b/src/wp-admin/images/bubble_bg-2x.gif
index 8e34e01dcd..21302a34dc 100644
Binary files a/src/wp-admin/images/bubble_bg-2x.gif and b/src/wp-admin/images/bubble_bg-2x.gif differ
diff --git a/src/wp-admin/images/bubble_bg.gif b/src/wp-admin/images/bubble_bg.gif
index 2888d9a6bc..bcf74c4854 100644
Binary files a/src/wp-admin/images/bubble_bg.gif and b/src/wp-admin/images/bubble_bg.gif differ
diff --git a/src/wp-admin/images/date-button-2x.gif b/src/wp-admin/images/date-button-2x.gif
index 49ff233113..281a6654fa 100644
Binary files a/src/wp-admin/images/date-button-2x.gif and b/src/wp-admin/images/date-button-2x.gif differ
diff --git a/src/wp-admin/images/date-button.gif b/src/wp-admin/images/date-button.gif
index 66ba110028..326a7b71ca 100644
Binary files a/src/wp-admin/images/date-button.gif and b/src/wp-admin/images/date-button.gif differ
diff --git a/src/wp-admin/images/loading.gif b/src/wp-admin/images/loading.gif
index 12d31e3b49..3778ebceb6 100644
Binary files a/src/wp-admin/images/loading.gif and b/src/wp-admin/images/loading.gif differ
diff --git a/src/wp-admin/images/media-button-image.gif b/src/wp-admin/images/media-button-image.gif
index 56a974731d..69efa7b484 100644
Binary files a/src/wp-admin/images/media-button-image.gif and b/src/wp-admin/images/media-button-image.gif differ
diff --git a/src/wp-admin/images/media-button-music.gif b/src/wp-admin/images/media-button-music.gif
index 8fcd3530eb..8e9a30aab2 100644
Binary files a/src/wp-admin/images/media-button-music.gif and b/src/wp-admin/images/media-button-music.gif differ
diff --git a/src/wp-admin/images/media-button-other.gif b/src/wp-admin/images/media-button-other.gif
index 4a19efd3f7..2a7c35dc10 100644
Binary files a/src/wp-admin/images/media-button-other.gif and b/src/wp-admin/images/media-button-other.gif differ
diff --git a/src/wp-admin/images/media-button-video.gif b/src/wp-admin/images/media-button-video.gif
index 405083b0b3..9b4a7963ea 100644
Binary files a/src/wp-admin/images/media-button-video.gif and b/src/wp-admin/images/media-button-video.gif differ
diff --git a/src/wp-admin/images/wpspin_light-2x.gif b/src/wp-admin/images/wpspin_light-2x.gif
index 25a6254bf9..fe5dea6290 100644
Binary files a/src/wp-admin/images/wpspin_light-2x.gif and b/src/wp-admin/images/wpspin_light-2x.gif differ
diff --git a/src/wp-admin/images/wpspin_light.gif b/src/wp-admin/images/wpspin_light.gif
index 7c0c698a23..a080e51f49 100644
Binary files a/src/wp-admin/images/wpspin_light.gif and b/src/wp-admin/images/wpspin_light.gif differ
diff --git a/src/wp-admin/images/xit-2x.gif b/src/wp-admin/images/xit-2x.gif
index 2415429207..040107a90f 100644
Binary files a/src/wp-admin/images/xit-2x.gif and b/src/wp-admin/images/xit-2x.gif differ
diff --git a/src/wp-admin/images/xit.gif b/src/wp-admin/images/xit.gif
index bf9452e5f9..2790d2113f 100644
Binary files a/src/wp-admin/images/xit.gif and b/src/wp-admin/images/xit.gif differ
diff --git a/src/wp-includes/images/smilies/icon_arrow.gif b/src/wp-includes/images/smilies/icon_arrow.gif
index ce6f1f6216..9f7976c615 100644
Binary files a/src/wp-includes/images/smilies/icon_arrow.gif and b/src/wp-includes/images/smilies/icon_arrow.gif differ
diff --git a/src/wp-includes/images/smilies/icon_biggrin.gif b/src/wp-includes/images/smilies/icon_biggrin.gif
index 2752870a20..c994014ad9 100644
Binary files a/src/wp-includes/images/smilies/icon_biggrin.gif and b/src/wp-includes/images/smilies/icon_biggrin.gif differ
diff --git a/src/wp-includes/images/smilies/icon_confused.gif b/src/wp-includes/images/smilies/icon_confused.gif
index 017ff881d1..c8b5f6a75d 100644
Binary files a/src/wp-includes/images/smilies/icon_confused.gif and b/src/wp-includes/images/smilies/icon_confused.gif differ
diff --git a/src/wp-includes/images/smilies/icon_cool.gif b/src/wp-includes/images/smilies/icon_cool.gif
index 16c568f7ea..e04af62a92 100644
Binary files a/src/wp-includes/images/smilies/icon_cool.gif and b/src/wp-includes/images/smilies/icon_cool.gif differ
diff --git a/src/wp-includes/images/smilies/icon_cry.gif b/src/wp-includes/images/smilies/icon_cry.gif
index 5cdba7f42c..03b2ffdc96 100644
Binary files a/src/wp-includes/images/smilies/icon_cry.gif and b/src/wp-includes/images/smilies/icon_cry.gif differ
diff --git a/src/wp-includes/images/smilies/icon_eek.gif b/src/wp-includes/images/smilies/icon_eek.gif
index ac1865a3bf..e21f3e095a 100644
Binary files a/src/wp-includes/images/smilies/icon_eek.gif and b/src/wp-includes/images/smilies/icon_eek.gif differ
diff --git a/src/wp-includes/images/smilies/icon_evil.gif b/src/wp-includes/images/smilies/icon_evil.gif
index 428e56522d..8998434ba4 100644
Binary files a/src/wp-includes/images/smilies/icon_evil.gif and b/src/wp-includes/images/smilies/icon_evil.gif differ
diff --git a/src/wp-includes/images/smilies/icon_exclaim.gif b/src/wp-includes/images/smilies/icon_exclaim.gif
index f8e34ac66e..1e355d6cdc 100644
Binary files a/src/wp-includes/images/smilies/icon_exclaim.gif and b/src/wp-includes/images/smilies/icon_exclaim.gif differ
diff --git a/src/wp-includes/images/smilies/icon_idea.gif b/src/wp-includes/images/smilies/icon_idea.gif
index 09b2353c28..3ce797646d 100644
Binary files a/src/wp-includes/images/smilies/icon_idea.gif and b/src/wp-includes/images/smilies/icon_idea.gif differ
diff --git a/src/wp-includes/images/smilies/icon_lol.gif b/src/wp-includes/images/smilies/icon_lol.gif
index f9ea0715fc..3612734615 100644
Binary files a/src/wp-includes/images/smilies/icon_lol.gif and b/src/wp-includes/images/smilies/icon_lol.gif differ
diff --git a/src/wp-includes/images/smilies/icon_mad.gif b/src/wp-includes/images/smilies/icon_mad.gif
index f42f613fbb..5f233d7130 100644
Binary files a/src/wp-includes/images/smilies/icon_mad.gif and b/src/wp-includes/images/smilies/icon_mad.gif differ
diff --git a/src/wp-includes/images/smilies/icon_mrgreen.gif b/src/wp-includes/images/smilies/icon_mrgreen.gif
index 92d9c4443b..7bc5c0a42b 100644
Binary files a/src/wp-includes/images/smilies/icon_mrgreen.gif and b/src/wp-includes/images/smilies/icon_mrgreen.gif differ
diff --git a/src/wp-includes/images/smilies/icon_neutral.gif b/src/wp-includes/images/smilies/icon_neutral.gif
index 48ab282dc2..3ab93cd696 100644
Binary files a/src/wp-includes/images/smilies/icon_neutral.gif and b/src/wp-includes/images/smilies/icon_neutral.gif differ
diff --git a/src/wp-includes/images/smilies/icon_question.gif b/src/wp-includes/images/smilies/icon_question.gif
index d23fbc7eb8..5a595ba9c2 100644
Binary files a/src/wp-includes/images/smilies/icon_question.gif and b/src/wp-includes/images/smilies/icon_question.gif differ
diff --git a/src/wp-includes/images/smilies/icon_razz.gif b/src/wp-includes/images/smilies/icon_razz.gif
index 77ad1e2295..5bbfd95e73 100644
Binary files a/src/wp-includes/images/smilies/icon_razz.gif and b/src/wp-includes/images/smilies/icon_razz.gif differ
diff --git a/src/wp-includes/images/smilies/icon_redface.gif b/src/wp-includes/images/smilies/icon_redface.gif
index d41e7f00e0..2adb4f2556 100644
Binary files a/src/wp-includes/images/smilies/icon_redface.gif and b/src/wp-includes/images/smilies/icon_redface.gif differ
diff --git a/src/wp-includes/images/smilies/icon_rolleyes.gif b/src/wp-includes/images/smilies/icon_rolleyes.gif
index b0bc06a505..9f83242cd3 100644
Binary files a/src/wp-includes/images/smilies/icon_rolleyes.gif and b/src/wp-includes/images/smilies/icon_rolleyes.gif differ
diff --git a/src/wp-includes/images/smilies/icon_sad.gif b/src/wp-includes/images/smilies/icon_sad.gif
index 7fe84e9fdb..75f2a41944 100644
Binary files a/src/wp-includes/images/smilies/icon_sad.gif and b/src/wp-includes/images/smilies/icon_sad.gif differ
diff --git a/src/wp-includes/images/smilies/icon_smile.gif b/src/wp-includes/images/smilies/icon_smile.gif
index 148ca0d2c6..3abf3b2213 100644
Binary files a/src/wp-includes/images/smilies/icon_smile.gif and b/src/wp-includes/images/smilies/icon_smile.gif differ
diff --git a/src/wp-includes/images/smilies/icon_surprised.gif b/src/wp-includes/images/smilies/icon_surprised.gif
index 601dfa9694..b84fcb42b0 100644
Binary files a/src/wp-includes/images/smilies/icon_surprised.gif and b/src/wp-includes/images/smilies/icon_surprised.gif differ
diff --git a/src/wp-includes/images/smilies/icon_twisted.gif b/src/wp-includes/images/smilies/icon_twisted.gif
index 535c10f1f4..04457db356 100644
Binary files a/src/wp-includes/images/smilies/icon_twisted.gif and b/src/wp-includes/images/smilies/icon_twisted.gif differ
diff --git a/src/wp-includes/images/smilies/icon_wink.gif b/src/wp-includes/images/smilies/icon_wink.gif
index 8edacae8fb..ab04b93c0e 100644
Binary files a/src/wp-includes/images/smilies/icon_wink.gif and b/src/wp-includes/images/smilies/icon_wink.gif differ
diff --git a/src/wp-includes/images/wpspin-2x.gif b/src/wp-includes/images/wpspin-2x.gif
index 25a6254bf9..fe5dea6290 100644
Binary files a/src/wp-includes/images/wpspin-2x.gif and b/src/wp-includes/images/wpspin-2x.gif differ
diff --git a/src/wp-includes/images/wpspin.gif b/src/wp-includes/images/wpspin.gif
index 7c0c698a23..a080e51f49 100644
Binary files a/src/wp-includes/images/wpspin.gif and b/src/wp-includes/images/wpspin.gif differ
diff --git a/src/wp-includes/images/xit-2x.gif b/src/wp-includes/images/xit-2x.gif
index 2415429207..040107a90f 100644
Binary files a/src/wp-includes/images/xit-2x.gif and b/src/wp-includes/images/xit-2x.gif differ
diff --git a/src/wp-includes/images/xit.gif b/src/wp-includes/images/xit.gif
index bf9452e5f9..2790d2113f 100644
Binary files a/src/wp-includes/images/xit.gif and b/src/wp-includes/images/xit.gif differ

Possible solution

Investigate alternative image minification settings or npm packages that avoid this issue.

Steps to reproduce (for bugs)

1. You will probably need a MacOS or Windows machine for testing
2. Checkout the code and run npm install
3. Run grunt precommit:image
4. Run git status or git diff to see if changes are reported

Context

When working on ClassicPress and using the precommit steps, I have to discard changes to the images before making a commi and push.

Required extensions for ClassicPress v2 support

Alternative to #397. ClassicPress version 2 will require the cURL HTTP transport and deprecate/remove support for the streams transport. Installing ClassicPress v2 (whether a fresh install or an upgrade from 1.x) should be blocked if cURL support is not present.

Remove microformats from the core

Context

There is a petition to upgrade microformats to v2 in the core. Instead of continuing to support microformats, which rely on CSS classes, they should be completely removed from the core as bloat. There are several reasons for this:

• This is plugin and theme territory and is usually handled by either an SEO plugin, a dedicated schema plugin, and theme developers implement their own markup.
• Google prefers JSON-LD:

  • The markup is not interleaved with the user-visible text, which makes nested data items easier to express, such as the Country of a PostalAddress of a MusicVenue of an Event . Also, Google can read JSON-LD data when it is dynamically injected into the page's contents, such as by JavaScript code or embedded widgets in your content management system.

• Fewer things to support. What if microformats v3 comes out? Do we upgrade again? Google still supports microformats, but it is slowly removing support for older formats. Recently, they stopped supporting data-vocabulary*org. At some point, they will stop supporting microformats v1. This means we either need to upgrade it or, better, remove it and let plugins/theme handle it.

If removal is not an option, we should consider upgrading microformats to v2.

Possible implementation

Removal of microformats support from the core. There are a couple of options:

1. Introduce a filter to disable microformats in a minor version.
2. At some point, introduce a filter to enable microformats support (or core plugin) in a major version.
3. If we're not worried about backward compatibility, it can be removed in a major version without filters. A core plugin would probably be a good idea just in case anyone needs it.

Will you be able to help with the implementation?

Will help with testing.

Original petition

Redesign the 'user' dropdown in admin bar

Glad we got rid of 'Howdy' but now I suggest changing this area to something more useful.

Expected behavior

Fast link to My Profile information.

Current behavior

Currently my user name is posted in this area twice.
Listed as 3 links to 'My profile'.

Possible solution

As the top level is a rollover (to reveal) change wording to 'My Profile'.
On rollover reveal these anchored links:

• Change avatar (if possible)
• Change password
• Log out

So, you can directly go to either 3 (most used) sections.

Steps to reproduce (for bugs)

1. Open Admin
2. Cursor top right, rollover username

Context

This area seems like an after thought - either remove completely or make more useful.
Zen the eff out of it!

Add the ability to blacklist certain meta keys from the metadata cache

To improve read performance on metadata, get_metadata() pulls all metakeys into a cache that is stored in memory, then on subsequent calls, pulls from that cache array.

In simple cases, this functionality is beneficial to performance, however, meta values are stored as MySQL LONGTEXT, with a maximum size of 4GB. In rare situations, the meta table may be used to store large amounts of data, that needs to only be accessed infrequently, or a large quantity of smaller metafields.

Especially when taking into account that featured image is stored as post_meta, meaning that every archive page caches all meta values for several posts, there exist situations where this metacache can lead to slow data retrieval and possibly memory exhaustion.

In a perfect world, I would recommend two filters on the metacache functionality, that would implement a whitelist and a blacklist of fields to cache. These filters would be run in realtime, so that users could choose to whitelist or blacklist different fields, based on the context. (This last part might require storing a context string in the cache key, to prevent issues with persistent caches like redis).

Original petition

Modify the folder structure used to upload media files into years

Context
ClassicPress by default sorts media uploads into year and month subfolders. This is a remnant of the days when WP was primarily a blog and new posts were being made weekly or monthly. Month folders are also created automatically which results in a lot of empty folders.

For many users, the first thing they do on a new site is to uncheck this and put all media files into one big folder. However, this can become unwieldy and cause issues with ftp when files start to number many thousands.

I think a good compromise is to keep the option but make it years only.

Possible implementation
I have started to implement this on my sites using a few lines of code in my utility plugin. I’ve just been testing it and it seems to work fine. There is no issue with older media that is still there in the previously created month/date folders.

add_filter( 'option_uploads_use_yearmonth_folders', '__return_false', 100 );
$year = date( 'Y' );
define( 'UPLOADS', 'wp-content/uploads/' . $year );

It would probably also make sense to modify the date selector dropdown box in the media library. I’m not sure how this works or how hard it would be, but I imagine it picking up both the previous year/month folders (if they exist) and all the images in the year folder, eg

Or if it’s easier, just pick up the years (ie include all images in the year and its subfolders).

Will you be able to help with the implementation?
I can’t help with coding, but I can test it out.

Original petition

Update uses of WP version string

Let's look through each use of $wp_version and get_bloginfo( 'version' ) (are there any others?) and decide whether it should refer to the WordPress version (minimum version checks, compatibility checks, etc) or the ClassicPress version (core update checks, version displays, etc).

Follow-up to:

• #32
• #34 (comment)

Shortcodes containing asterisks may create invalid regex breaking the editor

Despite not being a reserved character an asterisk in a shortcode followed by another character will generate invalid regex which breaks the editor.

This code reproduces the issue:

<?php
add_shortcode( '*stars*', function() {
	return '★★★';
} );

Below is a gif showing the editor tabs not working correctly along with the error in the console in Chrome 65 and Firefox 59.

I know it's unconventional to use an asterisk in a shortcode, but my use case is porting a legacy CMS that used BBCode into WordPress while trying to keep as much of the original formatting possible for old content.

This is an issue with all plugins deactivated (except for the above code) using the Twenty Seventeen theme.

This was originally reported on the WordPress trac.

Expected behaviour

Editor should allow shortcodes containing an asterisk

Current behaviour

Invalid javascript is generated which breaks the editor

Possible solution

https://core.trac.wordpress.org/attachment/ticket/43686/43686.diff

Core Plugin: Comments

Move comments to a core plugin (original petition).

Core Plugin: Emojis

Move emojis to a core plugin (Original petition)

Fix custom post status bug (#12706)

WordPress has some bugs associated with custom post statuses. It’s been in trac for over 10 years.
https://core.trac.wordpress.org/ticket/12706 1

With CP’s business focus, it can be a viable CMS for publishers. Publishers have different workflows for publishing articles/stories. EditFlow plugin introduced a feature to customize post statuses to give publishers a way to move posts through their workflows.

It would be a great differentiator for CP to fix annoying bugs that WP doesn’t consider important.

Original petition

Improve logic for theme stylesheet cache buster

Whenever I write a plugin or theme that enqueues JavaScript or CSS, I always add a custom version to it so that I can bump the version and clear browser caches when the assets change. For example:

https://github.com/ClassicPress/ClassicPress-Themes/blob/05ef142f6a677974e4ca4413df6aa0d88edaa93c/classicpress-susty-child/functions.php#L3-L26

The default style.css file for a theme is a different story. Since the core software enqueues this file for me, I have to jump through some hoops to use my custom asset version there:

https://github.com/ClassicPress/ClassicPress-Themes/blob/05ef142f6a677974e4ca4413df6aa0d88edaa93c/classicpress-susty-child/functions.php#L52-L68

Filed under: Things that Really Grind My Gears ™️

At the very least there should be a filter to override this version. Ideally:

1. The theme's core stylesheet should use the version number from the theme's style.css
2. This should also be the default behavior for any other assets enqueued by a theme or plugin

I'm not sure if this would break anything, and (2) might prove difficult.

Core Plugin: REST API

Move REST API to a core plugin (discussion).

Hash passwords with bcrypt instead of md5

WP uses md5 with key stretching to hash passwords. This is moderately secure, but using bcrypt instead would be significantly more secure. (Argon2 might be even better, but I have no experience with it, whereas I have been using bcrypt for a couple of years, so I know it works fine.)

WP hasn’t done this because it supports PHP versions lower than 5.5. Since we have already agreed to drop support for versions of PHP below 5.6, we should be in a position to implement this. See PHP: password_hash - Manual

Original petition

There was an old PR for this #83 by @KTS915 that was closed.

Add UUIDs/GUIDs as candidate keys for all tables

In working with some more complex WordPress sites that need to interact with other systems and synchronize data it’s becoming clear that the lack of a properly maintained UUID/GUID makes that really, really hard. See:
https://stackoverflow.com/questions/45399/advantages-and-disadvantages-of-guid-uuid-database-keys/45479#45479
I am talking a candidate key here, not UUIDs/GUIDs as primary keys.

Original petition

"Update now" link for theme is broken when JS disabled

With JS disabled, you can click these links and nothing appears to happen.

The same bug should apply to WordPress, since we haven't changed this code.

Paste image from clipboard to upload

Would be very helpful if we could simply paste image into the media library uploader, and it would automatically upload it and set randomly generated file name.

Original petition

💡 ClassicPress version issues and conflict with plugins

Context

The version of ClassicPress doesn't match the latest version of WordPress nor doesn't sometimes match what mainstream plugins need for it to work.

Possible implemantion

Make a way for users to manually change the version so that they can use and test mainstream plugins that require a certain version in order to use them.

Possible Solution

I have been manually changing the plugin's version to allow to use with the current version of ClassicPress. And to my surprise, a lot of them actually work! So my suggestion is to.., in addition to making a way to change the version of ClassicPress internally, at the same time, allow ClassicPress users to test of many plugins and to have a button that will report back to a CP repo that this plugin works.

Will you be able to help with the implementation?

I can actually build a options page to change global data, db data, etc, as well as a way to REST post data to a remote location to show which plugins work.. I would just need to know what ALL places to affect, change, when it comes to the version of ClassicPress. Like, where are all the area/locations that the version number is being stored.

Missing Information: Working with JS and CSS files.

We need to add Instructions to the contributions.md file to help with JS and CSS file contributions.
Right now we might not be using modern tools like SASS/SCSS but we need to document this for the future:

• how we use NPM and its dependencies.
• Is this locally used?
• When do we use npm install locally?

Replace API endpoint for core checksum

Expected behavior

Use CP endpoint to verify the checksum

Current behavior

On https://github.com/ClassicPress/ClassicPress/blob/develop/src/wp-admin/includes/update.php#L101 it is using for the core the WP endpoint

This can create issues in the future.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Renovate[bot]: Update dependency rollup to v4.16.1

Detected dependencies

composer

composer.json

• php >=7.4
• dealerdirect/phpcodesniffer-composer-installer 1.0.0
• wp-coding-standards/wpcs 3.1.0
• phpcompatibility/phpcompatibility-wp 2.1.4
• yoast/phpunit-polyfills 2.0.1

src/composer.json

• johnpbloch/wordpress-core-installer 2.0.0

github-actions

.github/workflows/coding-standards.yml

• actions/checkout v4
• shivammathur/setup-php v2
• ramsey/composer-install v2
• actions/checkout v4
• actions/setup-node v4
• actions/cache v4
• shivammathur/setup-php v2
• ramsey/composer-install v2

.github/workflows/javascript-tests.yml

• styfle/cancel-workflow-action 0.12.1
• actions/checkout v4
• actions/setup-node v4
• actions/cache v4
• ubuntu 22.04

.github/workflows/php-compatibility.yml

• actions/checkout v4
• shivammathur/setup-php v2
• ramsey/composer-install v2

.github/workflows/phpunit-tests.yml

• styfle/cancel-workflow-action 0.12.1
• actions/checkout v4
• actions/setup-node v4
• actions/cache v4
• mirromutth/mysql-action v1.1
• shivammathur/setup-php v2
• niden/actions-memcached v7

.github/workflows/triage.yml

• actions/checkout v4
• actions-ecosystem/action-add-labels v1

.github/workflows/welcome-new-contributors.yml

• wow-actions/welcome v1

npm

package.json

• @wordpress/a11y 3.56.0
• @wordpress/api-fetch 6.53.0
• @wordpress/dom-ready 3.56.0
• @wordpress/hooks 3.56.0
• @wordpress/i18n 4.56.0
• @wordpress/url 3.57.0
• node-sass 9.0.0
• @lodder/grunt-postcss 3.1.1
• @rollup/plugin-commonjs 25.0.7
• autoprefixer 10.4.19
• clipboard ^2.0.11
• grunt 1.6.1
• grunt-banner 0.6.0
• grunt-contrib-clean 2.0.1
• grunt-contrib-concat 2.1.0
• grunt-contrib-connect 4.0.0
• grunt-contrib-copy 1.0.0
• grunt-contrib-cssmin 5.0.0
• grunt-contrib-imagemin 4.0.0
• grunt-contrib-jshint 3.2.0
• grunt-contrib-qunit 8.0.1
• grunt-eslint ^25.0.0
• grunt-includes 1.1.0
• grunt-jsdoc 2.4.1
• grunt-legacy-util 2.0.1
• grunt-replace 2.0.2
• grunt-rtlcss 2.0.2
• grunt-sass 3.1.0
• grunt-webpack 6.0.0
• ink-docstrap 1.3.2
• install-changed ^1.1.0
• lodash ^4.17.21
• moment ^2.29.4
• postcss 8.4.38
• qunit ^2.19.4
• rollup 4.16.0
• sinon ^17.0.0
• sinon-test ^3.1.5
• source-map-loader ^5.0.0
• sync-request 6.1.0
• terser 5.30.3
• terser-webpack-plugin ^5.3.7
• webpack 5.91.0

nvm

.nvmrc

• node 20.12.2

---

• Check this box to trigger a request for Renovate to run again on this repository

Error: undefined function `classicpress_version()` immediately after migration

@striebwj has reported an issue where migrating from WordPress to ClassicPress sometimes shows the following error at the end of the migration process:

This issue only seems to happen when running under Laravel Forge. It is almost certainly a broken caching layer of some kind, since wp-includes/version.php is guaranteed to be updated before the ClassicPress dashboard's About page is served.

Computers often do strange things that we don't have time to investigate and understand, but in this case we know that the error always disappears after a page refresh.

This suggests a hacky hack that would probably work around this issue: add a "refresh counter" variable to the ClassicPress About page. The logic would look something like this:

if ( ! function_exists( 'classicpress_version' ) ) {
    if ( empty( $_GET['refresh_counter'] ) || (int) $_GET['refresh_counter'] < 5 ) {
        $refresh_counter = empty( $_GET['refresh_counter'] )
            ? 1
            : (int) $_GET['refresh_counter'] + 1;
        // show a warning message with a link to `?refresh_counter=$refresh_counter`
        // optionally, redirect there if JavaScript is enabled
    } else {
        // it's really broken, show an error
    }
}

The issue has since been identified as the PHP opcache storing stale versions of files, and the approach I originally proposed wouldn't work. See forums links below and also https://core.trac.wordpress.org/ticket/36455.

Core Plugin: Customizer

Move Customizer to a core plugin (original petition).

Improve "Remember me" checkbox

This was brought up as a petition in the forums:

Below the login credentials there is this cryptic “remember me” that doesn’t mean anything at all.

Remember me for what, for how long and what for?
The correct syntax for such checkboxes is:

Remember me for XX days on this computer

I will experiment with improvements to this checkbox as part of the overall improvements to the login page I started last year (#796).

Publishing an empty post shows an incorrect "Post published" notice

Expected behavior

When trying to publish an empty post - not title, no content, no excerpt - it should show an error message, "You can't publish an empty post."

Current behavior

When you publish an empty post, it shows a "Post published" notice with a link to the new post. However, the post was not actually published and the link leads to a 404 error.

Possible solution

When an empty post is published, it should result in an error notice "You can't publish an empty post."

Steps to reproduce (for bugs)

1. Create an empty post, no title, no content, no excerpt.
2. Publish it. You will see "Post published" notice".

Context

There is a function that performs this check and prevents post from being published:
https://developer.wordpress.org/reference/hooks/wp_insert_post_empty_content/

Missing Instructions:: Run PHPCS locally before commit

In order to reduce the back and forth commits for fixing PHPCS, we need to add Instructions for running PHPCS locally before commit to contributions.md file

Possible solution

Manual PHPCS install.

• You could manually install phpcs
• download the WP coding standards too.
• And then configure the path for phpcs.

Using Composer

The simpler way is to

• install composer globally
• run composer install in the CP repository folder locally.
• run phpcs -n That show only errors.

Update dashboard links to link.classicpress.net

With the release of the security screen in 1.1.0 we started using the https://link.classicpress.net/ subdomain as the link target for any new links within the dashboard.

We need to update the majority of the existing links to use this scheme also.

I'm not sure whether we should use link.classicpress.net for links to the main forums like the support section, since they are not going to change any time soon. However, links to documentation, individual website articles, etc should definitely be updated so that we can do things like re-organize our documentation site without also requiring a link-updating effort across multiple releases of ClassicPress.

The code for link.classicpress.net is here: https://github.com/ClassicPress/subdomain-link .

Replace Petitions Dashboard widget API

Since we're moving feature requests to issues, we have frozen the current petitions API so we can change the dashboard widget without issues.

My proposed widget tries to get more attention to our GitHub issues. It will have three tabs:

• Recent requests - shows the latest ten requests.
• Accepted requests - shows requests that were accepted, which means it has a label such as "needs pr", "has pr", etc.
• Help Wanted - this will show issues with "help wanted" label, to try and get people engaged.

Once request has "wontfix" label, it will not show.

Here are 2 mock-ups for 2 tabs in a new widget for recent and accepted requests. Help wanted is basically the same as recent.

APIs

If I'm not mistaken, this is what we can use:

Open issues labeled with "type: feature request":
https://api.github.com/search/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%3A+feature+request%22+repo:classicpress/classicpress

Open issues labeled with "help wanted":
https://api.github.com/search/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22+repo:classicpress/classicpress

/features/ endpoint

We can't have CP websites requesting data from GitHub API directly. So we would need to set up a script that would parse GitHub API and serve it using /features/ API we currently have. This way, we have full control over it. Script can be triggered by cron daily or couple of times per day. Daily probably would be fine.

We need to try and get users more engaged without being annoying. This is the first step.

Update list of files to remove during migration from WP

We need to do #487 again, since WP has added more files in recent versions that are not present in ClassicPress.

Revision handling for drafts

Quick "backup" of the discussion on CP slack: https://classicpress.slack.com/archives/CCSJGU44F/p1543296496867600

Expectation of new users of WP: Drafts get revisions, too, ie. one can jump back to earlier versions of the current draft.
De-facto behaviour of WP: Drafts don't get revisions, and sometimes auto-save breaks them, or when accidently closing the tab one is doing the editing

So the suggested behaviour would be: Actual revisions for drafts - so one can go back to earlier drafts, eg. when accidently removing your content in the current draft (WP would save blank content, too), etc.

Based on this WP track issue: https://core.trac.wordpress.org/ticket/12515

Core Plugin: Post by Email

Move post by email to a core plugin (original petition).

Add editor shortcode-button hook

What annoys me, and certainly others, is the chaos in the post editor with the shortcodes. Each plugin sets an extra shortcode button. Wouldn’t it be possible, even sensible, to implement a hook in which ClassicPress plugins can hang in order to display their button in a central “shortcode buttons” menu?

Original petition

Update contribution docs with docblock expectations

We have a codebase with WordPress an ClassicPress code. In a few years ClassicPress will have @since 2.1.3 making it hard to differentiate the same version with WordPress. So the docblocks have always been prefixed with cp or wp to make it @since wp-2.3.0

This needs to be added to the contribution.md file

Add full changelog display to admin dashboard

The ClassicPress admin dashboard should show the same changelogs as our official release posts in the forums: https://forums.classicpress.net/c/announcements/release-notes

Right now these changelogs appear in 2 different places (on the forums and on GitHub). To avoid having 3 places, it might be nice to come up with a way to automatically pull the content from a single source (most likely GitHub).

Or, we could take the simplest route and just add a link from the admin dashboard to the releases subforum.