ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

This is a read-only archive of the previous ClassicPress petitions website.

This archive was made at the end of 2020 when Fider stopped offering a hosted version.

To post a new petition, go to the petitions category on our forums.

2
Official Project Channel on Discord

Is Slack still invite only? no idea how it works but even when I was able to get in there for another project I don't totally get the appeal of it over something like Discord.

I basically live on Discord now and take advantage of lots of support channels/servers.

I would love to see CP come to Discord. So this is my petition.

Thanks!

8
Show Post/Page ID

Bring back Post/Page/Media ID in Posts/Pages/Media list pages.

4
Multilingual support by default

Having a multilingual website is a must for my customers.

Plugins like WPML are damaging my customers' performance, let alone their security.

Did you know that WPML is a stand-alone CMS? I have found out about it last week(!), therefore any plugin that is an overkill on my website's performance has no place inside my platform.

7
better database maintenance

not sure about this since i'm not familiar with how DBs work, but garbage in the database as a result of removed plugins, options, etc. has always bothered me

i'm thinking like auto-cleanup, compacting and removing dead options

8
comment reply email notification

site-wide and per-post/page email notifications for all new comments, or only for replies to ones comment(s)

i'm aware of Suggestion for new comments platform and Remove the Commenting system from Core but this may still be applicable

11
SMTP integration settings as core plugin

Users should have an ability to use SMTP easily if they choose to. No reason to have multiple plugins for something basic.

PHPMailer already provides necessary API, which can be accessed using phpmailer_init hook.

16
Remove the Theme and Plugin Editors

These are not necessary and can pose a security risk.

Difficulty: Moderate
Request: Remove feature
7
Replace dashicons with material icons

This would make a wider variety of icons available to be used on the admin pages.

Difficulty: Moderate
Request: Modify feature
13
Finish the Custom Fields API

This is a petition to finish the Fields API and integrate it into ClassicPress core.

https://github.com/sc0ttkclark/wordpress-fields-api

In particular, see: https://github.com/sc0ttkclark/wordpress-fields-api#why-a-fields-api

This was a feature plugin that never made it into WordPress core. It would have been a great foundation to further build out CMS capabilities and probably many other things that we haven't even imagined yet.

But, the core developers don't need to imagine everything that people will do with our CMS, we just need to provide a solid base for people to build on.

I see this API as mainly an un-opinionated way for plugins like ACF, Toolset, etc to do their job, but much more easily, without having to re-invent almost every piece of the functionality they provide.

For developers, this would also allow us to easily register all custom post types, fields, etc in the theme or plugin code for a site. We would change the field definitions in our dev environment, test and deploy, and everything in production is already updated. We could build a simple UI to manage only the settings that really need to be changed, but this UI wouldn't let users break the custom content types like what happens on sites today.

For users, it's hard to tell how this would look. I think this would mostly be a back-end improvement, perhaps with some light UI controls, but most user-facing implementation would be up to plugins until clean standards emerge.

CP Research Plugin
Difficulty: Hard
Request: Add feature
9
DB structure: each CPT should have their own datatable

As we all now in case of CPTs WP stores all the custom fields in post_meta table, which works of course but is far from being ideal. To show render any custom data for the users WP needs to look through 2 tables or join them. Or if the admin adds later a new custom field to a CPT those land at the end of post_meta table making that whole table a complete mess of randomly mixed data. Even worse if one does not need a custom field in a CPT anymore, well then those data remain in post_meta as orphans.

IMHO instead of all the above each CPT should have its own table in the DB. Everything would be much better organized and more flexible that way (one could add or delete rows anytime to any CPT without leaving garbage in post_meta). Even queries would be faster. I do not see cons at the moment.

16
Redesign admin UI in a comprehensive way that addresses the needs of business site users

The current admin was intended primarily for bloggers and single site owners. An admin UI redesign that caters more to the needs of business site users would be a big step in serving CP's primary market.

Difficulty: Hard
Request: Modify feature
20
Pages before Posts and change of admin menu

Since ClassicPress has set itself in the market as the business-focused CMS, I think that the Admin Sidebar menu can receive a much needed overhaul.

For starters Pages should be placed higher up in the Dashboard than Posts.

Ideally the order would become:

  • Dashboard
  • Pages
  • CPTs
  • Posts (with Comments being a submenu - see here)
  • Media
  • Appearance
  • Plugins
  • Users
  • Tools
  • Settings
  • and ideally all Settings of Plugins come below here, so the Dashboard can no longer be hijacked anymore).
Difficulty: Moderate
Request: Modify feature
9
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 http://php.net/manual/en/function.password-hash.php

Request: Modify feature
7
auto delete wp-config-sample.php after install

...and rename wp-admin folder

(easy and basics security...)

Request: Modify feature
62
Improved Media Library

I suggest an improved media library, because this is a feature of WP which has been strongly neglected in the past. Whenever someone came up with a new proposal, most of it went under, unheard or was post-poned till somewhere in the far-off future.

At least having some option to display files and directories in a classic tree view would be great. Oh, and a slightly more welcoming Media API.

Both features would be very welcome. The former one should sooth newcomers, who are used to having a "regular" overview of their media, while the latter should rush forward plugin development.

Update (2018-12-18)

CP Research Plugin
Difficulty: Hard
Difficulty: Moderate
Request: Add feature
Request: Modify feature
5
Choose login url instead wp-admin

