Critical flaw

This is due to the default architecture of WordPress post meta.

Pods already has a feature that allows you to store custom meta to a dedicated table as you requested.

You can enable it by going to Pods Admin > Components and clicking Enable for Advanced Content Types. As the description reads in the plugin: A content type that exists outside of the WordPress post and postmeta table and uses custom tables instead.

Once you have enabled the component, when creating a new Pod, select Advanced Content Type (separate from WP, blank slate, in its own table) as the Content Type.

If you have already configured hundreds of fields using Post Meta as the storage method, you can convert them to table-based storage by enabling the component mentioned above as well as the Import/Export Packages component.

Export the field defitionitions for your desired Pods using Components > Import/Export Packages. In the exported JSON, change "storage": "meta", to "storage": "table",, and optionally change the value for "name" if you would like to not overwrite your existing Pod definition on import. Then import the revised JSON. This will set up the desired fields as a table without needing to reconfigure them in the user interface, overwriting the previous Pod definition if "name" has not been changed.

Guys, thanks for fast answer, but you read very badly.

Problem is not about CustomFields VALUES storing, problem is about CustomFields SETTINGS storing – the SETTINGS of the Pods itself!!! Which Pods plugin store at “wp_posts” and “wp_postmeta”!!! It’s a completely architecture and fundamental fail!!! Plugin which was made to remove garbage from WP DB – add the same garbage by ITS OWN CustomFields SETTINGS!!!

It must be resolved ASAP, it’s a real CRITICAL FLAW!

• This reply was modified 1 year, 8 months ago by johnynla.

Apologies for the misunderstanding. Enabling object caching with your host or installing Pods Alternative Cache might alleviate the weight of those queries on your server. If that doesn’t resolve it, @sc0ttkclark may have some insight into the nature of the queries used for the administration pages.

Hey there @johnynla,

I really appreciate your feedback here. I’m working on planning the next iteration of Pods in 3.x which will change how we store configs to decouple it from the post/postmeta tables that we moved to in Pods 2.0. That move was done to avoid custom tables and to cater to wordpress.com requirements at the time. But alas ?? that is no longer necessary or a requirement.

In the meantime, you have a few options:

• Register your configurations via code
• Register your configurations via config file
• Review your reliance on large sets of fields, this could be an indication that you may want a Relationship to another Pod instead (if you have things like “Item 1 – Name”, “Item 1 – Country”, “Item 2 – Name”, “Item 2 – Country”, etc..
• Look over your hosting plan to see if it offers Object Caching or if it’s limited to low resources (shared hosting), those two things could help you determine the source of the resource sluggishness

Things will be changing here but you must also appreciate that for some strange reason — this runs just fine on a site I’m involved with on SiteGround hosting with 47 pods and 939 fields. That site only uses 140M and believe me that Pods is only one of many major components that the site is running. That specific site is on Pods 2.7.30 and will see major performance improvements if it were running Pods 2.8.x and 2.9.x instead.

I’m not sure if you’re experiencing any slow downs or if this is just general feedback about where we store our configs, but rest assured that we are working towards the next generation of our configuration storage.

Hi,

> Register your configurations via code

> Register your configurations via config file

https://docs.pods.io/code/registering-configurations/ – this? Registering Pod by file will not create mass wp_posts and wp_postmeta? Then where they will store at DB?

Which file format is better to use JSON/YML/PHP? Which file format you plan to use for newer Pods CustomFieldsSettings storing at DB?

How it’s possible to make Updates for 1 Pod or 1 CustomFieldsSettings? For example correct the type of 1 CustomField via such config file? If I will register it once more – it will not create one more data storage? If I will un-register it – it will not lose all existed data? etc. How to work with CustomFieldsSettings updates by files?

Those Pods config files on registering will not make conflicts or remove all Pods previously created via site backend interface?

I have enough powerful hosting but when I’ve create Pods with 50-100 CustomFields – when I open it at backend to “Add Data to Pod” or “Edit Pod CustomFieldsSettings” on 1 page – its very slow. Seems like your scripts get data about Pod CustomFields from DB one-by-one – maybe because of that its very slow? Maybe at least you can just change current many SQL SELECT requests for each field to take whole data about all CustomFields from this Pod to 1 joint SQL request?

ETA of changing CustomFieldsSettings storing method at DB?

• This reply was modified 1 year, 8 months ago by johnynla.
• This reply was modified 1 year, 8 months ago by johnynla.
• This reply was modified 1 year, 8 months ago by johnynla.
• This reply was modified 1 year, 8 months ago by johnynla.

Guys you will ANYWAY resolve this critical problem by add a new method to store CustomFieldsSettings at DBsutomTable like “wp_pods”. Maybe if I will give you $200 donation you can do it asap for 1 week? maybe not to replaced previous method, but just add a new one – new table with new Pod setting “store Pods settings at wp_posts&postmeta or wp_pods custom table”. What do you say?

Yes, the https://docs.pods.io/code/registering-configurations/ page is correct, and yes that will not create configs in the database. I personally prefer using JSON because it’s my favorite to work with, but other people have other preferences so we have support for YAML and PHP-based configs. One area that these configs don’t cover super well are relationship fields. That’s something we have to work on more as we also migrate wp_podsrel away from DB-based configs (it relies on pod/field IDs).

The way Pods fetches meta usually primes the cache so that means it fetches all meta key/values all at once from the DB for that specific post (configuration) and then uses that for reference for the rest of the page request. If you do have object caching enabled (or Pods Alternative Cache) then it will keep much of that data around from page to page to prevent additional database queries.

One thing you should really look into if you see any slowness is updating your relationship fields to use Autocomplete, or List View as your input type. Those will prevent loading large amounts of items for your relationships and are usually the number one place people see performance improvements on their forms.

You should try using a plugin like Query Monitor to see if that can help you identify what might be going on with your site on the slow pages. It will help you find slow queries, or duplicate queries, or large amounts of unexpected/unnecessary queries. It can also identify how your object cache is used and potentially tell you that it may be misconfigured and not actively being utilized (which could slow things down).

And then finally, the work involved here to change everything around for the storage is much more than $200 of dev cost unfortunately. It’s closer to 10x-15x that just to switch things over and that doesn’t even get into migration paths to get existing configs moved over.

>> One thing you should really look into if you see any slowness is updating your relationship fields to use List View as your input type.

I need it all the time, about 30% of data entering. its classic big DB structure with many dictionaries.

> And then finally, the work involved here to change everything around for the storage is much more than $200 of dev cost unfortunately.

Yes, I understand. But at this case – you will ANY WAY resolve this problem by moving CustomFieldsSettings to Pods own table someday. I just offer some donation to make it now.

Still you don’t answer about “how to update CustomFieldsSettings via files as JSON”? It will not damage existed Pods made via admin panel or lose data???

Clarify please about “Register your configurations via code”:

If I want to add many new Pods 1-by-1 via [JSON code] – suppose I must use the “Import/Export Packages” Pods function? Small clarifications:

A1) If I already create many CustomTaxonomies stored at standard WP taxonomies-terms tables (because they does not have any additional CustomFields – they does not make any mess at wp_posts & wp_postmeta tables). When I will add a new Pod via JSON to existed Pods created by backend interface, previous Pods will not be deleted/rewrite?

A2) On a new Pod ACT code importing – a new DB CustomTable will be created automatically or I must create table at DB by myself before import Pod & CustomFields settings?

A3) Still what about Updates Pods/CustomFields settings via JSON code? Your Pods plugin have functionality to find and replace Pods configs, or it will add the new configuration after old one? Any other problems/nuances with Pods/CustomFields settings updates?

A4) When admin “Register your configurations via code” – it will not save no one setting of a new Pods/CustomFields at “wp_post & wp_postmeta” tables at all? Or still store something at those tables?

A5) Can’t find detailed description of all Pods CustomFields settings. For example I want to add a Plain Numeric field displayed as slider from -5 to 5 with step 0.5 – but at documentation at your site: https://docs.pods.io/fields/number/#Settings – the exact CustomFields settings names and options is absent. Where I can find the correct names of CustomFields settings for JSON??

• This reply was modified 1 year, 8 months ago by johnynla.
• This reply was modified 1 year, 8 months ago by johnynla.

A6) If I will add a new Pod via JSON file and then go to WP Pods admin dashboard and edit some settings of this imported Pod – those additional settings will be: not saved / saved to config file / saved to standard tables “wp_posts & wp_postmeta”?

Because you don’t answer, I’ve make some test about adding a new Pods 1-by-1 via [JSON code] by my own. Here is the answers…

