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!

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

Don't know if this has been requested, but the ability to organize info into columns. One of the issues I had with classic wordpress was that organizing information on posts and pages into columns was impossible without a plugin, raw code or a theme. I need the ability to organize my info into columns because my sites contain too much info that needs to be organized. I'm not a php developer, and having to manually type in div classes is a time wasting pain in the #%/.

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.

Put a Jetpack-style like button for both posts and comments.

very simple, privacy-respecting visitor page view stats

see: Statify
and...
Statify – Extended Evaluation

simple drag-and-drop page ordering @ /wp-admin/edit.php?post_type=page

example: Simple Page Ordering

i have only 4-leter words to describe the arcane (ok, 6 letters) current 'order by number' method that WP invented - why???

a basic form builder, such as for contact forms, with challenge-response (no reliance on 3rd party APIs)

functionality like Broken Link Checker, but perhaps simplified to only display broken links with a link to the affected post/page

hopefully could be developed with an API so it could be extended to be much more powerful via a plugin

i'm aware of Access database in dashboard but i think this is a little different in that it could be useful to a wider audience with far less risk

the idea here is to be able to search-replace post/page content in the db

perhaps one has a habit of misspelling stuff (a lot vs. alot vs. allot) and wants to do replacements site-wide

an advanced option could enable RegEx support

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

new content email notifications where people can subscribe to be notified of new content globally, per-topic or per-page/post (when a page/post is updated)

this could be managed in the form of a checkbox added to the publish widget on the post editor where, if checked, subscribers will be notified of new/updated content

would also need ability to manage subscribers (manually add, remove, export)

same as Category Tag Pages

i'm guessing this could be valuable to many users while costing very little in code

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

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.
https://gitlab.com/BitChute/commentfreely

The Bitchute people are looking also for programmers to offer support forthe further development of this comment platform.

https://www.bitchute.com/video/duVjDBLU9iq5/

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

make a new ui for ClassicPress
make it not so WordPress looking

Filtering spam by just words and phrases is difficult and can easily lead to false positives.

Additionally, it would be helpful if the admin(s) had the choice between putting the recognized spam comments to trash or to the spam folder in order to check on them here and there so that legitimate comments that matched the blacklist rules can still be brought back.

Right now the WordPress plugin readme header can have these elements (among others):

Requires at least: 4.9.5
Tested up to: 5.4

(the numbers shown are just examples)

These are used by the WordPress API when it returns plugin lists on the plugin-install.php admin page, to advise admins whether plugins are likely to work with their installation.

As I understand it, the unofficial but useful Code Potent Update Manager plugin specifies that the 'Requires at least' number should be the required ClassicPress version, but that the 'Tested up to' number should follow WordPress versioning (for example 4.9.99). I'm sure there's a good reason for this.

However, before the official ClassicPress plugin directory is built, I'd like to suggest that CP and WP versions are kept separate in the readme header, so that plugin authors who want to support both platforms can do so with one zip file.

For example, this is how it could work:

Requires at least: 4.9
Tested up to: 5.4
CP core min: 1.1.0
CP core max: 1.2

The first 2 lines above would be read and used by WordPress installations, but ignored by ClassicPress. The last 2 lines would be ignored by WordPress but used by ClassicPress.

Note that the last 2 lines are named very differently (while their purpose is still obvious) to avoid any possibility of the WordPress API using them.

And to maintain consistency with WordPress, if the CP core max value contains an "X.X" version number, it would be interpreted to mean "X.X.Anything".

Explained here: https://core.trac.wordpress.org/ticket/46382

As the original poster says, the lack of an empty() check causes a lot of PHP notices.

Security First Approach Needs to Change wp-admin wp-login and directories can be configurable. So no one can know you are using wordpress. Of course you will want to know people use your classicpress instead of wordpress but for security you must cjange those things.

I think if WordPress admins were allowed to require new users to confirm their email address before they can start using the site would help to mitigate comment spam.

Hello, I am a Chinese user, I am from shenzhen, China.
I am willing to work for the promotion of ClassicPress in China.You can communicate further if you like.
I hope to add more features and improvements (some of which are still not responding to my countless requests to wordpress).

