0

I currently have a webside called storelocator.no.
Here you can search for a brand, and you can see what stores sells this brand.
Clicking a store, you will see what brands this store has.

Currently I am using custom database for this.

But now that WP has custom post types, I'm considering if I should create a custom post type for a store and one custom post type for a brand.

I still have to make the connection between store and brand -> A store can have many brands, a brand can be in many stores.

I also have to connect certain users up to a store or brand (store owner or brand owner), så that they can maintain infromation.

Normal users can also sign up, so that they can add extra stores / labels into the system.

Currently I have over 7.000 brands registered, and I will in due time have mane stores in the system.

My questions is this:

Should I stick to custom tables? Or should I take advantage of WP Custom post types? Would the site be slower using custom post types if I have several thousands entries?

Oh, another thing. A user is never backend in WP to register data., Everything is done from front end.

4
  • 1
    If you have an existing system, why do you consider to switch to wordpress? - Just to better understand your needs.
    – hakre
    Commented Nov 18, 2010 at 1:56
  • @hakre: I am already using WP. I'm just using custom tables at the moment. One of my current problems is getting friendly URL's: wordpress.stackexchange.com/questions/3537/…
    – Steven
    Commented Nov 19, 2010 at 7:34
  • 1
    Okay, now that's some direction. Are you aware of the RewriteAPI? codex.wordpress.org/Rewrite_API
    – hakre
    Commented Nov 19, 2010 at 11:05
  • No I wasn't. This looks exactly whatI'm after when it comes to friendly URL's. Thanks for that. When it comes ot associate a store with a brand through a link table, I don't think custom post types will be the right way to go.
    – Steven
    Commented Nov 20, 2010 at 10:29

3 Answers 3

2

I'll go with hakre's solution using RewriteAPI. I did not know it existed and it looks like it is what I need.

1

That is an interesting question, there is the Pods CMS plugin which does allow relationships between items, they call the relationships PICK columns. This is a fairly well supported and widely used plugin, the downside for me is that it uses the nicEdit HTML editor instead of the standard WordPress TinyMCE editor. So you don't get the full WordPress post functionality out of the box although you can code your way around it. The ideal solution would be to have a combination of both custom posts and Pods CMS Framework then you could say that WP is well on it's way to being a full-blown CMS. THe other thing to note is that Pods CMS does create it's own tables so that is a useful feature.

0

Personally, I wouldn't.

I can't see a way of doing the many-many relationship you're after via custom post types - there's no easy way (that my very limited knowledge knows about) of establishing that kind of relationship between custom post types.

You'd have to use a custom taxonomy (brands) and have a shop and brand custom post type. Each shop post would tagged with the brands taxonomy terms that are relevant, and so would each brand post (this would give you the linkage, and also allow you to have a page per brand with content.

Of course, smarter heads may have a different take, but I don't see this as being worthwhile.

2
  • If I only used brand name, I could use custom taxonomy. But brand name is registered with adress, contact details and so on.
    – Steven
    Commented Nov 19, 2010 at 7:36
  • exactly - that's why you would need brand to be a custom post type as well, and then you'd have to have brand as a custom taxonomy as well to link brand CPT to shop CPT. This is why I don't think it's worthwhile.
    – anu
    Commented Nov 19, 2010 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.