PHP 7.x (exact version TBD depending on usage, community, and our resources) for v2.0.0.
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.
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.)
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.
PHP 7.x (exact version TBD depending on usage, community, and our resources) for v2.0.0.
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.
Removes the extra code bloat used to add support for emoji’s in older browsers
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.
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).
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).
Automattic's war on SVG is madness in an era of high DPR displays. It's not difficult to fix with the Safe SVG plugin (or with code, if you prefer), however, I feel like the ability to upload SVGs should be a stock feature.
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?
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:
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..)
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.
Uncheck "Settings > Discussion > Show Avatars" setting by default for new installs. Keep functionality in code.
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.
There are plugins that handle this nicely, but I would prefer this to be a standard core product. And it shouldn't be difficult to implement.
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.
A differentiation between WP and CP is that CP is business-focused by being an application development platform, not just for blogging. Part of business operation would be to store personal information which may need encryption due to GDPR recommendations or actual enforcement by data privacy laws. This petition suggests to include 2 functions to encrypt and decrypt data ( i.e. wp_encrypt() and wp_decrypt() ) which can be added in the formatting.php file under wp-includes folder.
A sample encryption and decryption function can be accessed at Line 72 onwards at https://github.com/ray-ang/open-nis-patient-care-summary/blob/master/functions.php
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.
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
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.
These are not necessary and can pose a security risk.
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!
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:
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
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 :)
(it is a quick list, there is still a lot ! add yours...)
Yes, we have the Plugin repository, but we don't always need to use a plugin for menial tasks. What would be great is tapping into a script repository for simple installations of scripts to be used. WordPress already comes bundled with plenty, although I am talking more about those cool scripts you find on sites like CodePen, JSFiddle, and Codrops.
Imagine a plugin and script repository working side by side.
Changing this category to "General" would look more professional in those times when you forget to categorize something.
This is a petition to finish the Fields API and integrate it into ClassicPress core.
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.
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.
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
I would like to see the ability to automatically create an XML sitemap “on-the-fly” built into the CP core.
As with the ability to edit the page title and meta description (see https://petitions.classicpress.net/posts/175/allow-editing-of-page-title-and-meta-description-seo) , a well-structured and up to date XML sitemap is an essential part of SEO, helping Google (and others) to crawl your site.
This feature is only made possible at present through the installation of 3rd party plugins but in my view should be a core feature of any business-focused CMS.
If this feature were to be implemented, there could be global enable/disable setting and/or filter to be used as and when required (e.g. when installing a SEO plugin).
Borrowing the description;
In Chrome 76, you can use the loading attribute to completely defer the loading of offscreen images and iframes that can be reached by scrolling:
<img src="image.png" loading="lazy" alt="…" width="200" height="200">
<iframe src="https://example.com" loading="lazy"></iframe>
Here are the supported values for the loading attribute:
> auto: Default lazy-loading behavior of the browser, which is the same as not including the attribute. > lazy: Defer loading of the resource until it reaches a calculated distance from the viewport. > eager: Load the resource immediately, regardless of where it's located on the page.
Morten in https://core.trac.wordpress.org/ticket/44427 makes a good case for this. Can we work on this since it does not make any breaking changes? It is an enhancement that I see since I come from a location where we have bad bandwidth and network.
See lazy loading in effect here: https://web.dev/native-lazy-loading/lazyload.webm
A plugin I install on every ClassicPress/WordPress site is https://wordpress.org/plugins/duplicate-post/ (and it looks like 2 million other people also like this feature!).
Basically, it allows you to copy / duplicate a post of any type.
It would be great if we could add this basic functionality into ClassicPress
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.
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.
What might a more robust editing flow with support for collaboration and multiple roles look like as part of ClassicPress?
I think a really solid, seamless integration with Google Docs would be interesting to explore. Google Docs has the best real-time collaborative editing experience I've ever seen, anywhere. This is the result of many years of engineering effort.
There are a couple of existing (or previously existing) solutions:
https://www.wpsuperstars.net/publish-from-google-docs-to-wordpress/ (according to the reviews not supported anymore / not working for common situations, seems to potentially require a WordPress.com account / Jetpack site)
https://www.wordable.io/google-docs-to-wordpress/ (third-party service, requires an account with Wordable, appears to use XML-RPC on the site)
Such a solution could use Apps Script on the Google Docs side to send the document contents to the ClassicPress REST API and store info about the connection in document metadata, but this would require setup for each Google user account.
Another way this could work is with most of the work being done on the ClassicPress PHP side, with a button that prompts you to go through the Google OAuth flow and pick a document to synchronize with a post.
Either way, I think the ideal user experience for this feature would look something like this: the TinyMCE view of
post_content becomes read-only on the ClassicPress editing page, but stays connected to the underlying Google doc in the background. Then, people who write and edit stories would have their access managed using Google, and ideally only the person who publishes after everything is reviewed would need to mess with the ClassicPress dashboard.
There are definitely a lot of details to figure out here, such as how to map more complicated content types like embeds over to ClassicPress. This kind of setup would probably be most useful for text-heavy posts.
CP should set automatic ALT tags based on the file name for all images that do not have ALT tag saved in the database. This kills 2 birds with one stone:
Add option to expose REST-API only to authenticated users, maybe limited to a certain capability.
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.
Please note that I'm NOT suggesting dropping jQuery. The file will still reside in the product to allow plugin developer to use it if they wish.
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.
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.
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?
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.
The ability to edit the page title and meta description is a fundamental aspect of SEO. Both of these elements combined help with search engine ranking and click through rate. At present, it is only possible to edit these two key elements by installing a plugin.
However, as they are so important to SEO, I feel it would be of great benefit to all if the ability to edit the page title and meta description was made part of the CP core. In my view, this should be an essential feature of any business-focused CMS.
If this feature were to be implemented, the SEO page title could default to the ClassicPress page title + site title and the meta description to the first 155-160 characters of the page content or excerpt.
There could also be a setting and/or filter to globally disable this feature as and when required (e.g. if installing a SEO plugin).
a basic form builder, such as for contact forms, with challenge-response (no reliance on 3rd party APIs)
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
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.
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.
CP is a CMS. The reason why Posts are seen as default content type in the dashboard is because WP was initially created as a blogging platform. Content/Data should be defined by the user. Hence, I propose that there should be no default post type in the fresh install/dashboard, and that a simple UI for registering CPT's should be included. It can be called "Content", with a submenu of "Create Content Type". The reason for still registering as CPT is to adhere to WP ecosystem and database structure. I know... this can be achieved using plugins... But the being a CMS, there should be a way to distinguish one content from another at the core level.
Add functionality similar/same as existing plugin https://wordpress.org/plugins/simple-local-avatars/
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.
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.
Bitchute that is a new video hosting website, developed a new comments platform in order to get rid of Disqus that they used up until now.
They call it CommentFreely it is open source and it available on GitHub.
The Bitchute people are looking also for programmers to offer support forthe further development of this comment platform.
You can see how it looks like under the video as they have already launched this comment platform on their website.
According to what they say this comment platform is compatible with Disqus too - but not related- in order to migrate their use's comments that they already had on Disqus, into the Comment Freely.
And here is my idea.
Why not modfy and use this comment platform as default on Classic Press. I mean replace the default WP comments with the Comment Freely that is somewhat more advanced as it has edit button, upvote option, new old and popular comments etc.
As I said Bitchute people are looking for support and if CP team works on the same project for the CP platform that will be beneficial for both teams. CP team can modify it as default comment platform unique on CP ( and for sure better than the default WP comments) and perhaps improve it further and Bitchute team can benefit from the developing and promote CP on their video channel, that is now the stronger competitor of youtube with some millions of subscribers.
In order to sum the whole thing up. The concept is to take their code, modify it for use as default comments for CP, contriute to the further development and improvement for the platform and advertise CP on Bitchute. ( swap the coding support with advertisement and promotion).
WordPress has their own php coding standard for core. Although far from all code in core actually follows the standard.
I would love for ClassicPress to follow industry standard PSR-2.
The main question that everyone is asking when starting is : what the difference between posts and pages ?
in a professional website the posts are useless
The main features like the category, date, comments, must move to the pages
Just keep the pages with all the features
Hi all ! I love ClassicPress as it uses 4.9.x and based on Classic Editor and simple core functionality. I love the Community but the lack is WordPress App. There is many one using App for some uses. So, there should be App for more progression and it's continuous development should be taken place. Involve in growing Community and help build solid foundation upto Enterprise level Web Package. Support my petition of Making ClassicPress app like WP. Thanks ! 🤙
It's usually a recommended step to improve security, changing table prefix from wp_ to something random.
Bring back Post/Page/Media ID in Posts/Pages/Media list pages.
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
//Get home path
An easier/built-in way for users to change the login URL/admin path from the default would be nice. I think that if it was a built-in option, it might encourage more people to do it. Purely as an example:
options, not decisions
Hi, I like me suggest support for webP, Opera, Android, Chrome and Yandex (and browsers based in Chorme) support webP and the last beta version of Firefox support webP too.
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.
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.
...and rename wp-admin folder
(easy and basics security...)
There are many petitions about removing various features into 'Core Plugins'. And, that should be done with: Customizer, REST-API, XML-RPC, Comments, Links... This will make maintenance easier, and CP core lighter.
But, the main thing related to the Core Plugins would be an extra step during the CP installation - when everything is set up (database, language and admin account), a new screen will be presented to select core plugins to install.
Also, the Plugins menu should be expanded to show the Core Plugins page where the Core plugins can be installed and removed, and not to be mixed with other Plugins.
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.
Propose that the Advanced Editor (aka WYSIWYG Advanced) plugin be bundled with ClassicPress release (like Hello Dolly/Askismet are with WP - not actually integrated into core like Gutenberg was.)
Why? Since ClassicPress uses TinyMCE (Classic Editor), having Advanced TinyMCE features available makes a lot of sense... Many users don't know of the availability of Advanced Editor options, and this approach would both bring awareness of them and make them more readily accessible. The Advanced Editor is a battle-tested mature plugin inline with ClassicPress project goals, and so is a great candidate for bundling.
WYSIWYG Advanced: https://github.com/johnalarcon/wysiwyg-advanced
Discussion reference: https://forums.classicpress.net/t/should-wysiwig-advanced-be-bundles-with-core/1155/2
This would make a wider variety of icons available to be used on the admin pages.
To make theming more logical and extensible for CMS users, the following changes should be made to the template hierarchy:
blog.phptemplate should be introduced as the default page template for the blog archive (whether on the front-page or on a dedicated page). After
blog.phpthe template hierarchy would proceed as expected to
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.
A feature plugin implementing these changes currently exists at: https://gschoppe.com/wordpress/better-template-hierarchy/
Please move this to a plugin.
Business sites are very unlikely to post from e-mail.
People who do need this feature should of course still be able to access it, but for the vast majority it is an attack vector that we don't want / need and currently need to secure with more code.
Thanks for reading.
We have added the TinyMCE editor in Quick Edit plus a few nifty features for quickly creating multiple Posts and Pages. We are currently working on adding Post/Page Revisions and Featured Images in Quick Edit too. I believe in time, this can continually be extended.
I believe this development would be a great edition to add to ClassicPress core and I would be happy for you to freely use this code.
You can check out the developments at our website here: https://gutenberg-free.com
Keep up the great work there.
On April 1, 2019 and only active when wp-config has
define( 'gutenberg', true );
People are so used to the update notice with 1-click updating for themes and plugins if they get them from .org or a third party site which has that capability (not all do).
But one feature that would be great to have is the ability to utilize the theme/plugin installers to allow updating simply by re-installing a fresh downloaded zip for a theme or plugin. WP doesn't do that but Joomla does and it's so useful and efficient.
Slated for inclusion in 1.2.0: https://github.com/ClassicPress/ClassicPress/pull/594
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
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!
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).
As James Nylen said, we have few options when talking about general core-level improvements:
Personally i think this is correct but obviously limited. An option that i want to try is this:
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.
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.
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!
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!
There are a lot of nice cache plugins for WP (even I wrote one a long time ago), but there's still not one as core functionality.
Microcaching could save a lot of sites out there if they are hit with unexpected amount of traffic.
Plugin compatibility is one of the biggest concerns for people considering the switch. If there was an easily findable place where plugin support for CP could be documented and rated (eg, 1-works great; 2-minor issues; 3-breaks), it would make it easier to select plugins for CP sites.
From my point of experience permalinks proper setting should be set to:
and that should be at least at common settings or better as default. I can say - all of actual common settings in permalink settings are unusful dinosaurs.
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.
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 :
Incorporate something like the Tailor plugin which was just about perfect for page building. Would leap ClassicPress into the future in one step.
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.
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.
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:
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 .
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.
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.
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 . 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 , 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.
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.
 Distinct from authentication.
 Needing to use row-level permissions almost always means the schema is wrong.
