Avainsanana WordPress

Tremendously useful

11. lokakuuta 2020 klo 13.14
Sijainti: Keskustelupalstat: WordPress Support Forums
Avainsanat: WordPress

Happy to see the plugin get a new lease on life from an active and engaged developer. I only use a small portion of the features (suggested local tags), but this features alone makes it one of the most useful plugins for me.

Vastaa viestiin sen kontekstissa (WordPress Support Forums)

Inflection causes Simple Tags to miss relevant tag suggestions

10. lokakuuta 2020 klo 16.20
Sijainti: Keskustelupalstat: WordPress Support Forums
Avainsanat: kieli, WordPress

Thanks for keeping Simple Tags alive!

Simple Tags is great in picking exact local tag matches from the post text, but with Finnish (and probably some other languages as well), inflection often causes it to miss relevant suggestions (from Local tags). For instance, when using the inessive case ”Helsingissä” in the post, Simple Tags won’t suggest (previously added local tag) ”Helsinki”.

A fuzzy matching feature would help here.

While Simple Tags’ future was in limbo, I tested some other plugins, and one of them (maybe Smart Tag Insert) had such a feature: it showed related tags using some kind of fuzzy matching. I have no idea how difficult this feature would be to incorporate into Simple Tags though.

I know I can show all tags with the ”Click tags” feature, but with close to 2000 pre-existing tags, the full list is quite unwieldy.

Vastaa viestiin sen kontekstissa (WordPress Support Forums)

Use parse_blocks() instead of gutenberg_parse_blocks() in WP >=5

9. joulukuuta 2018 klo 16.09
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: WordPress

The release of WordPress 5.0 brought up an issue with the use of gutenberg_parse_blocks() in aesop.php: apparently for WP versions with Gutenberg integrated, parse_blocks() should be used instead of gutenberg_parse_blocks(), otherwise a fatal error occurs when Gutenberg tries to redefine WP_Block_Parser_Block.

Vastaa viestiin sen kontekstissa (Github)

The issue here, if any, is apparently just one of confusion

9. joulukuuta 2018 klo 15.43
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: WordPress

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

 

Vastaa viestiin sen kontekstissa (Github)

Cover2 also appears to exhibit this in single post view

6. marraskuuta 2018 klo 14.34
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: WordPress

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.

Vastaa viestiin sen kontekstissa (Github)

Feature request: searchability

20. lokakuuta 2018 klo 20.49
Sijainti: Keskustelupalstat: WordPress Support Forums
Avainsanat: saavutettavuus, WordPress

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.

Vastaa viestiin sen kontekstissa (WordPress Support Forums)

Undefined property: stdClass::$post_type when adding a Link

12. elokuuta 2018 klo 18.18
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: WordPress

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

  1. Set WP_DEBUG on (define as true)
  2. Enable WordPress’ link manager (add_filter( 'pre_option_link_manager_enabled', '__return_true' );),
  3. 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

Vastaa viestiin sen kontekstissa (Github)

Shortcode examples on FAQ page are broken

2. huhtikuuta 2018 klo 18.26
Sijainti: Keskustelupalstat: WordPress Support Forums
Avainsanat: WordPress

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.

Vastaa viestiin sen kontekstissa (WordPress Support Forums)

Trying to get property of non-object in header-overlay.php on line 53

5. joulukuuta 2017 klo 17.10
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: WordPress

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.

Vastaa viestiin sen kontekstissa (Github)

Captioned image with alignnone class aligned with screen left instead of content left

31. elokuuta 2017 klo 15.58
Sijainti: Vianhallintajärjestelmät: Github
Avainsanat: WordPress

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.

Vastaa viestiin sen kontekstissa (Github)

Vanhempia »