Will be great to be able to choose the login name instead of just the plain wp-admin. of course some plugin does, but why not implemented?

Difficulty: Moderate
Request: Add feature
Request: Modify feature
4
Branding and personalise from admin

Let Admin easy brand the whole thing without having to use snipets to hide elements or to modify login etc.

2
Rebuilt the admin menu

Use the frontend menu GUI to create admin menus.
... for each roles.

Don't show Tools menu if empty

Can be empty for certain roles, don't show it then.

Request: Add feature
1
Option to disable (gr)avatar in adminbar

If (gr)avatar is used, provide extra option to disable the (gr)avatar icon in adminbar, it currently allows external tracking of all admin navigation.

Difficulty: Easy
Request: Modify feature
15
Get rid of the "Cheatin' Huh?

For example you've left the browser window open on the WordPress dashboard and your session has expired and you click on a menu item you get redirected to page that says:

Cheatin’ uh?
Sorry, you are not allowed to list users.

This is not professional, nor useful.

It should instead give you a message that says something like:

"You need to login as an administrator to view this page."

With a login form below

Request: Modify feature
47
Add an Object-Relationship Table

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.

CP Research Plugin
Request: Add feature
6
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

Difficulty: Hard
Difficulty: Moderate
Request: Modify feature
12
Theme/Plugin Editors: disable by default

Following this discussion that asks for complete removal, it seems that most people would actually not want to see them removed at all, but instead they would like to see the editors disabled by default.

Difficulty: Moderate
Request: Modify feature
5
Remove the Commenting system from Core and implement as (optional) plugin

Not all sites need/want commenting. Implementing this as a plugin allows complete removal of commenting without having to add more code (such as the Disable Comments plugin).

If it's a plugin, it can be added back when needed.

16
Please add 'Enforce strong passwords' and 'Password Expiry' to the core.

These 2 features are often included in bigger plugins (Wordfence, iThemes Security, etc) but they should be core features so new users have to use them from the outset. Thanks!

Difficulty: Easy
Request: Add feature
7
Add Gutenberg support

On April 1, 2019 and only active when wp-config has
define( 'gutenberg', true );

1
Add REST API key for security

As it is, the existing REST API does not secure itself with a key to prevent unauthorized access, much like how it happened back in WP version 4.7.1.

We need to increase the security around it as a whole.

Request: Add feature
6
Use one configuration file per environment

Like Bedrock does.
A common configuration file using environment variables or using dotenv allowing to define db passwords and salts.

Special configuration files for each environment :

  • development
  • staging
  • production
Request: Add feature
9
Add local avatar functionality

Add functionality similar/same as existing plugin https://wordpress.org/plugins/simple-local-avatars/

Request: Add feature
6
Add SQLite and PostgreSQL support

Request: Add feature
18
Disable (gr)avatar by default.

Uncheck "Settings > Discussion > Show Avatars" setting by default for new installs. Keep functionality in code.

Difficulty: Moderate
Request: Modify feature
30
Remove Emojis (GDPR friendly)

Removes the extra code bloat used to add support for emoji’s in older browsers

Planned

Our roadmap for v2 is to move features into "core plugins" that can be disabled or deleted as needed: https://www.classicpress.net/roadmap/

Emoji support is a great candidate for this effort. We need to build a plugin directory first though.

Request: Modify feature
Request: Remove feature
40
Minimum PHP version should be 7.x

Planned

PHP 7.x (exact version TBD depending on usage, community, and our resources) for v2.0.0.

Request: Modify feature
16
Bring Comments into the Posts menu

Comments belong to Posts, just like Categories and Tags do. There already is a plugin for that, could be a good idea to integrate it.

Difficulty: Easy
Request: Add feature
Request: Modify feature
26
Remove XML-RPC specification

Difficulty: Moderate
Request: Remove feature
Enable STRICT_ALL_TABLES in MySQL

It was the fact that this isn't enabled in WP that led to the addition of emoji.

Request: Add feature
1
Follow minimum PHP version recommanded for security

Just stick to the security recommendation of http://php.net/supported-versions.php
to keep WordPress/ClassicPress secure and modern.
It's not break WP/CP after if PHP isn't upgrade but just stop update WP/CP until new PHP version installed.

Request: Modify feature
10
REST-API authentication option

Add option to expose REST-API only to authenticated users, maybe limited to a certain capability.

Difficulty: Easy
Request: Modify feature
Option for comment functionality in media

Provide an option to en/disable all comment functionality in media library = for post_type attachment, default: disabled.

Request: Add feature
2
Allow editor role to edit privacy policy

Currently by default only admin roles can edit privacy policy page.

Request: Modify feature
Option to show only "own media"

Add option to "Settings > Media" to switch on/off showing only "own" media for roles below editor (e.g. without edit_pages capability, or introduce new capability).

Request: Add feature
Add custom post type in dashboard_glance_items

Based on current_user_can( $post_type->cap->edit_posts )

Request: Add feature
1
Add custom post types to wp_dashboard_recent_posts

Based on current_user_can( $post_type->cap->edit_posts )

Request: Add feature
1
Add capability to allow editor role edit menus

Currently only possible with granting too broad "edit_theme_options" capability.

Request: Add feature
7
Remove Privacy Policy auto-injection

options, not decisions

Request: Add feature
4
Add API for additional required plugins

