6) One more great idea from nerd – because Pods creates a custom DB table for data – it’s strange, why Pods don’t have any possibility for “Files/Images/Videos” “custom storing”? Instead of adding 50 images one-by-one to each “File/Image/Video” Pods field, I will definitely prefer to: a) add many files from gallery to 1 field at once; b) even better – to just choose the web-site folder from which Pods must retrieve all media files! Or select files by name or tag! It’s much easy and fast and also files can be easily added/removed!
7) One more bug – “Date-Time” field with custom date format like “March,2020” (F,Y) always display only “October 2026”.
Hi @johnynla
First, for support management, please open new topics for new (unrelated) questions. It makes it much easier for us to manage.
1) You can enable the table storage component and allow custom fields to be stored in a separate table.
2) It’s always best to plan before you build. Make sure you plan your project.
Re-arranging table fields (columns) doesn’t help anything for performance or functionality. If you really need this you can do this manually.
3) See the “Migrate Packages” component.
4) Not sure but I think your question is related to this topics:
– https://github.com/pods-framework/pods/pull/5550
– https://github.com/pods-framework/pods/issues/2314
– https://github.com/pods-framework/pods/issues/5549
A required checkbox would always need to be checked, otherwise there is no point in making it required..
5) You can make a feature request for this: https://github.com/pods-framework/pods/issues/new?assignees=&labels=Type%3A+Enhancement&template=feature_request.md&title=
Depending on user demand will might add such a field.
Alternatively you can create such functionality yourself by extending the number/slider field. As of this moment this isn’t a feature from Pods.
6a) I believe the WP media modal already supports the multiple file selection
6b) Pods uses the WP core media modal and thus doesn’t handle file uploads it self.
You can always create a feature request for this but I doubt such a feature will be added anytime soon due to other priorities for Pods.
7) Please share your field config to I can check.
Cheers, Jory
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”.
-
This reply was modified 3 years ago by johnynla.
Hi @johnynla
1) It’s a feature not many users actually use, hence we didn’t enable it by default. Though your idea to add some form of wizard for this sounds good to me. Please create a feature request on GitHub so we can look at such enhancements a.s.a.p.!
2) I work with big data on a regular basis, hence my answer.
If you really want to rearrange columns you can do so manually.
Of course we could build something like this into Pods but I’d consider it a minor improvement since it doesn’t affect performance in any way.
4) Please join the discussion on GitHub to add your thoughts on this subject. Personally I don’t get why one would set a checkbox required if a 0 is also acceptable.. this would mean the checkbox isn’t required IMO.
5) WordPress Forum regulations does not allow us to take paid projects. Please contact us personally through Slack on the Jobs channel: https://pods.io/chat/
6) I understand that you would like such a feature, it’s just not a feature of Pods at the moment.
7) First off, please use the “Date” instead of the “DateTime” field if you just need date info.
I’m assuming you’ve set F,Y
as the input format. See the help icon, it refers to the jQuery Datepicker documentation. As an example, the jQuery Datepicker equivalent for F,Y
is MM,yy
.
However, after testing the actual display of this field it seems to me there is indeed an error for this format. I’ll investigate and let you know what I find!
Cheers, Jory
Hi @johnynla
Regarding 7)
I tested this multiple times on various formats and languages. It looks like this is an issue with the jQuery Datepicker for this particular format.
Displaying the date field works fine (front-end) but editing the field in this format doesn’t seem to work well with month names.
If you have script debug enabled you can see the JS errors in your browser console.
If you set the input value to a more common format it would work for now, something like: yy-mm
(similar to Y-m
in PHP format.)
Or (even better) just use the HTML5 input, that will always work well 🙂
Cheers, Jory
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?
-
This reply was modified 3 years ago by johnynla.
UPDATE (1+2):
I’ve just check DB custom Pod table structure – it really have all original columns names from Pods (not just ID#). Good job at this aspect!
Unfortunately columns are not ordered correctly as fields at Pods fields editing form. Bad job at this aspect.
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!
-
This reply was modified 3 years ago by johnynla.
-
This reply was modified 3 years ago by johnynla.
Hi @johnynla
This is getting way to technical (and off topic) for our forum support.
Please create a feature request on GitHub so we can discuss this further and maybe get something on our todo list:
https://github.com/pods-framework/pods
Please be sure to add one topic per issue, bug report or feature request! Otherwise it’s impossible for us to manage.
Duplicate issues or issues with multiple topics will be closed.
On a personal note. While I fully understand your ideas and enthusiasm about such improvements. Keep in mind that we have a 100k+ userbase who all have their own needs. For that reason all improvements (features or optimization) will be considered accordingly.
If you really need a feature/enhancement to be pushed through a.s.a.p. I suggest you make a contribution to the project by implementing such a feature and creating a pull request on GitHub. That is how I started with Pods! 🙂
I’m marking this topic as resolved in favor of GitHub.
Cheers, Jory
As I say – I’m not a web-developer, I’m a professional experienced developer but for Win (C++,Delphi,Asm,SQL). Thus I don’t know nor WP structure, nor deep php nuances, nor how code will work at web-servers, etc. Anyway the last offered by me improvement with new table for Pods fields/sets storing – I can make for my projects at my development environment – just for 1 day! Suppose you also can make it for 3-7 days easily. So on Pods 2.8 install you can add “DB update script” which will:
a) create 1 new table for all-in-one-record like “Pod #, Pod settings, fields settings”, move all data from wp_posts+wp_postmeta to those columns as JSON.
b) create 2 new tables for fields and sets, like “Pod #, settings” and “field #, settings” and move all data from wp_posts+wp_postmeta to their “settings” columns as JSON.
c) create 2 new tables for fields and sets, like “Pod #, individual column for each settings” and “field #, individual column for each settings” and move all data from wp_posts+wp_postmeta to their new individual columns as clear text/numbers.
For best accessibility and data clearance I would recommend method (c).
But will be nice to know will your team implement it or not, because what now Pods creates at wp_posts and wp_postmeta – is a real garbage. If you don’t want to make very important improvement (which honestly should have been done from the Pods project start) – I prefer much more accurate data storing at JetEngine.