1. Hope to increase the support of Chinese, more perfect support.It is well known that many of Google's resources are inaccessible in China.Want to optimize access speed, such as excluding Google fonts,
2. In addition, I feel the need to add a core function.CDN replacement, for example, on the site I use a lot of a lot of inbound js, CSS hopes to add a plug-in, such as scanning on the website of the js. CSS resource, then we can replace the CDN resource specific links manually, such as on the site I use (original js: https://xxxxxxx.js), but I think (CDN resources: https://xxxxxxx.js) to access speed faster, hopes to increase the manual to replace the function of these resources.
3. Hope to get rid of the gravatar avatars as soon as possible. I don't know why wordprees still has the annoying avatars.You must also install plug-ins to change the avatar.Want to replace directly with the user's own upload

General Settings:

Is it crazy, after 5000+ years of the week starting on Sunday, to have the default setting Monday?

I find it mildly irritating to have to remember to fix that setting. It almost seems like some odd developer had an agenda?

In a Trac ticket at https://core.trac.wordpress.org/ticket/14777, Mike Schinkel successfully argued for the addition of a fields parameter to be added to get_posts. Currently, however, it supports only ids or id=>parent. I propose that it should also support the title field.

Add the option for a wiki.

An admin option (specially for developers) access the database in the dashboard similar like the WP adminer plugin.

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

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

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

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

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

I often have situations where I need to prevent access to a specific user account, sometimes temporarily, sometimes permanently.

More often than not, this is for security reasons.

For accounts that need to be permanently disabled, it would be easy to say "just delete them" but there's often a lot of content associated with that account that would need transferring to other accounts. This may not be appropriate for many reasons.

My way around this at present is to change the password but a much more effective method IMHO would be to have a simple enabled/disabled checkbox.

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.

https://wordpress.org/plugins/zero-spam/

Based on this method:
http://davidwalsh.name/wordpress-comment-spam

No Akismet, no captchas, no checkboxes. No external APIs. It's simple and it works.

Avatar Privacy is a Wordpress plugin:

https://github.com/mundschenk-at/avatar-privacy/
https://code.mundschenk.at/avatar-privacy/

It is released under GPLv2 so there is no reason why it can't be copied into ClassicPress core. It solves two privacy issues (1.) enables opt-in for using Gravatars when commenting and (2.) it caches the Gravatar images locally preventing visitor information from being shared with Automattic, with default images also stored and served locally.

Settings could include things like:
-enable/disable wpautop
-enable/disable theme and plugin editing (role-based?)
-enable/disable autoupdate for core updates
-etc
Could be grouped under various tabs, like 'Content', 'Security', etc

I recently discovered that when maintenance mode has been activated, there is no way to deactivate it, even by an authenticated administrator.
This is because the maintenance mode check is initiated in wp-settings.php, which is loaded directly by wp-config.php (so it applies to ALL requests, including admin, ajax and cron).
It would be useful to have a way for administrators to cancel maintenance mode without having to SFTP in to the site and remove the .maintenance file.
This would save a lot of time for those of use who manage many sites, especially from a central control panel like MainWP. If a MainWP plugin update times out for some reason, we have no option but to remove the .maintenance file before MainWP can reconnect to the site.

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

I think it would be cool to have OAuth server functionality built-in by default. I currently run a multi-site network and am working on having it so that people can login to a new Phabricator instance using their account on the ClassicPress multi-site network.

The problem: While I've been able to get the job done, many other features that would be useful are usually put behind a paywall, like with WP-OAuth. Additionally, I've been struggling to figure out a way to grab user's avatars from the network so that it can be their profile picture for the Phabricator instance as well.

So if there was an OAuth Server core plugin built into ClassicPress by default, I think it would be really great, especially for developers who want to do this kind of stuff like I do.

Email can be complicated, with lots of potential issues related to configuration, deliverability, etc.

To help with auditing emails that a site sends, including debugging and fixing any issues, we need a good email logging system. I think this is valuable enough for our target market to be included with ClassicPress, probably as a core plugin.

I'm imagining basically a custom post type with a lightly customized archive page, like a few meta fields about the email and whether it was sent successfully or not. This could also include an option to resend previous emails and an option to disable email sending entirely for local development, except for logging the emails that would have been sent.

https://wordpress.org/plugins/wp-mail-logging/ already does a lot of this.

Semi-related discussion and links to other related petitions here: https://github.com/ClassicPress/ClassicPress/issues/363

In particular https://petitions.classicpress.net/posts/163/smtp-integration-settings-as-core-plugin would be a fairly natural tie-in here. It would be great if the SMTP settings used to send each email would also be saved as part of the archive metadata.

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 ! 🤙

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

I'm going to propose that the core of ClassicPress be rewritten using vanilla Javascript.

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 benefits of moving to vanilla Javascript:

1. Massive runtime performance increase
2. Less http requests
3. No B/C break when updating jQuery

If this is done correctly, there will be no B/C breaks and all plugins that depend on any core Javascript will still work in exactly the same manner.

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

The default comment system uses the defined admin contact email for where to send moderation emails. For a single user blog that is fine, but for a company site one person or multiple persons may be dealing with comments. I have found no easy work around for that.

Please add options during initial setup (and / or on the settings screen) to provide the value for the "from" and "name" fields for WP mail.

Please make the default [email protected]

PSR-1 says

> A file SHOULD declare new symbols (classes, functions, constants, etc.) and cause no other side effects, or it SHOULD execute logic with side effects, but SHOULD NOT do both.

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md#23-side-effects

We have class files and files full of functions with side-effects It would be the first step towards class autoloading.

One of the things that irritates me about WordPress is that users aren't able to change their username and I never have heard a good reason why. If ClassicPress included the ability for users to do that, it would give them a good advantage to WordPress.

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

• Better search in pages, based on title content only. Example if you search for "foobar", you want this page to be in the results. Not the 150 children pages of it
• Add filter for parent page in the list
• Ability to order the pages with drad and drop from the list (without the need to edit every page and set the order number)
• Better view list, where the title is not written on 5 lines with every word splitted

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.

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

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

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.

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

I think it would be nice to be able to navigate to the next or previous post from the current post (i.e. after saving changes). This would be convenient if your editing posts in a particular category instead of having to click back on the "Posts" link in the admin sidebar, then having to filter the posts by category again. It would also eliminate having to hit the browser back arrow "twice" to get back to your post list.

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.

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

As discussed in slack (about woocommerce tracking users sensible data) I would like to see removed unecessary data tracking from ClassicPress, such as:

https://github.com/ClassicPress/ClassicPress/blob/1.0.1+dev/src/wp-includes/update.php#L93-L94

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.

#remove feature

In working with some more complex WordPress sites that need to interact with other systems and synchronize data it's becoming clear that the lack of a properly maintained UUID/GUID makes that really, really hard. See:

https://stackoverflow.com/a/45479/102699

I am talking a candidate key here, not UUIDs/GUIDs as primary keys.

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.

I cannot tell that posts table is large − it's very fat...
Please optimize it:

1. Don't create revisions for all posts. At least add option for enabling or disabling this. This will reduce size of posts table in some times.
2. Why images and other multimedia content are stored in posts table? Please move this to separate table.
3. When I click on «Add post» link Wordpress creates empty record in posts table. Why?! And if I'll press Cancel button this record will leave in table. And user cannot delete it using native Wordpress tools.

Below the login credentials there is this cryptic "remember me" that doesn't mean anything at all.

• Remember me for what, for how long and what for?

The correct syntax for such checkboxes is:

• Remember me for XX days on this computer

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.

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.

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

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.

It's usually a recommended step to improve security, changing table prefix from wp_ to something random.

It would be nice if core files, plugins, themes and uploads respectively would be kept separate of one another - both as locations and as objects.

That would make it much easier to move servers or switch between versions in case anything goes wrong.
Several websites could share a single install. It should also make it possible to specify different log-in paths - on subdomains or even different domains.

It would probably take some amount of symlinking and hooking into the existing code to preserve backwards compatibility.

example of directory structure:

• public_html
• • classicpress-X.1
• • classicpress-X.2
• • plugins
• • themes
• • example.com*
• -- uploads
• • example2.com*
• -- uploads

*each with their own config.php etc.

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:

• It helps improve accessibility
• It helps improve SEO

My suggestion would be to highlight the image in posts, pages … has the ability to get from url

Explanation.
Someone who has a small storage at the host server
your photos are set somewhere else
And to get that photo on its website, it has to use the plugin
If this option had a CP default, there would be no need for plugin’s
I hope you understand what I wanted to say

Ticket #28099 <https://core.trac.wordpress.org/ticket/28099> Passing an empty array to post__in will return have_posts() as true (and all posts will be returned).

If the post__in array is empty, the query should return no results instead of all posts. Currently to get the expected query result, the post__in argument must be checked for emptiness and the first element of the array set to 0 before passing to WP_Query->set().

For sites that publish multiple posts in a day, it would be really helpful if the default view when looking at the Posts list included the time as well as the date.

An optional extra that I found in a long-abandoned plugin that added times (WordPress Scheduled Time) is a text colour change strictly on the date/time column: green for scheduled, yellow for draft, red for trash. It makes it very easy to see quickly whether there are posts ready to go or needing approval, especially if there are multiple authors.

Users should be able to rename files as needed inside Media Library easily.

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

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.

Thanks

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.

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.

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.

The current shortcode parser is based on a single regular expression, making it error-prone and incapable of many useful features, such as nesting two instances of the same shortcode.

Here is a proof of concept parser for shortcodes that supports nesting and self-nesting out of the box: https://github.com/gschoppe/Better-Shortcode-Parser

From my point of experience permalinks proper setting should be set to:

/%category%/%postname%/

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.

Widget area should be empty. No one likes to delete it at start, everyone knows widgets as well, so example is not needed. Optionally search widget could be saved.

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.

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

Thanks.

Keep up the great work there.

Regards,
Damian Baker

I think this should a stock feature on installs. When you create a link (internal or external), that option should be there.

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.

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

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.

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:

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

Fix “From”, “Name”, and “Return-Path” headers for all WP notification emails since this is a long-standing WP security vulnerability.

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.

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.

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.

With the current design of the settings pages in WordPress, plugins have a very hard time customizing the settings interface, as most panels have only a few specific places where custom code can be inserted via action.

To make this much easier to deal with, the built in settings pages should be reimplemented as a stack of render functions attached to individual actions per section.

These sections should also be attached by actions, so that any plugin can replace or augment a setting on a case by case basis, by simply adding new render functions to the same action, or by replacing the existing render function.

In my opinion the best thing in Gutenberg is the ability to save a post without reloading the page. I think the editor for posts (or pages or CPT) should use a modal, like the attachment editor in the media library, with instant navigation to previous/next post and button for instant close.

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.

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.

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.

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

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/

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

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.

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.

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.

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!

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());

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?

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

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.

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

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

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

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

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.

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.

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.

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.

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

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.

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.

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

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

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.

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.