If a theme / plugin requires / depends on another plugin, show a note to allow/deny during install.

Maybe include a way to preset options/data for the additional plugin, e.g. if CF7 is required, auto-install it (if "allow" is selected) and provide/install custom premade contact-forms.

Planned

Planned for V2.

Request: Add feature
1
Add option to clear all theme options

A "reset to default" feature (with a strong worded "are you seerious" step) so a theme acts like it was fresh installed, limited to $wpdb->prefix . 'options'

Request: Add feature
2
Add option to inherit parent theme options

If a child theme is installed later, copying all options from parend to child can be pita. When acivating a child theme which has no options saved yet, ask if copy from parent.

Request: Add feature
4
Show notice if plugin update path does not exist any more

in local plugin/theme listing e.g. if plugin/theme is removed from repository or external update-source is not reachable. Maybe dismissable for 'a week, month, forever' or similar.

Request: Modify feature
4
Remove the auto-complete of the search string on the plugins page

Annoyingly when searching for a plugin the results filter as you type - normally this is a plus BUT the repo cannot find anything that's not 100% named forcing you to type the whole name, but, what if you don't know the name.

Get rid of this function for now and build something better asap.

Request: Remove feature
5
Change basic settings of comment options

First thing I always do when installing a fresh Wordpress is switching off the discussion options. It should defailt to "off" (non active) if you ask me. Because novice users don't do this, resulting in loads of spam to their sites as well as heavy traffic. If people want to use it, they are well capable of switching them on later on.

Difficulty: Easy
Request: Modify feature
13
Add some basic brute force protection please

I would like to see some basic protection against brute force attacks on the wp-login.php and xmlrpc.php. At the moment, you will need to add plugins and/or disable access to xmlrpc.php using plugins. I hope to see ClassicPress with a basic protection like a captcha on the login page.

Request: Add feature
4
change user slug - do not expose user name

could be a cryptic random string

Create a CSP manager in the core

To grant plugins and themes to add Content Security Policies for third part assets or call. WP will be able to on save of an posts/pages add the external domain to the CSP automatically.

10
Support for plugin dev/update on Github

CassicPress should start to avoid using the WordPress repos, develop its own repos and an alternative plugin and theme developmen platform by actively supporting native Github repos for each, and providing the interface people need to fnd what they want without having to scroll through years of outdated, irrelevant and totally pointless dead plugins and themes.

Difficulty: Moderate
Request: Add feature
Request: Modify feature
RFC / PEP mechanism for ClassicPress

We need to have something Request for Comments (RFC) or Python Enhancement Proposals (PEP) so we can demonstrate a clear case-study for each case we present.

23
At installation, leave a choice between adding default content or not

Put a radio button with the choice between installing default/dummy data (like sample page, post and maybe even plugins) or a clean empty installation (could be the default option).

Difficulty: Easy
Request: Modify feature
Time basis publishing

It's not very useful to be able to change the date of a page and not been able to hide (Send to draft?) at the same time the one not needed. Been able to do it in a scale schedule, one after the other could be also great.

Request: Modify feature
3
Choice of translation glossary

Give back to the authors the priority on the slack teams for the translations of their plugin.
In some local teams, a small self-proclaimed group decides for everyone, even if the author does not agree on a term, he can not oppose it without leaving the WordPress repository.

Difficulty: Moderate
Request: Modify feature
25
ACF in the Core (with an off-switch)

A lot of folks have been asking themselves why the outstanding Advanced Custom Fields plugin is still not baked into WP Core. Seeing the number of installs (1+ Mio) it certainly is not a wrong question to ask.

Out of backward compatiblity, and just easy of use, there should be an off-switch, at best supplied as a simple auto-load option (eg. 'acf_in_core' or 'acf_base_integration' or something like that). This would also ensure that future massive updates to the original ACF plugin may not collide with "our" core version, plus it'd still enable you to properly use ACF Pro ;)

I'd also suggest keeping the ACF infrastructure (field groups CPT / taxonomies etc.) the very same, so in the case of eg. ACF 6 or maybe even a custom version for ClassicPress, one indeed just uses the "off" switch (or the plugin installation hook checks for the enabled option and just disables it automatically during plugin activation).

Suggested version to integrate is 5, not 4. I release its not released yet, only available in a preview relese from the ACF site, but its better to have up-to-date structures in place, than slightly outdated ones. Also, most people who use the pro version are already on 5.x.

My guess is that the official release of the base ("free") version has been delayed thanks to a) the advend of Gutenborg and b) the overwhelmingly massive amount of reviews to be done by the Plugin Review Team (essentially it might just be stuck in the review pipeline).

Difficulty: Hard
Request: Add feature
4
Handling ajax other than via admin-ajax.php

There should be a way to handle ajax requests without the downsides of admin-ajax.php

I guess this file has not been intended to how it is used.

There should be a way to do effective ajax requests without loading all plugins, without require the wp-admin folder to stay in place (can also not just be protected by basic auth because of that dependency) etc.

Having a standadized way to handle ajax calls is a good thing and should be possible.

Request: Modify feature
15
Integrate Health Check & Troubleshooting plugin

It is an official plugin by the community started from a ticket https://wordpress.org/plugins/health-check/

I think that we can integrate to improve the debugging and also help the customers/users to understand the system data.

Request: Add feature
6
Add a real page builder

Incorporate something like the Tailor plugin which was just about perfect for page building. Would leap ClassicPress into the future in one step.

