This is a community support forum where you can ask questions and interact with other PremiumPress Customers.
Assuming that I create say 50 custom fields for a listing and yes this could be extreme, and not really wanting to get in to why wp works the way it does…. some things just don’t make sense especially on the number of db querries that need to be made to get a listing.
Mark I know this concept will probably have you either laffing, ripping your hair out or saying hmmmm interesting idea.
Here we go:
create a new table call it say – listings
in the listings table you maintain all of the data regarding a particular listing, including all custom fields.
When creating a custom field it would be created in the listing table not as a reference in wp_post_meta
All the fields would be in this listing table as such db query would be much faster and you could key certain fields to speed things up.
You would then only reference the listing ID to a Post ID.
The reason for this concept is that trying to upload hundreds or even tens of thounds of listings is impossible, also your not having to deal with linkins in other tables w_term_relationships, w_term_taxonomy etc.
Tell me i’m crazy but a new table with all the data for a listing record is a simple import and 1 query, unlike how wp now handles things, if you have 50 custom fields plus what you have hard coded now a single listing can take 70 or more rows of data.
One more thought…..
or have it so that all of the custom fields are in a new table and the data is pulled from the new table based on the post id.
so as a 2 step process – you have the current csv inport export and you would then have a secondary import export in the listing table.
hope this makes sense …
Anyone have any thoughts on this?
not sure what sort of responsive you would want WP is the core system of which i didnt develop, in the old framework i tried to go against the grain and it caused alot of plugin issues moving forward, so now..i just ‘go with the flow’.
Any ideas or solutions to easily add records to the db when using multiple custom fields?
Gerry, before trying to add many custom fields, I would look into other options. Could you use custom taxonomies or custom post types instead?
couldnt u have 1 field and store all 50 options in an array?
The big issue that I see is with importing of data. Sure you can have as many CF but as the are stored as individual rows in an other table it is then about having to hit the table and go through all the rows, should you have 20,000 listings with say 50 custom fields thats 1 million rows to go through.
I think if there was a way to add custom fields to a table and then reference the data from the custom fields table based on either post ID or listing ID this could be the answer.
Also import and export of the data would be a zillion times easier.
This would then mean that all custom fields would be written to a new table and not added to w_term_relationships, w_term_taxonomy etc.
Call me crazy but this just makes total sense.
But that could only work if the custom fields were ‘static’ or ‘predefined’ it would not work well if you need to be able to create / remove the fields frequently.
And as Mark has said, if you store the information in array – you get just one line
The array concept I think is a great idea…. but it will then be a matter of recoding things on CF?
I’ll call you later today and we can have a chat about this as you know the code so well.
sniff sniff… do I smell a custom job here