Tony Diaz
Forum Replies Created
-
Posts
-
Great, that does the job. Just what I was looking for.
No clue why php just totally escaped my mind, even though I used that for the tab itself.
Thanks!
…and as best I can tell, there are shortcodes associated with custom fields?
(Therefore taking advantage of shortcodes and tabs)
So I need to use the Fieldset to group tab contents and can not display that custom field in more than one user created tab?
Fieldset A
Item 9
Item D
Item CFieldset B
Item 8
Item 7
Item 1I want Item 8 and Item D in a tab called “Details”, but both of them are in other fieldsets that may or may not have a tab already.
I want to show all the fields on “More Info” and select ones separately, in a summary form. A lessor detailed page that has something from more than one fieldset. They can select a summary view or a detailed view.
Are we saying then, that it is -not- possible to add GD custom fields to a user defined tab, selectable from a listing page?
If it’s not possible to put fields in a user defined tab, just static text then I see that ability as pretty limited.
That is what I asked and where my screenshot is from. I didn’t say anything about fieldsets which are just banners for sections of custom fields.
This reply has been marked as private.What about where Location is disabled? Some of my listings do not have addresses at all. So I added my own fields for addresses so that if there is pertinent data it will show, otherwise no, and still all be on the same CPT.
Is there a logging mechanism to see which lines are the problem ones?
I’ve imported small amounts of the same variants in my listings without any issues but when I give it 1600 or so it comes back with a lot of issues.
Okay. You win 😉
… I changed that previously when first starting out and it didn’t seem to matter. Perhaps it was WordPress voodoo. What I’m running now is from scratch 4.6 installed.
I will add though that my “argument” was based on the other threads asking a similar thing about “getting rid of” or “changing” places and the replies are all along the use the CSS to hide it, it can’t be changed, just ignore it, whatever. The actual post name type? Yeah, it would be nice but who cares. It’s not a part of what anyone has to deal with other than when importing.
As for WooCommerce, yes, it creates the Products CPT. That also is a much more general description that works as an out of the box option where as someones directory may not be actual places at all, yet it’s already been decided for you. A similar example for the directory would be “Listings” as a CPT. Fairly broad definition wise.
Yes, of course, the ‘Geo’ part standing out here, but down to the bullet coordinates are not part of everything, though I do say that yes, it helps with the map data being a -LOT- more accurate, rather than the way some things are plotted on the wrong side of the street, block, etc.
That’s not true, the only thing that you can’t change is the CPT name gd_place, that will appear when adding listings and in search strings.
Yes, and the slug. You’ve linked to a newly created CPT, but the existing slug, of which is either derived from, or used to declare the CPT name .. can not be changed. It even says so right under the line listing it.
Therefore no matter what you change all the rest of the stuff to, people, animals, binary-units, the URL is always going to have /places/ in it.
If this was a question asked when the plugin is first activated, like pretty much every other plugin that creates a needed default category/set of options/initial entry with a dialog in the dashboard area along the lines of “In order to complete your installation …please specify a title for your initial / default listing type.”. Store that in the options table and it’s there, and your inbuilt code to install demo data still works because it uses that specific option rather than the hard coded ‘places’.
They may not know exactly what the bounds of it are in the beginning, but like other plugins, the plugin and it’s settings can be un-installed, reset, whatever, and then the user has a clean slate.
A lot of people install stuff, muck around with it, get the feel, and then start over for the real deal.
Otherwise, unless the user purchases the CPT module, there is no way ever to not have -places- in the URL at the very least.
GeoDirectory seems to be the most versatile directory engine among the various WP plugins. Yes, it’s strong point is the whole map thing, but not everyone wants to use that for every directory.
Yes, it can be disabled, but you’ve still got /places.
Of course, there’s the premium module to create your own. But nothing is lost at all, and GD has way more to offer in the way of premium additions and having that title be configurable loses nothing in terms of opportunity as you get one “directory/classification item/whatever”, or if you want more, then the CPT Module is the way to go.
Burying it via CSS then results in screen re-draws at every turn in WP admin but it’s still in the GeoDirectory sidebar, in the import / export choices, etc. If it were only in the main WP sidebar, thats easy to ignore.
..and in my particular case, since it appears to be sorting by the CPT name, it’s the first entry in the import / export that I always have to change because all my CPTs are alphabetically greater than ‘p’.
Install the Custom Post Type addon, then you can change all Places default wording easily.
Except the slug.
While GeoDirectory is at the top of the crop, it’s the only one that I have found that sticks you with default classifications that you can’t delete and can only sort of ignore because you still can’t get it the heck off the admin menus.
I understand that the hardcoded demo data and such relies on consistency, though one solution could be that during activation the name (and therefore ‘slug’) of the “default” post type would be set.
Seriously. I don’t want to even see it. I have modified the live page to enable the “Delete” option on my sandbox install so it’s gone and I don’t see any ill effects. Just don’t ever attempt to use any of the demo data.
This reply has been marked as private.I wrote the same thing .. differently.
The perfect answer would be if there was another global status for posts that like trash, they don’t show up. But they’re not deleted.
(16) All (1) Draft (2) Archived (3) TrashThere’s something to be said for it being like that, in all the shenanigans I tried to make it go away, I learned quite a bit about the options / settings / etc. 😉
In my case, the source of my data is an external database that will be imported at intervals.
As a way to match fields I can place the source field name in the htmlvar. Except for the ones that are predefined.
I don’t want extra items in the config menus, and I also would like to have a consistent connection across the board so there’s no questions from anyone on my end as to what something is.
I get that I can disable them, but they still show up in the field sort order area. (I know, I know, because if they disappeared then how would you get it back again?) .. I don’t want to see any of it.
Perhaps a function that omits any listing option having anything to do with gd_place and gd_listing, and anything that is disabled for use.
Or have it use a user definable name for the initial default CPTs just like it does when you add an additional CPTs.
(I know, gd_place is hardcoded in the demo/dummy stuff.)
How about using the default CPTs extensively for dummy data / demo purposes and rather than users editing on top of them, just make it hide the default one by a selection.
Once someone makes changes to those fields, adds in more, the dummy data is irrelevant anyway, so why not have it stay the way it is for any purposes documentation and example wise that way there is a (disable-able) sandbox of sorts. No fiddling with “live” contents. There’s times when all you have is production server access.
Making them inactive is one thing. I don’t even want -see- them in the list. It’s particularly annoying that I’ve got some fields defined that I can’t change the html variable. If that could be changed, I wouldn’t care.
Perhaps I’m too anal, though I’m sure I’m not the only one.
I’m trying to keep all the nomenclature the same. I can’t if a field is pre-defined. If the custom post type is pre-defined, I’m stuck with it. Sure- I can rename it, but the table names are still going to be gd_placexxxxx
To be able to delete the default fields from the dashboard interface, it’s a matter of disabling the changing the value of ‘is_admin’. I figure that if I were to delete them, I would want to do it via the admin interface so that the same thing that it goes through the same thing that an otherwise deletable field would, rather than just dropping the record.
Point is, we may just not to even see fields, names, options, etc. that are not being used.
I will say that GeoDirectory hands down, has the others scrambling. I’ve looked at a lot of them over the last few years. But I don’t recall any others sticking me with permanent entries within a user configurable option.
I get it, they are part of the demo data, so have the dummy data thing do more than just add some records. Have it create fields for those dummy entries too. That is what happens with others. I can then rename all the attributes on those demo/dummy installed fields, categories, what ever, drop the ones I don’t want, all that.
I have a few URL fields in each record, yes, I can recycle the default entries. But again, I’m stuck with ‘twitter’, ‘facebook’ as the variable name.
So, if I never intended to use the install dummy data, could I just nuke the default custom fields? I have already experimented with clearing the ‘is_admin’ bit and deleting them through the admin interface. They go peacefully. No issues there.
Checking everything by using the GD Tools, I got no complaints, if that alone means anything.