12
Remove dashboard color schemes

Since a recent poll shows that 70% of users do not use any of the additional color schemes for the dashboard, it would be a good cleanup to remove the lot and simply keep the default color scheme.

source: poll on recent WP Tavern article: https://wptavern.com/dark-mode-is-possibly-coming-to-a-wordpress-dashboard-near-you

Request: Modify feature
17
Better frontend search

For years and years (frontend) search has been a complete disaster. There are several plugins that have tried to improve the search functionality, some with better results than others, but should something as fundamental as search be done with a plugin? I think not.

Difficulty: Hard
Request: Modify feature
3
Menus method rethink

While I understand the thinking behind the 2-steps of firstly making a page, then secondly adding it to a menu, I have found my clients didn't expect 2 steps and using the 'Menus' area for them is very confusing.

How about a feature that upon making a new page, or editing an existing page, there is a menu palette in the right-hand-side of the classicpress admin interface, allowing choice of menu, with ability to assign the order of the current page in the menu.

Difficulty: Hard
Request: Modify feature
10
Core support for modern microformats v2

There's already core support for the older v1 microformats, but it would be nice to modernize to the v2, and in particular for the proper use of h-entry and h-feed. Adding these on top of/in addition to the prior hentry and hfeed shouldn't cause any conflicts.

See also: http://microformats.org/2014/03/05/getting-started-with-microformats2

Request: Modify feature
18
Core support for basic backups

It's stupid to have a nag about doing a DB backup before updating core and plugins and not having a simple tool to let the user make that DB backup and recover. A simple DB export (and possibly import) feature should be in core.

Request: Add feature
1
Styling in Editor

I suggest that the visual editor should pick up basic styling from the active theme by default. I know that theme designers can incorporate this, but most don't. It makes sense for the font, and for changes to blockquote styling etc could be automatically picked up by the visual editor.

Request: Modify feature
5
Configurable admin bar

Allow admin to configure the elements in the admin bar, user role based. Add new items eg. I would love to put 'plugins' into the +New dropdown, nest submenus into the admin dropdown menu, non-standard things like that.

Request: Modify feature
4
Default Support for HIBP

People have a terrible habit of using the same password over and over and often times have no clue the password they use isn’t safe anymore. It’s also a common oversight to add this by most creators. Add a Setting to enable/disable of course.

https://haveibeenpwned.com/API/v2

Request: Add feature
Add simple security measures to core