Possibility to “Add Pods via JSON file” have 2 completely different ways:

I) Pods dashboard function “Migrate: Import/Export Packages” – it works the same as when you’ve add Pods 1-by-1 at dashboard. When you Import [JSON code or file] via this function – you again will get excessive mess at “wp_posts” and “wp_postmeta” tables. For example when I import [48 pods, 71 groups, 273 fields] – wp database becomes as completely garbage with [392 wp_posts, 6170 wp_postmeta] only because of their settings without any data!!! Then all other Pods functionality works the same as if they were created manually at the WP dashboard. (BTW I found 1 bug there – if Pod does NOT have any CustomFields and CustomFieldsGroups as simple CustomTaxonomy – on JSON Export your plugin will add an empty CustomFieldsGroups – which must NOT be happen.)

II) Upload [JSON file] manually to website folders [your-theme/pods/pods.json] – it works completely different: it NOT make any garbage at DB which is the most important; it ADD Pods from [JSON file] to existed Pods and NOT delete any previously created Pods or data – which is also good.
But then you will face with problems:

All Pods added by manual uploading of [JSON file] to website folder:

p1) At Pods dashboard displayed in gray and does NOT have ability to edit their settings at all!!
p2) Don’t create CustomTables automatically thus you need to create those tables by your own some how, suppose the most faster way is to use phpMyAdmin tables Export/Import.
p3) Seems does NOT have the Pods Templates. You must add them manually also.
p4) Belongs not to WP or Pods itself, but to current Theme – thus when you change your current theme it will require to move all [Pods.JSON] files to your new theme and not miss one to another.

When (p2-p3-p4) are not very comfortable, still for a professional web developers is pretty easy… but (p1) is very annoying and require to keep an additional “Stage website” for any Pods and CustomFields Settings changing and for each manipulation export and import Pods.JSON again and again! Guys, really, for 2023 is like a cart on wooden wheels…

To avoid all those critical problems – you really must change Pods-CustomFields-CustomFieldsGroups Settings storing place from [wp_posts & wp_postmeta] to [Pods own DB tables] ASAP!!!

p1) At Pods dashboard displayed in gray and does NOT have ability to edit their settings at all!

Correct. Loading configuration via JSON freezes the configuration in place. Editing the schema in a test site and exporting the file via the GUI is the way to change them.

p2) Don’t create CustomTables automatically thus you need to create those tables by your own some how, suppose the most faster way is to use phpMyAdmin tables Export/Import.

It is possible to batch-export the schema without additional data for Pods-created custom tables with the following CLI command (assuming your database prefix is wp_):

mysqldump -u $(wp config get DB_USER) -p$(wp config get DB_PASSWORD) $(wp config get DB_NAME) $(wp db tables --all-tables-with-prefix "wp_pods_*" --format=csv --allow-root | sed -e 's/,/ /g') --no-data > wp-pods-schema.sql

And then import the schema once the output file wp-pods-schema.sql is copied or rsync‘d to your desired environment with:

wp db import wp-pods-schema.sql

p3) Seems does NOT have the Pods Templates. You must add them manually also.

As noted in pods/readme.txt, the schema configuration goes in the theme at pods.json or pods/pods.json. The templates go in the theme by default at pods/templates.json.

p4) Belongs not to WP or Pods itself, but to current Theme – thus when you change your current theme it will require to move all [Pods.JSON] files to your new theme and not miss one to another.

As noted in pods/readme.txt, there are functions for both registering configuration paths (for config and templates), or singular config files, if you’d like to store configuration in a plugin or elsewhere:

Custom paths can be registered to support third party plugins as well. Register new paths using pods_register_config_path( $full_directory_path ) that contain a /pods/ directory to automatically pull from or use pods_register_config_file( $full_file_path, 'json' ) to register a specific file.

pods/readme.txt

All these moves only “help to lubricate the wooden wheels of old cart”…

At 2023 such simple and important functions of your plugin must NOT work so complex and such annoyingly. ??

We understand and have plans to work on switching the database storage over. For now, this is something you’ll have to hold on for, or you are welcome to use any of the other plugins out there like ACF.

Sorry for the inconvenience here, Pods might not be the plugin for your specific needs at the moment.

• This reply was modified 1 year, 8 months ago by Scott Kingsley Clark.