- This topic has 1 reply, 2 voices, and was last updated 6 years, 9 months ago by
Kevin.
-
AuthorPosts
-
-
April 27, 2015 at 3:45 pm #3649
spitfireMemberHi Piklist, thank-you for this plugin. I had actually started creating my own version of Piklist (spent a few weeks at it) when I came across your plugin while searching for help on a topic. You saved me a lot of work so thanks! 🙂
Just have a question regarding the saving of postmeta you have implemented. It’s kinda nitpicky, but just wondering about the implementation you chose for it. Whenever a page is saved, the TABLE_postmeta row is deleted and then saved rather than updated. Code is in class-piklist-form.php around row 1626 in version 0.9.4.26. This implementation increments the meta_id column for each field/field-group created using Piklist. WP Codex recommends using updata_metadata() function as it will create the md row if not existing, but update the row if exists. So just wondering why you chose to delete_metadata() first then save?
Even though meta_id is a bigint type in the db which is plenty for 99.99% of websites, I personally don’t like unnecessary incrementation. Did you choose this implementation because of wp revisions possibly?
Thanks for this great software and I hope to be a help in making it better as I am certain I will be using it for most of my future WP sites.
-
April 28, 2015 at 2:03 pm #3654
KevinKeymaster@spitfire-
Love the avatar, I am a big fan of the P51 Mustangs. Also, great question. I have mulled over this countless times and have even written code trying different ideas and methods. The long story, put shortly, is that it just doesn’t matter. As we add and remove meta in WordPress without Piklist we still have the same issue with the ids. However there are form coherency issues that it will help with in the future but the biggest reason at the moment is that the order they are inserted into the database is the order they should be pulled out. We do this without any extra meta information like other plugins use, trying to leverage WordPress as much as possible without changing every single possible query that an end user could make for the data (the more complicated the machine the more likely it is to break). The maximum size of a bigint is 2^64… so if you managed to ever hit that, WordPress and any plugins aside, you should probably already be optimizing or rethinking your application architecture.
There are a few other reasons for this we will demonstrate in the future, but rest assured we have spent a considerable amount of time on this decision and we believe it to be the best course for the meta tables.
Let me know if you have any other questions.
Thanks,
Kevin
-
-
AuthorPosts
- You must be logged in to reply to this topic.