You can reproduce this even with Twenty Nineteen, by adding <?php $blocks = gutenberg_parse_blocks( $post->post_content ); ?> to header.php.
Replacing gutenberg_parse_blocks() calls with parse_blocks() seems to work around the issue (for me at least), and the issue here, if any, is apparently just one of confusion: renaming the function broke backwards compatibility, but since gutenberg_parse_blocks() is still defined, instead of a ”Call to undefined function” you get this attempt to redefine WP_Block_Parser (via inclusion of parser.php), resulting in the ”name is already in use”.
My test blog is running WP 5.0-beta3-43867 with Gutenberg 4.3.0-alpha-0841246 (from Daniel Bachhuber’s nightly), and the theme I’m using is Cover2 (Github here), which also appears to exhibit this in single post view.
I’ve narrowed it down to this function (called from header.php), where the gutenberg_parse_blocks() call triggers the issue.
I’m not saying I’m 100 % sure it’s Gutenberg and not the theme(s) at fault here, but I just thought I’d post this just in case it helps to find out either way.
Thanks for the excellent plugin! I’ve only had one issue so far: the previews are apparently saved encoded, which makes any decoded preview content unsearchable with WordPress’ search function (whereas searching for a piece of the encoded string brings up the matching post). If you could implement searchability of the decoded content, that’d be great.
The plugin refers to $post->post_type before testing it exists, which triggers an error for WP’s built-in (though hidden-by-default since forever) ”link” post type. The error appears quite harmless, as it doesn’t seem to interfere with the link editor’s functionality in any way.
Setup
- Simple Tags version 2.4.7
- WP version 4.9.8
- PHP version 5.6.33
Steps to reproduce
- Set
WP_DEBUG on (define as true)
- Enable WordPress’ link manager (
add_filter( 'pre_option_link_manager_enabled', '__return_true' );),
- Go to
Links > Add New
What happens
Simple Tags’ Settings box in the sidebar shows the following notices:
Notice: Undefined property: stdClass::$post_type in [path to wp]/wp-content/plugins/simple-tags/inc/class.admin.post.php on line 46
Notice: Undefined property: stdClass::$post_type in [path to wp]/wp-content/plugins/simple-tags/inc/class.admin.post.php on line 54
The shortcode examples on the FAQ page seem to be rendered (”It’s only fair to share…” + sharing icons) by the plugin instead of being shown as code. You should probably escape the shortcodes in those examples.
With WP_DEBUG enabled, a non-existing page (404) logs the following PHP error:
Trying to get property of non-object in wp-content/themes/cover2/components/header/header-overlay.php on line 53
I believe this is caused by the $post reference on that line, as $post has not been populated on a 404 page.
Steps to reproduce
Add an image to a post, type in a caption and set alignment to ’None’.
What I expect to happen
I’d expect the captioned image to be left-aligned with the main content column’s left, in line with <p>elements.
What happens
The image is left-aligned to the left edge of the screen. My attachment is a screenshot of a post with one uncaptioned and one captioned alignnone image.
All right, thanks for the response. As I said, the shortcode approach works just fine so I’ll have to stick with that, and create my own custom post type if/when necessary.
The description page clearly says the plugin features a ”Gallery custom post type”, but for the life of me I cannot figure out how to publish or even preview those posts. I can add galleries and use the short link on other post types, but the editor for galleries has no ”preview” functionality and there’s no way to view gallery posts on the front end on their own. I’d expect to be able to view the galleries at /(gallery_post_type_slug)/(gallery_post_slug).
Looking at the custom post type code (includes/class-posttypes.php), the ’public’ and ’rewrite’ args to register_post_type() have been set to false, which according to Codex documentation causes what I’m seeing. The args variable has a filter so I could override it; does this imply that I’m intended to add a filter to have the galleries work as a viewable post type and not just something used behind the scenes by the plugin?
Reading from the Codex page linked to, I think the value of ’field’ in the tax_query array should be ’term_id’ rather than ’id’: ”Possible values are ’term_id’, ’name’ and ’slug’. Default value is ’term_id’.” I’m guessing ’id’ only works because it causes a fall-back to the default.
