Advanced Content Type with custom fields
-
Hello, some questions from a nerd.
Your Pods with custom fields and tables are really very good! It’s 95% the same good as how would I make it. But still have some questions-shortcomings. I search at internet but don’t find the exact answers to my questions. Maybe it will be the “new feature requests”, I’m not sure. Please, help to find the way to implement them with Pods:
1) Very banality situation when admin want to extend his shop special professional products info by Pods fields&data. But because of too much data I prefer to store it at new custom simple fast-accessible DB table. Seems Pods persist to such using without any logical reason – you or can extend existed Posts types but with data storing as garbage which is normal for WP area, or to store data at clear custom table you must only create your own post type with “Advanced Content Type”. What a reason for a such limitation? Why it’s impossible to add to exited post type a new table with some custom fields&data?
2) Table on-click rebuild. When you create a new Pod with many fields it’s often impossible to arrange all of them ideally from the beginning, mostly you will re-arrange fields many times before you will get the ideal fields order and structure. But on Pod saving (even without data at this Pod) – all fields number stay the same from when they was added. For example even when lastly added field will be placed at position #10 of fields list, it still will have the last ID:150. For ideal conformity will be nice to have button “re-arrange fields ID with current order” which will re-set fields ID’s (maybe exclude first ID field) and re-build DB table structure to the same order! It will be just more comfort to work with such DB table directly, to not search and scroll for ID’s from start to end.
3) Pod Export – I still can’t find how to easily export created Pod? Not data from Pod! But Pod itself with all fields and fields settings??? When you have 150 fields with detailed description, many authorizations, fields custom tune, etc – it’s VERY IMPORTANT to have possibility to make backup of a such hard work! How make a Pod structure backup??? (WP-Tools-Export don’t work with Pods “Advanced Content Type”.)
4) SQL “boolean” store data as 0/1. Thus if I use at Pods the “Yes/No” field, choose “Checkbox” style (which often are the most comfortable), set this field as Required, and preset default value to 0 – in terms of SQL DB it must work properly – if checkbox are not set – value will be not empty but 0. But it don’t work. Need to be fixed. Or add some new UI style like: “green V for Yes”, “red X for no” at one box – which must easily works with 0/1.
5) Will be very nice to have the “5-stars rating” field which can be set with ANY range numbers and will automatically recalculate them in to classic “0-5 stars” with partial stars displaying. Maybe also with option to display or not overall rating number before/after stars. Or maybe you know how to make it based on “Number field” or “Relationship – Simple custom list with values”? Or what is the best way to add a “field custom UI displaying php/html code for frontend” to some fields?
Best regards, your Pods are really very good project especially for simplified WP area.
-
Hi,
Thanks for answers, but pity that all of them are nor very useful. Some clarifications…
1) OK, I see. Thus will be better to have ability to turnOn “tables storing” from the main “New Pod creating” dialog with 2 variants. For now turonOn this additional component are too deeply hidden.
2) Seems you never work with really big data (not in terms of rows, but in terms of columns-fields number). When you have actively developing project with some data which require >30 fields – you will ALWAYS after some time add more and more fields and for better structure will re-arrange them. Also it seems your custom DB tables naming columns only by field-number-ID, those on data export-import with 100-150 columns with similar data it can be extremely hard to know where is which data field. Thus DB table re-arranging or full re-build can be very useful!
4) If your Checkbox does not get 0 as default value (which is correct for SQL) – then remove “default value” for checkbox’es at all or add some warning etc.
5) Can you make it for me personally or at near Pods update for some fee?
6) It’s just logical to have with CUSTOM DATA STORING SW, also possibility for the CUSTOM MEDIA STORING.
7) Already tell. “Date-Time” field with custom date format like “March,2020” (F,Y) on new date entering always display only “October,2026”.
2) Big data have always 3 most important aspects:
a) Store data at DB most compact as possible;
b) Store data at DB as native (data type) as possible;
c) Store data at DB best organized as possible;
d) Optimize data search/indexing as possible.
Your Pods are really great update for idiotic WP manner to store all different data at 2 tables which makes a garbage. But still your Pods does not control (c) – first of all the database columns organization. Possibility to re-arrange columns at DB is only half of this. The second important part – is to not use the “Pods DB template fields ID”, but control the [Pods fields] with [DB columns] synchronously by NAMEs.
You definitely must think about it.2+4) It’s the classic “web developers logic” – most of you thinking by web interfaces. But very few of you thinking about data storing correctly – from the project basis – starting from database. In terms of working with data and a specially big-data – data is the most important, data have the first priority, only than all other things and interfaces. First of all right developing needs to make all data storing correctly. Than based on DB rules add interfaces. At such right for corporate/banks/big-data/etc SW logic – Boolean DB field can have value: “empty/0/1”. But if admin needs to make field “not empty” anyway, he can do it at DB with many possibilities as: set DEFAULT, set Not null, etc – all works correctly! But at WP-Pods interface your Checkbox destroy and ignore all those DB rules&possibilities – even with “Required” option and “Default value = 0” – your Checkbox does not save 0 to DB. Thus your “Pods web-interface Checkbox field” at such conditions violate of the “more important DB Boolean field rules”. There is no doubts and no any room for discussions. If you still not sure, you can try Microsoft Visual Studio C++ and it’s component Checkbox – it’s a standard. So your must resolve this problem at Pods ANYWAY – or by adding possibility to Checkbox to store 0 to DB if it not checked but “Default value = 0”, or to control Default fields-columns values directly as DB COLUMN DEFAULT values.
5-6) OK.
7) Yes, I use “Date” field. Your Pods fields editing interface have a very useful hints but the first such hint is for “Date format for display” leads to “PHP date documentation” – thus I use it. I just far from web-php-JS-etc thus I just don’t know that input date format have another format than displaying format, which for desktop SW is a nonsense. Thanks, will try.
BTW which improvements “HTML5 input” can bring to another fields? Is it possible to turnOn/Off “HTML5 input” for ALL fields at one Pods? (It’s again seems that Pods developers are not familiar with big-data with 100-200-300 columns at once, which turnOn/Off one-by-one is too time-wasting.)
8) One more very important thing is to add to your “Pods knowledge base” info about your field “Relashionship – Simple (custom definition list)”: about values and data storing; which editing methods it support as: text values changing, numeric values changing, text values without numeric values re-arranging; does it add numeric values automatically or not; etc?
But then I think… if you directly naming DB columns, for what reason you still use unneeded Pods CustomFields ID#???
Then I open wp_posts table… and get stunned… you create at wp_posts (the most garbage DB table) records for EACH CustomField Description… Why??? Description is the simple 255 chars text, it must NOT be stored as wp_posts with all unneeded columns! Only to make the next garbage???…
And then I’ve open the “wp_postmeta” table… where I found over 22’000 records of your pods custom fields!!! 22’000 records for 150 custom fields!!! What a reason???
Why you just don’t create your own table like “wp_podspods/wp_podssets/etc to store each Pod settings into it??? (Later I try JetEngine and found the absolutely correct DB structure – 1 standalone table for each CCT/ACT set. Just 1 record instead of Pods 150 records at wp_posts and 22’000 at wp_postmeta!)
Does your team understand the conception of “DB CUSTOM TABLE” means DON’T USE DEFAULT tables?!
You really need to fix it! Just make your own standalone table!
Move all data from old locations as wp_posts and wp_postsmeta to your new 1 table – is very simple and can be done by just 1 SQL procedure!
DB CustomTable storing method and overall DB optimization – are really needs it!
You really must make it!
- The topic ‘Advanced Content Type with custom fields’ is closed to new replies.
