string WP_Post->ID If Classic Editor Plugin

  • Resolved dougbmorris

    (@dougbmorris)


    5 years, 1 month ago

    Background: I am developing my first plugins to create my first WP (or any) CMS website. I replaced my computer’s storage device and updated to the newest WordPress, version 5.2.3, which comes with the new blocks editor. During my previous development I had the classic/TinyMCE editor as the default core editor. My plugins make widgets and manage metadata with their own meta boxes. Therefore, they do not entirely work with the block editor API. I want to finish these plugins and make a website with the classic/Tiny editor before seriously studying and applying the Blocks Editor Handbook.

    Problem: There is a display callback passed as the third argument of WP function add_meta_box(). The sole argument passed to that callback, I call it class method ‘function html( $post ) {…}’, is a post value. Value $post is always an instance of WP_Post, as desired. If I DO NOT have the Classic Editor plugin, version 1.5, active, the block editor is active and the value of $post->ID is an int, e.g. int(11), as desired. If Classic Editor plugin 1.5 is active, the value of $post->ID is a string, e.g. string “11”. I used echo and var_dump to demonstrate that at the start of method html().

    Evaluation Effort: The Classic Editor plugin 1.5 implementation is one php file and one very small JS file. I could not find anything wrong by visual inspection of those files and the core WP files (not all of them, of course). I can’t locate the plumbing that feeds the meta box display callback, e.g. my method html().

    Concerns:
    (1) I think that post ids should always be ints in the PHP world. True? I see core code that casts to (int). I I am supposing I should just cast to int in my callback method. In core code, wouldn’t it make more sense to use assert( is_int($post_id), … ) for post IDs that should not be unscrubbed user data from the client side but ‘inside’. Detect the problem early and trace less?

    (2) The other approach would be to accept post ID regardless of its type and adapt to it. Meaning I could pass it as is to WP functions. I also need to compare post IDs from my metadata apples to apples (or start using loosing typing, which I don’t like to do).

    (3) An aside, it seems (saw somewhere in WP core) that the value int(0) is NOT a valid post ID for an actual post (it’s falsy and tested that way, not my favorite semantic approach). Is it true that int zero is definitively understood to be no actual post? If so, is it documented? Importantly to me as an implementation detail, can zero be used as a post ID in the MySQL/MariaDB database (i.e. table wp_posts, column ID and table wp_postmeta, column post_id ). In my database they are the type bigint(20) unsigned. Maybe the auto_increment attribute prevents zero from being used?

    I consider PHP zero to be a falsy and loose-typing hazard to avoid. I’m not a seasoned programmer, and I don’t presume what others should do.

    Thanks for reading, kind person.

Viewing 3 replies - 1 through 3 (of 3 total)

  • (1) I would agree, and the core code does cast to int, so that’s a good standard to follow.

    (2) If you don’t do anything with the ID, pass it as is.

    (3) I don’t know where it is documented, but there are a lot of places in core that a zero post ID indicates the current post, as in “look it up or use the global $post”.

    For your plugin, you can try testing with other plugins that disable the block editor. Perhaps Classic Editor plugin is the culprit, perhaps not. There is one called Disable Gutenberg, and there might be others. There is also TinyMCE Advanced.
    You could also try on other versions of WP.

    Thread Starter dougbmorris

    (@dougbmorris)

    Thanks, Joy. I just tried the Disable Gutenberg plugin. It’s effect is identical to that of the Classic Editor plugin. If active, ID is a string. If not, ID is an int.

    I am surprised that, as far as my searches suggest, no one else is having this particular problem. I always worry about having a unique problem. It suggests I am doing something uniquely not right. The only exception I know is not having the reverse-engineered drivers for a new computer. I got Linux to install 3 months after my initial attempts. Anyway, I can and will (hack) correct the problem in my code and see what happens. I hope this is not a widespread issue.

    Thread Starter dougbmorris

    (@dougbmorris)

    Addendum: I am using the ‘save_post’ action hook to register a callable that takes a single argument, the post ID. The post ID is an int like it should be.

    Workaround: I added code to the display callback to test if the post ID is a string, and if so, to convert to an int if ( (string) (int) $post_id === $post_id ) and otherwise to return immediately, after sending a diagnostic message to standard out if ( WP_DEBUG ). It seems to be working.

    Resolution: Whether or not this issue should be raised for another forum or submitted as a bug I leave to others to decide. I can only guess the issue is with core and that after 2021 it won’t matter. It has a simple workaround. Perhaps this documentation of the issue will help someone.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘string WP_Post->ID If Classic Editor Plugin’ is closed to new replies.