Below the login credentials there is this cryptic "remember me" that doesn't mean anything at all.
The correct syntax for such checkboxes is:
Add an option in "Settings > General" with a meta box to put the site in maintenance mode and add a message that uses the site's theme.
All revisions to posts and pages are saved by default. This can lead to unnecessary bloat in the database over time. I suggest adding a simple number box on the Settings -> Writing page to allow users to set the number of revisions saved (with zero indicating no revisions are to be kept).
It would be very helpful to everyone if anti-spam feature was in the core and enabled by default.
There's a very effective, very simple anti-spam feature that works with comments and all other forms (registration, login, etc.) that requires no user input, that works with JS and a token.
There's a plugin we use with WP called WordPress Zero Spam that uses this method, and it does live up to it's name. Never had any spam issues on any sites.
It basically generates a random token and stores it in the database. It adds this token on the page using JS, and if token is present and matches database token form submission is validated. If JS token is not present or doesn't match database, it's marked as spam. Validation is performed in the backend.
A checkbox to disable it on Discussions page (or Security) would be helpful if for some reason someone wants spam.
Based on this method:
No Akismet, no captchas, no checkboxes. No external APIs. It's simple and it works.
Put a Jetpack-style like button for both posts and comments.
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.
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.
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.
capital_P_dangithad performance and correctness issues, but as far as I know these have been fixed.
Feel free to discuss below.
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.
Users should be able to rename files as needed inside Media Library easily.
WordPress 3.5 removes the setting fields to change the media upload path and url.
It can be enabled manually from here /wp-admin/options.php
NAME-upload_path AND upload_path_url
Settings > Media, we can set the upload path(FOLDER) to folder like images,data etc.
It will be super useful for all.
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.
Wordpress will soon put this into core. Described here: https://core.trac.wordpress.org/ticket/44458 and here: https://wptavern.com/wordpress-5-1-to-introduce-new-white-screen-protection-feature-beta-1-now-available-for-testing
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?
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.
Let Admin easy brand the whole thing without having to use snipets to hide elements or to modify login etc.
Not sure what your plans are for widgets, but something I've been fighting with WP for many years--something that is common sense--is to have the ability to disable a widget title and to also the option to show/hide widgets on select pages.
You have to install third party plugins to do this and the idea, especially to lessen the security risks, is to have these capabilities in the core. Plus, if you have to use plugins, you never know if they will be maintained, and if not, this creates a problem then. Best to keep these types of options in the core of your cms.
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.
could be a cryptic random string
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.
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 for V2.
I cannot tell that posts table is large − it's very fat...
Please optimize it:
As discussed in slack (about woocommerce tracking users sensible data) I would like to see removed unecessary data tracking from ClassicPress, such as:
I think we can just collect statistical data needed for serving updates/troubleshooting, in an anonymous way.
Also I would like to see the enforcing of rules limiting data plugins can collect.
Wordpress does not allow upload of swf file.
Why ClassicPress would not allow such a thing
we do not have to look for a third party for that.
someone wants to set banner etc.
Let's say I have a flash game site
In older versions of WP the checkbox for setting links to "open in a new tab" used to be included in the primary pop-up. It is now about three levels down in the process.
This petition is to have it moved back to the previous position, so it can be easily found and selected without all the additional mouse clicks.
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.
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.
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.