classicpress / classicpress-v2 Goto Github PK
View Code? Open in Web Editor NEWNOT READY FOR PRODUCTION.
License: GNU General Public License v2.0
NOT READY FOR PRODUCTION.
License: GNU General Public License v2.0
No errors
PHP Deprecated: preg_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /.../ClassicPress-v2/src/wp-includes/formatting.php on line 4861
This happens when Timezone is set to a city (Rome
) and not to an offset (UTC+1:30
).
No response
2.0.0
8.1
I can help test a solution
To be able to successfully login.
I created a new CP2 site and went through installation, but on initial attempt tp login I get this error:
No response
No response
2.0
8.1
No, I can't help
Empty log
[19-Jun-2023 14:15:36 UTC] PHP Deprecated: ltrim(): Passing null to parameter #1 ($string) of type string is deprecated in /wp-includes/formatting.php on line 4414
[19-Jun-2023 14:15:36 UTC] PHP Deprecated: ltrim(): Passing null to parameter #1 ($string) of type string is deprecated in /wp-includes/formatting.php on line 4414
[19-Jun-2023 14:15:43 UTC] PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /wp-admin/includes/class-wp-site-health.php:3053
Stack trace:
#0 /wp-includes/class-wp-hook.php(308): WP_Site_Health->wp_cron_scheduled_check()
#1 /wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
#2 /wp-includes/plugin.php(565): WP_Hook->do_action()
#3 /wp-cron.php(188): do_action_ref_array()
#4 {main}
thrown in /wp-admin/includes/class-wp-site-health.php on line 3053
[19-Jun-2023 14:15:43 UTC] PHP Fatal error: Uncaught TypeError: call_user_func(): Argument #1 ($callback) must be a valid callback, no array or string given in /wp-includes/functions.php:3722
Stack trace:
#0 /wp-includes/class-wp-fatal-error-handler.php(239): wp_die()
#1 /wp-includes/class-wp-fatal-error-handler.php(154): WP_Fatal_Error_Handler->display_default_error_template()
#2 /wp-includes/class-wp-fatal-error-handler.php(58): WP_Fatal_Error_Handler->display_error_template()
#3 [internal function]: WP_Fatal_Error_Handler->handle()
#4 {main}
thrown in /wp-includes/functions.php on line 3722
No response
Load a page
No response
2.0
8.1
I can help test a solution
HTML5 has been available to use for what feels like ages now, and one really great feature they introduced was an increased number of form input types, such as email, url, number, and so on.
These input types allow mobile browsers to display appropriate keyboards (such as a numpad in the case of "number"), while also often providing instant client-side validation, preventing erroneous form submissions.
Swapping to HTML5 form types will provide users with a more pleasant data entry experience (especially on mobile browsers), while also providing users with instant feedback if they input something in an improper format, without them having to wait for a page reload to get feedback.
There are a great many forms throughout WordPress, showing up across both the front and backend. Updating the code would be easy enough β do a codebase search for something like type=
and verify that each input is an appropriate type, update it if not, and then verify that the form displays and functions correctly. In the event that that a browser doesn't support one of the newer input types, they should interpret it as a text field, allowing the form to be submitted as it always has been.
No response
Assuming we're okay with deviating from the WordPress codebase in tiny amounts in potentially dozens of places, I'd be willing to go through my test install and see about updating the forms.
This is a big request (a codebase search for type="text"
turns up 102 results, with another 6 for type='text'
), though obviously not all of them would need changes.
Thoughts?
I know there are some form inputs that will take extra care to replace β such as the time and date fields when editing posts' published time. Changing them to number fields makes them wider and affects the layout of the page.
The Beaver Builder plugin should work in v2.0 as well as it works in v1.0.
When trying to activate the Beaver Builder plugin it doesn't work, a lot of errors in the console related to jQuery. See log file for all errors. Here's a screenshot as an example:
Console error log:
cpv2.lndo.site-1687575367924.log
Beaver Builder officially supports ClassicPress and works in v1.x. Any users upgrading to v2.0 will have major problems. So we need to figure out what's causing it and see if it's a bug we can fix. It also does work in WP 6.2.
This was present in PHP 7.4 and 8.1.
No errors in debug.log
.
2.0
8.1
I can help test a solution
When using the migration plugin, the process should completely convert v1.x to the provided nightly version.
The migration process completes, but v2.0 features are missing. So far, I noticed the following issues:
I can see the updated nightly version, custom login image, block compatibility, etc. So the migration did happen, but it seems to be incomplete. I tried going back to May nightlies, and the issue still happens. I tested this on 2 separate CP instances using wpsandbox.net. No errors in debug.log.
I have a local site running nightlies. I updated it and everything is OK. Site Health is present. So whatever happens is in the migration process.
No response
If anyone can confirm the issue, I would appreciate it. If you can't replicate this issue on your sites, can you also try migration using wpsandbox.net? Maybe it's something limited to their environment.
What's interesting, the files do seem to be there. At least some.
2.0 nightly
7.4
I can help test a solution
The expected behavior is when a theme or plugin when a specific version is set for example Requires PHP: 8.0
, it should throw an error or warning stating that the theme does not work with your version of PHP or Requires CP: 1.4.0
The current behavior just doesn't give any errors or warnings if a theme or plugin has set these requirements. Please note that the issue occurs in 1.5.3 so I don't know if Version 2 have the same issue or not since I haven't tried CP 2.0.
create a function or modify the code to use version_compare()
Requires PHP
or Requires CP
for something higher or lower depending on the Header.No response
1.5.3
7.3
I can help test a solution
Have both minified and unminified libraries.
SCRIPT_DEBUG
is true
the unminified version is present)wp-includes/js/tinymce/wp-tinymce.js
I find wp-includes/js/tinymce/wp-tinymce.js.gz
No response
define('SCRIPT_DEBUG', true);
No response
2.0.0+nightly.20230518
8.0
I can help test a solution
jQuery UI provides a series of widgets, interactions, and effects that are used throughout the CP admin pages. It was built to provide tools that HTML4 and XHTML did not provide natively. But HTML5 provides many of these tools, and now that HTML5 is well supported by all modern browsers, it's time to be moving away from jQuery UI to take advantage of that fact.
Such a transition would assist accessibility, because users would then be using tools provided by HTML5 natively rather than tools specific to ClassicPress and Wordpress. In addition, jQuery UI was never designed to work with touchscreens, and using HTML5 would overcome that limitation. Making this change would also help speed up the CP admin pages, which can sometimes be very slow, because of the significantly reduced JavaScript to be loaded on each admin page.
Of course, not everything that jQuery UI provides is now provided by HTML5. In cases where some sort of JavaScript is still required, I would expect us to adopt much more modern, smaller, vanilla JavaScript libraries which not only do not depend on jQuery, but which also support touchscreen usage.
This would be a longer-term project rather than a short-term task. Individuals would be free to pick an aspect that interests them. But I would like to get the ball rolling by replacing jQuery UI's draggable, droppable, and sortable interactions with HTML5 for the first two and a bespoke vanilla JavaScript library for the last one.
The draggable, droppable, and sortable modules total about 100kb minified, and they in turn depend on the core module, which weighs in at another 40+kb (on top of jQuery itself). So there is the potential for a significant reduction in the amount of JS loaded on each page where these modules are currently used.
jQuery UI's draggable and droppable can be replaced by HTML5 natively. Sortable, however, would require a new JS library. I have been comparing two: SortableJS and HTML5Sortable.
SortableJS weighs in at 44kb minified; HMTL5Sortable at 16.1kb minified.
I had initially expected to want to use SortableJS because it's under very active development and it's very slick. Unfortunately, I have not found it at all easy to get the dragging animations to look right, while it also includes a lot of options we don't need.
HTML5Sortable, on the other hand, worked perfectly the first time I tried it out on the dashboard widgets and post/page metaboxes. I have only tried dragging, dropping, and sorting so far without attempting yet to make calls to admin-ajax
to register the new widget positions, but it looks as though it's exactly what we will need. (Touch support would be provided using the DragDropTouch library, which adds another 18kb.) Unfortunately, the developer announced after the latest release (in December 2022) that it's no longer being actively developed.
I am therefore looking for feedback on whether it would be fine to go with HTML5Sortable, on the grounds that, since it mainly leverages native HTML5, it is not so important that it be actively developed β DragDropTouch works perfectly fine despite not being updated for six years β or whether we should go with SortableJS (or, indeed, some alternative that I have not explored).
I would be happy to work on replacing jQuery UI's draggable, droppable, and sortable interactions. But I need some guidance on the right JS library to use for the sortable replacement before I can start work on this in earnest.
For greater accessibility (and significantly less reliance on JavaScript), half of the menu screen has already been rebuilt using details
and summary
tags. A PR will also soon be merged that rebuilds the admin dashboard and post screen metaboxes using details
and summary
tags.
The logical next step is to re-build the widgets screen in the same manner. I have begun this task in a branch of my CP v2 fork at https://github.com/KTS915/ClassicPress-v2/tree/widgets
I am creating this issue partly to track progress and partly to invite help.
What I have done so far is as follows:
details
and summary
tags.details
and summary
tags.What still needs to be done:
div
that needs changing to a ul
, but I haven't found where yet, anddetails
tags need to be made to open and close properly. (See src/wp-admin/js/customize-widgets.js
.)src/wp-admin/js/widgets/text-widgets.js
.media-widgets.js
file (in src/wp-admin/js/widgets
) and I have already made the same edits to that file that I made to get the Custom HTML widget working, but they also need work on their own JS files (also in src/wp-admin/js/widgets
).I have already started working on this at https://github.com/KTS915/ClassicPress-v2/tree/widgets
Here's a feedback from a user that uses a screenreader and has been testing ClassicPress:
In this menu screen, there are menu items that can be expanded or collapsed where we can choose from posts, pages, custom links, etc. It would be far better if these were... I think the element is
<details>
? It's an element that clearly conveys an expanded or collapsed state. It is quite dificult to tell which of these category menus are expanded and or collapsed. The hint always says to press enter to expand or collapse this menu but no state is conveyed. I'd rather find a native way to do this with HTML than using ARIA, if at all possible, so these menus will work on mobile. They work now, but it would be far easier to navigate if I knew which were collapsed and which were expanded.
This refers to the "Add menu items" column in the nav-menus.php page:
As the user suggested, using <details>
might be the right choice here. It is widely supported..
WordPress is moving towards FSE, so changing the classic nav menus won't affect our backporting as much.
If we agree this is the way to go, I may be able to work on this. But I might need some help.
This relates to the default comment left during the initial installation.
We did change it in CP v1, but in v2 it didn't transfer. So I'm curious if we should change it or not.
One additional change I want to make to the text, is to remove the mention of Gravatar since CP disables it by default.
$first_comment_author = ! empty( $first_comment_author ) ? $first_comment_author : __( 'A ClassicPress Commenter' );
$first_comment_email = ! empty( $first_comment_email ) ? $first_comment_email : '[email protected]';
$first_comment_url = ! empty( $first_comment_url ) ? $first_comment_url : 'https://www.classicpress.net/';
$first_comment = ! empty( $first_comment ) ? $first_comment : __(
'Hi, this is a comment.
To get started with moderating, editing, and deleting comments, please visit the Comments screen in the dashboard.'
);
See above.
Yes
Not show updates for plugins from WordPress.
Three of my plugins are showing an update is available which is actually a WordPress plugin with the same name (but different slug):
No response
No response
2.0
8.1
No, I can't help
Edit Post in Visual must have text visible and editor button must be aligned to the left.
Edit Post in Visual is "blank" (hidden) and mce-editor button is left-stacked (one under other)
I try with Firefox and Chrome, same problem.
Edit Post in Visual is "blank" and after debuging I see inline-css:
.mce-panel {visibility: hidden;}
to solve I add in wp-includes/css/editor.min.css and wp-includes/css/editor.css
.mce-panel {visibility: visible;}
To solve mce button stacked (one under other) if using Visual Editor I add in wp-includes/css/editor.min.css and wp-includes/css/editor.css
.mce-btn {float: left;}
Edit post and try to switch from Text to Visual!
Changing wp-includes/css/editor.css it is the simplest and fastest solution that I have found. I do not know in detail about editor!
2.0.0+nightly.20231115
7.4
I can help test a solution
Report results.
It freezes.
No response
From command line wp doctor check core-verify-checksums
.
No response
1.7.0
2.0.0
7.4
I'll check what's happening.
I'm sharing this as an idea, in case others may see this useful. While testing nightly on a site with plugins that had updates it was hard to see the compatibility alert because it uses the same color as updates alert. Some people might not notice that it's a different type of alert. So it might be a good idea to introduce a different notice color dedicated to block compatibility, to help these alerts stand out from the rest of the update alerts.
Implement a new alert color and class.
Introduce a new notice class .notice-compatibility
.
Color: #fff5ea
Background: #ffa035
This is in-between warning (yellow) and error (red) notices. So it stands out, but not as bad as a red notice.
Yes
Even though the CP2 project states to be a fork of WP6.2 I cannot see the changes above mentioned in the relevant codebase.
With these changes missing, it unfortunately becomes impossible for WP Plugins newly submitted to .org to also be compliant with WPCS submission rules, when the plugin implements Direct DB Queries. As of 6.2 one has to use the new placeholder for the database table names. One of these affected projects is the Better WordPress Plugin Boilerplate, which is about to get a new, massive update with a fully revamped codebase, where at least one of the templates provided as example will interact with the database. I have either the choice to not include that, or require WP 6.2+. My preference is to keep supporting both worlds, so my suggestion would be (correct me if I miss it) to include these changes in CP2, and if possible, even backwards into CP1, as it actually relates to security, it might be a win.
I have asked the owner of these changes if he is considering backwards compatibility and actually, he has expressed interest and willingness to patch CP with these changes!
This gives me hope :)
I have never done a back port so I do not know how to do this, but please let me know if I can help in any way possible.
I can help test backports
The core update completes without an issue.
When updating the core on the update-core.php page, it returns an error. Log shows the following:
Looking around, it appears this function was added in 6.2:
https://developer.wordpress.org/reference/functions/_preload_old_requests_classes_and_interfaces/
There is a trac ticket that might be related:
https://core.trac.wordpress.org/ticket/57662
No response
2.0.0+nightly.20230520
7.4
I can help test a solution
Hallo,
I'm not sure, if it is helpful, ...
but I was curious to try v2.
Everything works using 8.0 ..., only error messages using php 8.1.
... only causes problems with classic-SEO using php 8.1, not with ... 8.0 ...
Deprecated: Calling static trait method Classic_SEO\Helpers\Conditional::is_heartbeat is deprecated, it should only be called on a class using the trait in /homepages.../wp-content/plugins/classicpress-seo/includes/module/class-manager.php on line 43Deprecated: Calling static trait method Classic_SEO\Helpers\Conditional::is_heartbeat is deprecated, it should only be called on a class using the trait in /homepages.../wp-content/plugins/classicpress-seo/includes/modules/status/class-status.php on line 29
....
kiind regards
I think I am not in the position to really help ...
see above
see above
see above
see above
v2
8.1
No, I can't help
The petition received much support to implement this change for new installs. This would be a good inclusion for v2.
@mattyrob suggested an easy solution:
In order to get this into the code without it being a breaking change couldnβt we just add:
define( 'DISALLOW_FILE_EDIT', true );
to the wp-config-sample.php file for new installs?
If this is all it takes, I think we should include it to improve overall security.
If it's only a new constant being added to wp-config-sample.php
, then yes I can submit a PR.
When looking for a theme I see all the themes are installable. There are 3 types of themes (Classic, block and FSE). Installing Classic or Block themes do work. FSE themes throw an error:
"There has been a critical error on this website. Please check your site admin email inbox for instructions."
They do not have the code to use the customizer and they break the site.
Expected behaviour is having some sort of notice warning me that that specific theme cannot be installed.
As of now the FSE themes do install and break the site
disabling the install button for FSE themes
trying to install and activate a theme that is FSE outputs the error after activation
No response
2.0
8.1
I can help test a solution
Here's a feedback from a user that uses a screenreader and has been testing ClassicPress:
I tested this, and the menu structure has some extra properties added to it in WP COM that makes moving menu items a lot easier because, instead of just saying, "item moved up," or "item moved down" it says, with a few hints, "item moved under XXX or "item moved out from under YYY menu item." this makes it far easier to know where my menu item structure is and where I am moving it to.
It would be even better if more variables could be included in the output. For example, the below is a sample structure and what I'd like conveyed.
1st menu structure item, site map.
2nd menu item structure, blog.
If I wanted to move site map below blog, after moving, I'd like to hear/read if at all possible,
"item moved to position X, under Y.
I hope that wasn't too confusing!
No response
No response
Not sure if I can help.
ClassicPress should contain and make reference to blocks
and the Block Editor
as little as possible and ideally not at all.
There are still instances where blocks
and the Block Editor
are mentioned in documentation or utilised in the code base.
We need a place to reference these location and then PRs to address each case.
Examples of current locations in the code base:
'wp-block' is still registered as a post type in src/wp-includes/post.php
The block editor is mention in REST-API tests in wp-admin/includes/class-wp-site-health.php
Default content for Privacy Policy pages may still contains block data in wp-admin/includes/class-wp-privacy-policy-content.php
Several block editor related functions exist in wp-admin/includes/post.php
This list is not comprehensive and more searches and details will likely be needed.
No response
2.0
8.0
Yes, I will submit a PR
When an update is available, the button should say "Update to version x.x.x".
The button says "Save Changes." But it does initiate the update process.
No response
update-core.php
page.I may be able to help submit a PR, but I can't find where the button text is coming from.
2.0.0+nightly.20230520
7.4
I can help test a solution
Track all the necessary Site Health changes in this issue.
Many browsers supporting HTML5 are able to do client-side checks on form fields such as required, url
, and email
fields to ensure that the form content is filled out properly beforehand.
The ClassicPress comment form outputs valid HTML5 fields when themes declare support for HTML5; however, it also outputs a novalidate
attribute into the form
declaration. This prevents client-side validation, allowing incorrectly filled-out forms to be submitted. When this occurs, the user is greeted by a generic WordPress error and they must go back to the form, fix the problem, and resubmit.
Enabling client-side comment form validation has a few advantages:
Example of a default comment form error message, showing that a required field hasn't been filled out:
HTML5 validation on the same form, as seen in Safari 17:
An example of what an invalidly formatted email address would show:
By replacing this:
printf(
'<form action="%s" method="post" id="%s" class="%s"%s>',
esc_url( $args['action'] ),
esc_attr( $args['id_form'] ),
esc_attr( $args['class_form'] ),
( $html5 ? ' novalidate' : '' )
);
with this:
printf(
'<form action="%s" method="post" id="%s" class="%s">',
esc_url( $args['action'] ),
esc_attr( $args['id_form'] ),
esc_attr( $args['class_form'] )
);
in wp-includes/comment-template.php
, HTML5 client-side validation will work as expected.
I have a pull request ready to go.
As few warnings as possible.
A lot of warnings are generated by wp i18n
command. Some warnings can be ignored, but some may need to be fixed.
Go through warnings and fix the ones that need to be fixed.
The file provided on the "Warning" line is not the only file where that string is used. That's just one of them. The command doesn't list all the files where the string is used.
Instructions:
Each warning needs to be verified. The context of strings needs to be checked, and if translator comments are correct you can check the task off. If translator comments needs to be changed, ideally, need to turn task into an issue by hovering over it.
Some warnings are about missing translator comments. Those can be converted into issues, if appropriate.
See list.
For reference, the command is:
wp i18n make-pot . v2-c.pot --ignore-domain --exclude=wp-content,composer.json,wp-admin/about.php --skip-theme-json --skip-block-json --no-color
2.0
7.4
Yes, I will submit a PR
wp-tinymce.js should be present.
The file is missing in the nightly. Might be a few nightlies, as I have an older version running on a local site and here's the latest one:
I ran into this problem while trying to test Elementor:
2.0.0-nightly
7.4
I can help test a solution
No fatal error.
PHP Fatal error: Uncaught Error: Call to undefined function unregister_block_type()
.
We need to add a polyfill for this function. We already have a polyfill for register_block_type()
.
You need a plugin that unregisters block types. In my case, it's the SEOpress Pro plugin. This is a generic version of what it does:
add_action( 'current_screen', 'custom_unregister_blocks' );
function custom_unregister_blocks(){
$screen = get_current_screen();
if( is_admin() && $screen and $screen->base !== 'post' ){
unregister_block_type( 'custom/how-to' );
unregister_block_type( 'custom/how-to-step' );
}
}
No response
2.0
7.4
I can help test a solution
Gravatar supports another generated avatar type besides the wavatars, identicons, etc. that ClassicPress already supports. With one line added to wp-admin/options-discussion.php
, the feature can be implemented.
No response
In wp-admin/options-discussion.php
, add the following line to the $avatar_defaults
array which is around line 316:
'robohash' => __( 'Robot (Generated)' ),
That's it. Feature implanted.
I've already tried to submit a pull request for this, but no matter what I try in GitHub Desktop, it keeps wanting to submit to an unrelated pull request about a different feature entirely. So I'm opening this in hopes that someone else wants to add a single line of code that would resolve this request. :)
Pages should load without errors occurring.
Loading an uncached menu can generate the following errors:
Undefined property: stdClass::$target in ../wp-includes/class-walker-nav-menu.php on line 180
Undefined property: stdClass::$xfn in ../wp-includes/class-walker-nav-menu.php on line 183
Undefined property: stdclass::$current in ../wp-includes/class-walker-nav-menu.php on line 196
Reported on WP Trac at https://core.trac.wordpress.org/ticket/46382
I have provided the solution on the above Trac ticket at https://core.trac.wordpress.org/ticket/46382#comment:5
Load a page. This must be uncached, and so must the menu. (Some themes and plugins cache either or both, so these errors don't appear for everyone.)
No response
2.0
8.1
I can help test a solution
Hallo,
I get the following deprecation message in backend at
-> Design -> Menu
Deprecated: preg_replace(): Passing null to parameter ClassicPress/Documentation-Issue-Tracker#3 ($subject) of type array|string is deprecated in /homepages/23/d278325892/htdocs/verwaltungsrecht/wp-admin/includes/plugin.php on line 2100
... the message does not disappear even if I deactivate all plugins ...
I use the Genesis Framework with Genesis Sample Theme with php 8.1 (the message does not disappear even using theme Twenty Twenty), v2 20230720
Kind regards
SΓΆnke
A list of URLs that need to be changed in the core:
https://docs.google.com/spreadsheets/d/1yEA9Jnlx9L-QH4CeJLRlXY0QBCqHQQ4PpwCfM8-Lk3I/edit?usp=sharing
To ensure our block compatibility feature works as expected, we need to polyfill all functions that can be polyfilled.
The list of block-related functions in WordPress (6.2.2):
get_block_editor_theme_styles
render_block_core_legacy_widget
the_block_editor_meta_boxes
locate_block_template
register_block_core_read_more
render_block_core_post_comments_form
register_block_core_post_comments_form
block_core_gallery_data_id_backcompatibility
register_block_core_site_title
get_block
block_core_home_link_build_css_colors
register_block_core_shortcode
register_block_core_block
serialize_blocks
register_block_core_query_pagination_next
block_core_gallery_render
should_load_block_editor_scripts_and_styles
render_block_core_comment_edit_link
process_blocks_custom_css
get_default_block_editor_settings
block_core_navigation_submenu_render_submenu_icon
add_block_from_stack
register_block_core_legacy_widget
render_block_core_post_date
parse_blocks
register_block_core_comments_pagination_numbers
block_core_navigation_link_build_css_colors
render_block_core_post_content
get_typography_classes_for_block_core_search
parse_block_styles
enqueue_editor_block_styles_assets
post_comments_form_block_form_defaults
block_version
register_block_core_file
get_registered_styles_for_block
render_block_core_post_author_biography
get_block_file_template
block_core_social_link_get_color_styles
render_block_core_post_featured_image
wp_enable_block_templates
resolve_block_template
wp_add_global_styles_for_blocks
get_block_core_post_featured_image_border_attributes
serialize_block
render_block_core_query_pagination_next
register_block_core_query
register_block_core_post_terms
render_block_core_post_title
wp_enqueue_editor_block_directory_assets
apply_block_core_search_border_style
get_block_wrapper_attributes
render_block_core_template_part
build_template_part_block_area_variations
generate_block_asset_handle
wp_is_block_theme
filter_block_content
render_block_core_comments
render_block_core_tag_cloud
register_block_core_latest_comments
filter_block_kses
use_block_editor_for_post_type
is_block_theme
render_block_core_navigation
get_dynamic_block_names
the_block_template_skip_link
register_block_pattern
register_block_core_archives
register_block_core_query_pagination_numbers
register_block_core_rss
strip_core_block_namespace
render_block_core_block
is_block_editor
render_block_core_comments_pagination
build_template_part_block_variations
get_styles_block_nodes
unregister_block_pattern
register_block_core_post_featured_image
wp_common_block_scripts_and_styles
filter_block_kses_value
render_block_core_comment_author_name
render_block_core_page_list
render_block_core_search
block_core_latest_posts_get_excerpt_length
register_block_core_comments_pagination
register_block_core_cover
register_block_core_gallery
register_block_core_comment_author_name
get_block_metadata_i18n_schema
blocks
render_block_core_calendar
render_block_core_site_tagline
get_allowed_block_types
register_block_core_template_part
wp_should_load_separate_core_block_assets
register_block_core_post_title
wp_get_block_default_classname
has_blocks
excerpt_remove_blocks
register_block_script_handle
render_block_core_social_link
register_block_core_page_list
block_footer_area
wp_normalize_remote_block_pattern
get_block_template
get_block_templates
block_core_navigation_get_post_ids
render_block_core_comment_date
register_block_core_site_tagline
render_block_core_post_author_name
block_core_page_list_render_nested_page_list
block_core_navigation_block_contains_core_navigation
render_block_core_post_navigation_link
render_block_core_cover
get_block_data
register_block_core_comments
register_block_core_home_link
render_block_core_post_excerpt
render_block_core_comment_template
wp_should_load_block_editor_scripts_and_styles
block_core_heading_render
block_core_calendar_update_has_published_post_on_delete
block_core_navigation_from_block_get_post_ids
register_block_core_post_author_biography
block_core_comment_template_render_comments
block_core_navigation_build_css_font_sizes
get_styles_for_block
block_header_area
remove_block_asset_path_prefix
block_core_calendar_update_has_published_post_on_transition_post_status
get_block_nodes
block_core_latest_posts_migrate_categories
build_template_part_block_instance_variations
has_same_registered_blocks
render_block_core_comments_pagination_next
render_block_core_home_link
block_core_page_list_build_css_colors
register_block_core_categories
styles_for_block_core_search
render_block_core_rss
register_block_pattern_category
render_block_core_comments_title
block_core_navigation_maybe_use_classic_menu_fallback
classnames_for_block_core_search
block_core_home_link_build_li_wrapper_attributes
register_block_core_tag_cloud
render_block_core_comment_content
register_block_core_post_template
register_block_core_navigation_submenu
register_block_core_widget_group
register_block_core_latest_posts
build_query_vars_from_query_block
render_block_core_read_more
block_core_home_link_build_css_font_sizes
get_block_editor_server_block_settings
render_block_core_comment_reply_link
block_core_page_list_build_css_font_sizes
get_legacy_widget_block_editor_settings
render_block_core_latest_comments
block_core_calendar_update_has_published_posts
wp_filter_out_block_nodes
get_allowed_block_template_part_areas
build_comment_query_vars_from_block
register_block_core_query_pagination_previous
wp_enqueue_block_style
the_block_editor_meta_box_post_form_hidden_fields
render_block_core_post_terms
get_block_categories
render_block_core_comments_pagination_numbers
get_comment_delimited_block_content
serialize_block_attributes
block_template_part
register_block_core_comments_pagination_next
render_block_core_post_template
register_block_style
register_block_core_pattern
render_block_core_image
block_core_page_list_nest_pages
block_core_navigation_render_submenu_icon
get_typography_styles_for_block_core_search
comments_block_form_defaults
get_border_color_classes_for_block_core_search
register_block_core_post_excerpt
get_blocks_metadata
render_block_core_widget_group
register_block_core_comment_template
register_block_core_comments_pagination_previous
block_core_navigation_build_css_colors
render_block_core_site_title
block_core_navigation_link_render_submenu_icon
get_block_theme_folders
wp_should_skip_block_supports_serialization
register_block_core_calendar
get_default_block_template_types
get_classic_theme_supports_block_editor_settings
register_block_core_post_date
block_core_calendar_has_published_posts
register_block_core_post_author_name
render_block_core_post_author
block_core_navigation_submenu_build_css_font_sizes
register_block_core_social_link
build_dropdown_script_block_core_categories
wp_generate_block_templates_export_file
render_block_core_avatar
block_core_navigation_get_most_recently_published_navigation
render_block
register_block_core_post_author
add_inner_block
render_block_core_loginout
block_core_navigation_typographic_presets_backcompatibility
get_color_classes_for_block_core_search
block_core_navigation_get_menu_items_at_location
register_block_core_query_no_results
render_block_core_pattern
block_core_navigation_sort_menu_items_by_parent_id
register_core_block_types_from_metadata
register_block_style_handle
apply_block_core_search_border_styles
register_block_core_term_description
render_block_core_navigation_submenu
enqueue_legacy_post_comments_block_styles
register_block_core_avatar
unregister_block_style
render_block_core_categories
render_block_core_query_pagination
block_core_navigation_filter_out_empty_blocks
register_block_core_comment_date
register_block_core_search
block_core_navigation_get_classic_menu_fallback_blocks
render_block_core_query_pagination_numbers
register_block_core_site_logo_setting
wp_enqueue_block_support_styles
unregister_block_pattern_category
apply_block_supports
get_default_block_categories
render_block_core_comments_pagination_previous
block_core_post_template_uses_featured_image
register_block_core_heading
block_core_navigation_link_maybe_urldecode
wp_enqueue_registered_block_scripts_and_styles
get_block_core_post_featured_image_overlay_element_markup
block_core_navigation_link_build_css_font_sizes
block_has_support
register_block_core_navigation
register_block_core_image
block_editor_rest_api_preload
register_block_core_loginout
render_block_core_query_title
block_core_navigation_submenu_build_css_colors
block_core_navigation_get_classic_menu_fallback
render_block_core_term_description
render_block_core_query_pagination_previous
_block_template_render_without_post_block_context
register_block_core_post_navigation_link
render_block_core_site_logo
render_block_core_file
wp_setup_widgets_block_editor
enqueue_block_styles_assets
use_block_editor_for_post
register_block_core_comment_edit_link
block_core_navigation_get_fallback_blocks
register_block_core_navigation_link
register_block_core_comment_content
register_block_type_from_metadata
register_legacy_post_comments_block
register_block_core_site_icon_setting
render_block_core_query_no_results
block_core_social_link_get_icon
get_the_block_template_html
register_block_core_post_content
block_core_navigation_parse_blocks_from_menu_items
render_block_core_shortcode
do_block_editor_incompatible_meta_box
register_block_core_comments_title
has_block
register_block_type
render_block_core_navigation_link
render_block_core_latest_posts
unregister_block_type
register_block_core_site_logo
render_block_core_archives
get_block_classes
block_core_social_link_services
block_core_social_link_get_name
wp_use_widgets_block_editor
get_block_editor_settings
register_block_core_query_pagination
wp_pre_kses_block_attributes
do_blocks
register_block_core_query_title
register_block_core_comment_reply_link
For reference, these are the block-related functions in ClassicPress 2.0.0 (08-09 nightly):
The following block-related functions are in the core, not polyfills:
wp_pre_kses_block_attributes
The following block-related functions are in the core but set to return: false
. I assume that is a polyfill.
use_block_editor_for_post
use_block_editor_for_post_type
is_block_editor
(polyfill)The following block-related functions are not in WordPress but we do have a polyfill:
update_extensions_using_blocks
using_block_function
using_block_function_theme
(FSE theme notice)delete_themes_using_blocks
using_block_function_row
delete_plugins_using_blocks
Might not be related to blocks?
block_request
PclZipUtilCopyBlock
Use gettext
to change core URLs to reduce merge conflicts.
add_filter( 'gettext', 'fixlink', 10, 3 );
function fixlink( $translated_text, $untranslated_text, $domain ) {
if ( $domain !== 'default') {
return $translated_text;
}
if ( $untranslated_text !== '<a href="https://wordpress.org/support/forums/">Support forums</a>') {
return $translated_text;
}
return str_replace('https://wordpress.org/support/forums/', 'https://forums.classicpress.net/c/support', $translated_text);
}
I tried some "popular" WP plugins.
Some of them don't work because they call block-related functions.
A possible solution is to make a "compatibility" plugin to declare those. Example:
function register_block_type(...$args) {
return false;
}
But for me the best solution is - as we go - have them in core, because this is the only way to handle situations like:
if ( WP_Screen::is_block_editor() ) {
do_something();
}
Yes.
WordPress 5.2.0 introduced a new template hook, wp_body_open
, which fires immediately after the opening body
tag.
This hook can be useful for outputting custom content before any of a theme's body content starts to output.
As a default WordPress hook, though, it should be included so that plugins and tinkerers can take advantage of it just as they do wp_head
and wp_footer
.
The hook is described here: https://developer.wordpress.org/reference/hooks/wp_body_open/
No response
Include <?php do_action( 'wp_body_open' ); ?>
or similar after the opening body
tag in each of the included themes.
This is a quick and simple thing that shouldn't cause anything to break, but I'd be willing to test. Not submitting a pull request myself because of how busy I'm going to be this month with work and preparing for a nursery for my upcoming baby. :-)
This is a minor privacy enhancement. The Gravatar link should have noreferrer
so it doesn't pass referrer to gravatar.com to be logged by their analytics apps.
Add rel="noreferrer"
to the URL:
ClassicPress-v2/src/wp-admin/user-edit.php
Lines 599 to 600 in 3d3e5f8
No response
Yes, I can submit PR.
No column shift.
Originally reported by Avias on the forum:
https://forums.classicpress.net/t/classic-seo-2-2-0-alpha-0-help-testing/4836/5
https://forums.classicpress.net/t/classic-seo-2-2-0-alpha-0-help-testing/4836/7
After quick editing a post, the post column is shifted.
No response
No response
2.0.0-dev
8.1
I can help test a solution
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
composer.json
php >=7.4
dealerdirect/phpcodesniffer-composer-installer 1.0.0
wp-coding-standards/wpcs 3.0.1
phpcompatibility/phpcompatibility-wp 2.1.4
yoast/phpunit-polyfills 2.0.0
src/composer.json
johnpbloch/wordpress-core-installer 2.0.0
.github/workflows/coding-standards.yml
actions/checkout v4
shivammathur/setup-php v2
ramsey/composer-install v2
actions/checkout v4
actions/setup-node v4
actions/cache v3
shivammathur/setup-php v2
ramsey/composer-install v2
.github/workflows/javascript-tests.yml
styfle/cancel-workflow-action 0.12.0
actions/checkout v4
actions/setup-node v4
actions/cache v3
ubuntu 22.04
.github/workflows/php-compatibility.yml
actions/checkout v4
shivammathur/setup-php v2
ramsey/composer-install v2
.github/workflows/phpunit-tests.yml
styfle/cancel-workflow-action 0.12.0
actions/checkout v4
actions/setup-node v4
actions/cache v3
mirromutth/mysql-action v1.1
shivammathur/setup-php v2
niden/actions-memcached v7
.github/workflows/triage.yml
actions/checkout v4
actions-ecosystem/action-add-labels v1
.github/workflows/welcome-new-contributors.yml
wow-actions/welcome v1
package.json
@wordpress/a11y 3.46.0
@wordpress/api-fetch 6.43.0
@wordpress/dom-ready 3.46.0
@wordpress/hooks 3.46.0
@wordpress/i18n 4.46.0
@wordpress/url 3.47.0
node-sass 9.0.0
@lodder/grunt-postcss 3.1.1
@rollup/plugin-commonjs 25.0.7
autoprefixer 10.4.16
clipboard ^2.0.11
grunt 1.6.1
grunt-banner 0.6.0
grunt-contrib-clean 2.0.1
grunt-contrib-concat 2.1.0
grunt-contrib-connect 4.0.0
grunt-contrib-copy 1.0.0
grunt-contrib-cssmin 5.0.0
grunt-contrib-imagemin 4.0.0
grunt-contrib-jshint 3.2.0
grunt-contrib-qunit 8.0.1
grunt-includes 1.1.0
grunt-jsdoc 2.4.1
grunt-jsvalidate 0.2.2
grunt-legacy-util 2.0.1
grunt-replace 2.0.2
grunt-rtlcss 2.0.2
grunt-sass 3.1.0
grunt-webpack 6.0.0
ink-docstrap 1.3.2
install-changed ^1.1.0
lodash ^4.17.21
moment ^2.29.4
postcss 8.4.31
qunit ^2.19.4
rollup 4.5.1
sinon ^17.0.0
sinon-test ^3.1.5
source-map-loader ^4.0.1
sync-request 6.1.0
terser 5.24.0
terser-webpack-plugin ^5.3.7
webpack 5.89.0
.nvmrc
node 20.10.0
Customizer has the ability to open sections based on URL parameters (more info).
For example, when I visit /wp-admin/customize.php?autofocus%5Bsection%5D=custom_css
it will automatically open custom CSS section in the customizer. This is a link on the theme editor page:
It doesn't do anything and there are no console errors. This works in 1.5.3.
No response
/wp-admin/customize.php?autofocus%5Bsection%5D=custom_css
A lot of themes link to sections from their admin pages. Core links to it in at least one location.
2.0.0
7.4
I can help test a solution
As minimum required version is PHP 7.4 and Unit tests are no more running on PHP 5.6 PHP Compatibility check should check for PHP 7.4+.
PHP Compatibility check are checking PHP 5.6.
Amend phpcompat.xml.dist
.
See failing tests in PR #88.
No response
2.0
7.4
I can help test a solution
Home and application password working.
wp-date
is used in wp-admin/js/application-passwords.js
and in wp-admin/js/dashboard.js
.
Remove the functions from the calling scripts and the dependency from src/wp-includes/script-loader.php
or add wp-date
.
No response
2.0.0
8.1
I can help test a solution
Is TinyMCE supposed to be working in the Text widget? I don't use it normally but, as I'm working on something to do with widgets, I had cause to test it and found that Tiny doesn't work. (In fact, there's an error generated in the browser console.)
When opening a Text widget, the user can enter blank text only. There is no TinyMCE editor.
What's missing are some lines in the ~/wp-includes/script-loader.php
file and then some lines in the ~wp-admin/js/widgets/text-widgets.js
file.
I can provide a PR if we agree that Tiny is supposed to be working (which I think is what we want). If we don't want that, then some lines need removing from the ~wp-admin/js/widgets/text-widgets.js
file to avoid generating the current error.
Open a Text widget and see for yourself.
No response
2.0.0+nightly.20231005
8.1
Yes, I will submit a PR
About screen for CP v2 should state the correct version of WP from which it was forked.
About screen says:
About ClassicPress
ClassicPress is a fork of the ClassicPress 4.9 branch, including the battle-tested and proven classic editor interface using TinyMCE.
Correct version number
Update CP to latest version and read the About screen.
Tested on updates
2.0.0+nightly.20230926
8.1
I can help test a solution
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.