Here's my wishlist for standard core security measures.

  1. Integrate a simple math captcha (so we don't have to rely on Google)
  2. Integrate the ability to change the login page name from the default.
  3. Integrate the ability to block bad queries.
  4. Integrate the ability to send bad bots to some blackhole.

Thanks.

Request: Add feature
15
Better WYSIWYG editors

Gutenberg project is cool... but designed for final users.

Developpers need more fexibility according to projects requirments.

we should be able to choose editor we want for each project !

My proposal is to add and maintain the 3 best WYSIWYG editors to the ClassicPress core !

Let's vote for that :)

  1. https://www.tiny.cloud
  2. https://ckeditor.com/ckeditor-5
  3. https://www.froala.com/wysiwyg-editor
  4. https://imperavi.com/redactor/
  5. http://jejacks0n.github.io/mercury
  6. https://quilljs.com/
  7. https://summernote.org/
  8. http://getcontenttools.com/demo

(it is a quick list, there is still a lot ! add yours...)

Difficulty: Hard
Request: Modify feature
7
Cleaning up the <head>

Traditionally the <head> section is bloated with all kinds of things that should not be there, or at least not by default.

There is already an open issue to remove the Windows Live Writer (https://github.com/ClassicPress/ClassicPress/issues/69), but this feature request takes things further.

For example the output of the REST API link tag into page header should not be added by default in my opinion.

Of course there are many more individual links that bloat the <head> of ClassicPress, vote this request up if you agree to a clean up!

Request: Modify feature
1
Break large js files in small pieces when WP_DEBUG_SCRIPTS is enabled

Maybe we can break the huge js files in smaller pieces when the WP_DEBUG_SCRIPTS is enabled. It is hard to look into files like:

wp-admin/js/customize-controls.js
wp-includes/js/media-views.js

especially when the documentation is poor

Request: Modify feature
2
Add foreign keys in database

As most of the host set the default mysql engine to innodb I think that is a good idea to add foreign keys to the new classicpress installs

Request: Add feature
16
Add a GraphQL API

The current REST API is currently bloated with so much information one seldom needs when using the software as a headless CMS and could be improved in speed relatively. I suggest running with GraphQL.

This would improve speed of API, All developer to query only information needed.

This could be a start. https://github.com/wp-graphql/wp-graphql

Difficulty: Hard
Request: Modify feature
Page Templates for all kind of post types

This is a rather small change, mostly UI-wise, because most of it is already there, but would help a lot: Using Page Templates for any kind of Post Type, eg. posts or Custom Post Types :)

Difficulty: Moderate
Request: Add feature
11
Change all meta_key columns to VARCAR(191)

There is an issue with the meta_key field in all meta tables. This issue is that the fields in all meta tables (_postmeta, _usermeta, _commentmeta, _term_meta) are all set as VARCHAR(255). These should be VARCHAR(191)

The meta_key fields in all of these tables is indexed. However, the maximum length of the key is 191 characters. Actually the byte limit is 767 and in utf8mb4 that give us the 191 limit.

What this means is that when searching for a meta_key value the index may not be used used because the field can be longer than the index prefix. I'm going to be honest I don't know all of the technical details here. The only thing that I can say is that I have tested installations where I have altered these DB tables to set the meta_key fields to VARCAR(191) and this has resulted in slightly faster queries. Considering the number of queries made to these meta tables or when doing a "meta_query on posts, this increase in speed can be significant

This issue was address for the options table when the option name field was increased from 64 characters and it was discussed there why 191 was a better choice than 255. You can read that entire discussion there. You can read the entire discussion here if you'd like https://core.trac.wordpress.org/ticket/13310.

Difficulty: Moderate
Request: Modify feature
40
Include a page builder friendly theme in the installation package.

As I have had the opportunity to discuss this with another participant, I think it would be worth considering the inclusion of a basic theme and a theme built with multiple page builders in mind.

The idea stems from a free theme already available on WordPress.org Repository ( https://wordpress.org/themes/page-builder-framework/ ). While I understand there is resistance to builders due to the Gutenberg issue, page builders are a very active part of the WordPress ecosystem.

I personally think that including a theme that is built for use with multiple free and paid page builders would be a valuable asset in helping people begin building their site(s).

This doesn't involve making any changes to core. It isn't something that is automatically activated. It's just a useful tool I think would be nice to see included in the installation package.

10
Show Latest Plugins on Plugin Install Screen in ClassicPress backend

The current Plugin Install screen shows different tabs.

This idea, that was originally mentioned by @Rui on Slack, is to remove all tabs and change the current Popular tab with Latest Additions.

Instead of showing the same plugins with millions of downloads, this feature request is to show a more dynamic tab.

Request: Modify feature
3
Add a proper front end image upload mechanism

Include a mechanism where a front end user can add an image inline to their page/post/comment/topic/reply and it is uploaded to the media library upon submission.
I've not seen any plugin for WP that does this properly.

Request: Add feature
4
Add constants to support SSL connections for mysqli

As per this requested and pretty much ignored ticket https://core.trac.wordpress.org/ticket/28625 Allow SSL connection to mysqli - absolute madness this is not in core.

Difficulty: Moderate
Request: Add feature
3
Improve admin revision UI / handling

Always been a big PITA: The user interface for the revision system. Just a few hours ago I had another run-in with it, essentially wasting the revision I actually wanted to restore. Tried it a few times .. thanks to not being clear WHICH part we are currently trying to restore.

I'd like to see a few PROPER, well-done highlights and pointers to fix that issue.

Difficulty: Moderate
Request: Modify feature
4
Add Webmention Support

Webmention is a modern reimplementation of things like Pingbacks and Trackbacks. This proposal would be to remove the older standards in favor of the new.

The old standards were abandoned because of abuse and disinterest. But the vision is valuable.

Basic premise...Site A links to site B. Site A tells Site B they've linked to it and it is up to site B to decide what to do with it after verifying it.

That can be parsing the sending site to display a rich comment (Better than WordPress currently showing an unintelligible snippet) or even merely using it in a statistic display.

There is already a plugin to support webmention and a separate one that enhances the response.

7
Add Micropub support

Micropub is a W3C standard for publishing that is incredibly easy to implement. The advantage of having a platform agnostic posting API that supports simple form encoded or json encoded posts will instantly open up WordPress to many additional editors.

7
Add Indieauth as built in auth

Indieauth is a layer on top of Oauth2. It eliminates the need for client registration by making your client id your URL. This solves the issue WordPress had with this.

https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

22
Remove the Customizer / move it to a Core plugin

Businesses do not need the Customizer as they hire developers to customize on their behalf. Business owners simply want a functional website and they certainly don't have time to fuzz around in a sidebar with sliding elements.

This petition therefore aims to remove the thing altogether.

Possibly the Customizer Remove All Parts-plugin which hasn't been updated for more than 2 years can be used as a starter?

Difficulty: Hard
Request: Remove feature
6
Implement Custom Comment Types and Status

This is a gap in the current system. Comments are used for things other than pure comments. There is a type field, but not the sort of registration you get with posts, taxonomies, etc.

Comments don't have a staatus, they have Approved, which is overloaded as status now.

The steps to address were outlined a while ago. Comment type for comment, which is an empty string, needs to be moved to type "comment", which requires some migration.

Registration functions need to be built, and any place with hardcoded comment functionality needs to be switched to use the registration system.

Same with approved being used as a true status.

Difficulty: Moderate
Request: Modify feature
2
Consider a breakaway from WP

I wonder if creating a whole new cms using WP as a basis is the best way to go. Update the php core, phase out anything related to WP, but the big one is the editor. The best editor I have used in a cms is the JCE Editor (an extension for Joomla) which eats WP for breakfast, lunch, and dinner (with snacks in between). Perhaps make a deal with JCE. This editor also provides an amazing media management system that also kicks the butt of WP. As for widgets, give serious consideration to being able to hide widget titles, publish widgets to select pages, a field to add a class...these are things that should have been part of widgets without third party plugins.

Difficulty: Hard
Request: Add feature
Request: Modify feature
Request: Remove feature
6
Add PDO support

I personally want to have an SQLite as my default database, as I have a few friends' websites that have extremely low traffic. There's no need to have MySQL installed for such a small website that contains basic information.

No, SQLite can handle high volume of traffic as well and those who don't believe me, go check https://levels.io/remote-ok/

But that is not the point here.

We really need to have more alternatives to MySQL / MariaDB / Persona.

Thanks to PDO, we could have MS-Server, PostgreSQL, SQLite, Oracle...but we really need to support only the three most used: SQLite, MySQL, and PostgreSQL.

Request: Add feature
4
Update admin bar to show "Logged in as username"

Where the howdy text used to be, it now just shows the username. This messes with the symmetry of the area given the big tabs underneath (Screen Options / Help). I'd like to see that string a bit longer, such as "Logged in as username", with the username in bold.

Difficulty: Easy
Request: Modify feature
14
Change the name of the Uncategorized category

Changing this category to "General" would look more professional in those times when you forget to categorize something.

Difficulty: Moderate
Request: Modify feature
3
Dashboard > Settings > Reading ... text change

The word "homepage" ... I think there's a crack in the internet over whether this is one word or two, but it looks weird, especially when the first character is capitalized.

I'd change the label to read "Your front page displays"

...and then split and capitalize the other instance of homepage (from Homepage to Home Page) so that it looks consistent with the other option in that selector, which is "Posts Page".

Difficulty: Easy
Request: Modify feature
8
Change Posts to Articles or make them editable so they can be changed into anything

Articles use a more business-like tone than Posts, which belong to a Blog. A business site can have a News section where it publishes Articles.

Difficulty: Easy
Difficulty: Moderate
Request: Modify feature
9
Create an Admin Settings page w/icons grouped by category

WordPress's admin console is a rat's nest of complexity, especially when lots of plugins are added.

A while back I was reading https://deliciousbrains.com/craft-cms-self-hosted-wordpress-alternatives/ where they showed a screenshot of CraftCMS' settings page and I feel in love with it. I thought "Wouldn't it be great if WordPress' dashboard (or settings page) could be reconfigured to use categorized icons for core features and features added by plugins rather than the bloated wild-wild-west of the WordPress admin menus?

<img src="https://cdn.deliciousbrains.com/content/uploads/2017/07/04124856/craft-settings.png">

I could envision plugins that don't specify an icon or a category could get listed at the bottom or we could maintain a JSON file on GitHub with categorization for well-know plugins, and then also allow plugins to actively register their own icons and categories if they wanted to explicitly support ClassicPress.

Anyway, posting here hoping that others will get excited about the same.

Difficulty: Hard
Difficulty: Moderate
Request: Modify feature
9
Make ClassicPress a 12 Factor App...ish

WordPress has long followed an operational model that makes deploying, updating, and maintaining it automatically difficult.

While the formal Twelve-Factor App structure adheres a little too rigidly to the Heroku deployment model, it offers a number of advancements that would greatly aid operational concerns with ClassicPress.

For reference, I'm referring to this: https://12factor.net/

As an example, implementation of configuration in the environment - not on the filesystem - would improve flexibility and make operating ClassicPress in a Docker container more viable. An excellent library for this exists in the form of Vance Lucas's phpdotenv: https://github.com/vlucas/phpdotenv

Another part of the Twelve-Factor App model that would help in operations is logging. WordPress's logging model is just to rely on the reverse proxy serving it. ClassicPress would benefit from adopting Jordi Boggiano's monolog library (https://github.com/Seldaek/monolog), as it implements the PSR-3 standard and makes logging much more manageable from an operations standpoint.

Note: this petition has huge scope, and would be best served by being adopted as an overarching strategy, rather than an atomic change.

Change login header URL to site's homepage

The login header URL points to ClassicPress, which of course is very nice for ClassicPress, but I would like to think that anyone would expect to be taken (back) to the homepage of the site when clicking on it.
I always change it on any of the sites I build for clients, but I would like to petition this to be changed so the default becomes the homepage of the site.

Difficulty: Easy
Request: Modify feature
7
Hide/show admin notifications in according with the user will

Actual admin notifications are annoying and take place that should be taken by more important content. An action link could be added to the admin top bar to toggle the admin notices visibility.

Request: Modify feature
5
Remove capital_P_dangit content filter

I don't really have strong feelings about this one but I know that others do.

This petition is for removing the capital_P_dangit function that forces WordPress (now ClassicPress) to always be displayed with a capital P.

Like other removed features, I think we should make this (yes, even this) into a core plugin that people can disable if they want.

Pro capital_P_dangit

Many people unintentionally write Wordpress, but this looks unprofessional. Whether WordPress or ClassicPress, it's important to preserve the project's brand and present it consistently.

Anti capital_P_dangit

  • "Don't mess with my content"
  • Early versions of capital_P_dangit had performance and correctness issues, but as far as I know these have been fixed.

 
Anything else?

Feel free to discuss below.

Previously: https://github.com/ClassicPress/ClassicPress/issues/180

Difficulty: Easy
Request: Modify feature
Request: Remove feature
1
Do not create month- and year-based folders until some media is uploaded

WP creates a current month one even before you have a chance to decline this feature in settings.

4
Sell 'featured' plugin slots to sponsors

WP chooses to plug Automattic-owned ones, even when better ones exist.

This is a potential source of income for the CP project.

3
Have a compatibility with themes & plugins

I think to get a wider adoption CP needs to be compatible with existing plugins and themes.
Maybe somehow keep methods consistent and/or do regular partial merges with WP core.

3
Merge jQuery Manager for WordPress

Let users control which version of jQuery and/or jQuery Migrate they want to use (on the front-end). Also, let them turn on/off jQuery and/or jQuery Migrate.

I have made a plugin which does this, and only on the front-end, the backend and the customizer is not affected, see link: https://github.com/Remzi1993/wp-jquery-manager

This plugin is an open source project, everybody is welcome to contribute (code).

4
Tools That Can Be Used in Building

I mentioned this in a reply to another person's post. To bring it to the surface more, I am reposting and elaborating on my thought.

I always have and notice that I continue to prefer "The Drupal Way" of providing high-level tools (modules) that can be used to build extensible and scalable sites rather than being provided solutions in the form of plug-ins. That approach reduces the plethora of plugins that must be maintained in the WP environ, while enabling the building of anything one can imagine -- without WIXing it.

While devs find this approach attractive, the Drupal weakness has long been a ui that pushes non-techy clients of devs away from the table. Additionally, Drupal's update process can be simply annoying. Add to that, it's weakness in the ecommerce area.

Imagine bringing the great features of WordPress and the great features of Drupal together. The result would be innovative, a unique position in the CMS arena, and simply amazing.

Think about it? Consider it?

8
Define constants for easy development

No need to remember long paths or infinitely add ../../../

//Get theme dir
define('td', get_bloginfo('template_directory').'/' );
//Get home dir
define('hd', esc_url(home_url( '/' )));
//Get temes path
define('tp', get_template_directory('').'/');
//Get home path
define('hp', get_home_path());

Difficulty: Moderate
Request: Add feature
7
Overrides/Improvements, OOP, Scalability

PROLOGUE:

WordPress is fundamentally old because the "core" has been written years ago and everything inheriting the core must maintain the same "specs": No real use of Namespaces, no autoloading, tiny optimization and tons of "static" functions that you cannot override without action and filters (this is quite stressful for PHP).

OVERRIDES:

As James Nylen said, we have few options when talking about general core-level improvements:

  • Replace the old APIs with new ones. This will break existing sites and plugins.
  • Add new APIs on top of the old ones. This creates more ways to do the same thing, more complexity and bugs, and can be confusing. “

Personally i think this is correct but obviously limited. An option that i want to try is this:

  • Create new APIs that only wrap currently declared APIs but with the benefit to be extendable. So you can still do the same things with the same functions (that keeps compatibility) or you can use the new APIs that should allow you to do "more" or at least in a more semantic way.

This is something i've been thinking about since last year. I created a library called "wordpressify" (not even alpha - just an idea) where I'm scaffolding/experimenting this idea.

A tiny example on this:

Take the get_the_title() function.
Ideally we might have a WP\Posts\Post::title($post = 0) that returns exactly the same as get_the_title traditional function passing the same parameters. But (and that's what i'm doing in my library) it might be used even instanced as (new WP\Post(1))->title() where 1 is the post id.

In my library the Post class extends the abstract class PostObject that implements Meta interface and so on...

As Facades principles suggest it shouldn't be done this hard way. There should be some sort of function/parameters mapping in here.

Overrides will come in action once a proper implementation of the autoloading technology is done. PrestaShop Dispatcher class is an example here (not the best one in my opinion) but it might not be what it suits for WordPress.

OOP

Posts, Terms, Metas and any entity in WordPress should be objectified or at least recognized as Object and may eventually be part of an MVC model.

More Objectification in WordPress will be part of the previous section (refer to Improvements).

I don't want to go deeper into this because it might be too theoretical. Just take a look at https://laravel.com/ as example of how things (in my opinion) should be done.

SCALABILITY

Code, Push, Test, Deploy.
On a business routine you might want environments where you can test features before a production deploy. You may want an easy team process when working locally (eg. the db syncs: we still need to make search replaces on the entire db). This is just a tiny part when talking about DevOps because the scalability part of this is mainly managed by cache. Cache, cache and more cache!

CONCLUSIONS

So what is the solution to all this?

I truly think that the key is on creating a framework that "only" extends what WordPress does. Exactly like Laravel does with PHP.

Laravel does not invent anything on php - it "just" allows you to make it easier, faster and (in general terms) better.

TL;DR; A Laravel-like framework but it is still WordPress... with steroids!

20
Translatable content & localization at first installation.

Translations is something blogger may not be interested to - indeed when talking about business you want translations to be easy.

When installing WordPress you're asked for languages but this is just for the interface. Location shouldn't be "optional". It is something any CMS today consider at it first (eg ps, drupal etc..)

NOTES:

Translated content shouldn't be a duplicate post (as done by wpml). This is stressful for database that will force to search related ids by language.

For example the "post_content" column should be in a pivot table that contains the language id. When doing "get_the_content" it will take the content per language and so on.

CP Research Plugin
Difficulty: Hard
Request: Add feature
Revisions handling for drafts

following a discussion about a bug affecting draft visibility in the dashboard held in slack channel #community, and subsequent GitHub issue 250 (https://github.com/ClassicPress/ClassicPress/issues/250), I propose the development of a better way to handle drafts revisions.
In WP, drafts were a minor part of publishing experience back in the days when blogging started to be a mass phenomenon, it was useless having drafts stored in the dashboard for long. Now writers desire more control over what they write and posts are stored as drafts while crafting them, sometimes for months. This petition is aimed to allow people relying on drafts without data loss in an organized way, and hopefully solving also the bug originating the discussion in the process.

4
Add featured +- attached images to post endpoint in REST API

When one pulls up the endpoint "wp-json/wp/v2/posts" we get a key called "featured_media" but it returns an integer value.

Can't we rewrite this to give a proper URL to the featured image? or even add another key that has attached images as URLs.

This will prevent the extra queries one has to return the image URLs or even install bloated plugins to get this information.

I know the endpoint already has so much information one rarely needs thus the growth of tech like GraphQL but we could also consider Author name & description to the individual posts.

This is voice is for decoupling ClassicPress to modern apps or front-ends.

Difficulty: Hard
Request: Add feature
6
Defence in Depth: Separate database operations by access level

<h3>Background</h3>

ClassicPress has inherited from WordPress a codebase entirely devoid of even the concept of “defence in depth”.

The purpose of this petition is two-fold:

  1. Gain wider acknowledgment and acceptance of the need for defence in depth,
  2. Agree on a concrete first step in the process of providing defence in depth.

Creating full defence in depth properly is going to be a long, slow process, but I believe there are very worthwhile quick wins available.

There are many facets of defence in depth; I shall confine this petition to authorisation [1].

<h3>Why?</h3>

Over the years there have been many bugs in WordPress that have allowed some variation on “an unauthorised user being allowed to access something they shouldn’t”. The most recent is the REST API bug in 4.7.0/1 which allowed an unauthenticated user to insert/update/delete any post. This proposal would have completely prevented the bug from becoming a security issue.

<h3>The Problem</h3>

The fundamental issue is that CP has a single database connection which, by default, can do anything; if the authorisation checks in the code fail for any reason there is no way to catch it before the damage is done.

<h3>The Solution</h3>

The only solution is some form of separation of concerns.

The ideal separation is to have multiple database connections, each with a different level of access; ideal from a security perspective, but impractical.

Instead, I propose the addition of a number of database roles to the existing user, with the default role having only read access.

Roles, in one form or another, are common to all databases (with the exception of sqlite). Their exact functionality differs, but generally MySQL is the least capable; whatever works for MySQL is almost guaranteed to be possible on any other database we might consider supporting.

Each role would have a different level of access, but how the roles are structured requires further discussion. For example, we could mirror the CP user roles - which is probably too coarse, or we could mirror the low-level user rights - which is probably too fine and definitely too hard to implement in the first version [2]. We need a compromise and that requires discussion.

Due to the rather “basic” nature of the existing database schema the effectiveness of this approach is slightly blunted; for example, having all the posts and CPTs in a single table makes it difficult to restrict access by type [2], and unpicking this is not something to be undertaken lightly. However, it would still have stopped the REST API bug from becoming a security issue, and would generally prevent SQL injection attacks.

<h3>Future Implications</h3>

It is vital that any future developments take the security implications of the database schema into account, rather than just simplicity or conformity. For example, the “object relationship” research plugin must use individual tables for relationships so that there is enough granularity for database roles to be effective.

Ultimately, as part of implementing PDO support (which I am very much in favour of and hope we agree to do), we should look at implementing table-per-post-type, amongst other things. However, given the potential for breakage I cannot see how we could attempt that before v3.


[1] Distinct from authentication.
[2] Needing to use row-level permissions almost always means the schema is wrong.

CP Research Plugin
7
Update template hierarchy with blog.php, front-page.php templates, and custom URL routes

To make theming more logical and extensible for CMS users, the following changes should be made to the template hierarchy:

  • a blog.php template should be introduced as the default page template for the blog archive (whether on the front-page or on a dedicated page). After blog.php the template hierarchy would proceed as expected to front-page.php and home.php
  • If a custom page template is selected by a user, it should override all other templates, including blog.php, front-page.php and home.php. As the hierarchy is currently, you cannot offer homepage page templates in a child theme, if the parent theme includes a front-page.php. This removes choice from the user for no apparent reason.
  • TENTATIVE: Custom Permalink routing and embedding non-wordpress PHP functionality could be vastly simplified by offering a new file header comment that defines templates that should run at specific custom paths.

A feature plugin implementing these changes currently exists at: https://gschoppe.com/wordpress/better-template-hierarchy/

Request: Modify feature
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).

Request: Add feature
Add a flag to enable/disable maybe_serialize() functionality on metadata

Since meta_queries don't take maybe_serialize() into account, and since serialized strings are doubly serialized, there is a situation where a value can be stored in post meta that cannot be retrieved. Adding an optional $strict flag to metadata functions that casts all values as strings, without conversion, would solve this issue.

9
Add a templating engine like Twig

In the current state templating is plain spaghetti code. PHP interwoven with HTML. Readability is difficult at best. With a solution like Twig things would get dramatically improved. For WordPress already exists a plugin: https://github.com/timber/timber . With its help you get a separation of concerns. You have PHP files responsible for the logic and control and twig files for the presentation. Way easier to read any maintain, improved security through Twig by default, way easier loop construction and in case you ever need to work with time and unix timestamps in WordPress the Twig functionality is nothing but bliss. And the best it is backward compatible. Themes could run built in the old fashioned way without using Twig functionality at all, you could update certain templates adapting to Twig or migrate or write themes from the ground up for Twig.

CP Research Plugin
Difficulty: Hard
Request: Add feature
View more posts