TOPIC:

Hi jojo12, also in my opinion at the moment this is the only solution.
Create a category for each city and then manage the menu items for each of them. Hopefully in future updates because the function is very important

Hi AchLive,
For an hour or 2 I traveled the same path with categories.
I was using the method to assign attributes to venues. Same difference though.

I simply split the core categories functions in 2. 1-1000 (or whatever) was for normal core function, 1001 (or whatever) was for my new venue stuff.

Doing so provided a way to keep things on their own paths.
I posted about this not long ago. I ended up going a different route simply because my list of core mods was becoming unmanageable and scary to follow. Besides, it was not a very eloquent hack.

My ultimate solution has been to run a parallel solution just outside of JEM that is portable across upgrades. A real pain and quite a bit of work though.

At any rate, I think I still have notes on my hacks if it will help. Not much really, just some logic inserted here and there in a few filles.

Happened on this. Haven't tried it, but it seems to simplify some of things that might otherwise be difficult for us non-programmers. May finish up my venue categories project with it among other things. Oh, and it's free.

fabrikar.com/help/tutorials/details/3/18-existing-tables

mrgreg wrote: I simply split the core categories functions in 2. 1-1000 (or whatever) was for normal core function, 1001 (or whatever) was for my new venue stuff.

Hi Greg,

because the id is a primary key and auto-increment (which means handled by the DBMS itself) I can't recommend this way.
Additional to this more theoretical potential conflict (nearly nobody needs to create more than thousand categories) you have to know if and where this id wil be used as reference. For example when having full ACL support for categories it could be that if you create a new category in backend automatically an additional record is added to assets table using this original id. This could result in strange effects hard to find if you only change the id in jem_categories table.

I agree. It was a nutty idea in its implementation and carried out on a whim. However 'split in half' probably was a poor choice of words.
But if one were to create a bunch dummy categories (a reservation pool) one could simply unpublish them and then re-work them as need. Anything added after could then be considered <some new use> and dealt with using some logic. "Show this range as normal categories, show this range as <some new use>".
Still fraught with traps- but mostly just harmless ones however requiring many logic changes in the code where they might pop up.

After playing with Fabrik a bit last night it is clearly a tool for the non programer that can greatly extend the presentation potential for JEM without having to bother developers, hack at core files, or come up with some other crazy idea
With 4 little lines of code on the core I have already seamlessly embed a full extended form (component in a component) in the JEM front end admin (with proper ACL) and access to my new tables- jem_cust_venue_categories and jem_cust_cats_venue_relations.

Venue categories for me. WhooHoo!