Issue 564 in wp-e-commerce: Template hierarchy re-implemented unnecessarily
wp-e-c...@googlecode.com
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-Themes Milestone-3.9
Version-3.8
New issue 564 by leewilli...@gmail.com: Template hierarchy re-implemented
unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
See also #563.
wpsc_all_products_on_page() in wpsc-includes/theme.functions.php
essentially hijacks template_redirect, and re-implements a
template_hierarchy for WPEC rather than WordPress just doing the right
thing. This should be unneccessary, and leads to bugs (Such as #563).
This bug is to clean up how this works.
wp-e-c...@googlecode.com
Comment #1 on issue 564 by gary...@garyc40.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
Should we do away with the [productspage] shortcode and the pages
altogether? These shortcodes are there just to determine the slug of the
store pages, and it can also potentially mess up the $wp_query object. And
I dislike having to query the post_content to look for the shortcode so
that we can determine the URI of the product pages (although we're already
caching it in a transient or option).
Instead perhaps we'll just have a section in Settings -> Store that allows
the user to choose the slug they want. Then we can just rely on the
WP_Rewrite rules to do the magic.
We should also let the user determine the permalink structure of the custom
taxonomies as well.
Dan Milward
How does the new bbPress do it?
I'd like to hear what everybody else thinks.
Best,
Dan
Sent from my iPhone
Jeffry Ghazally
wp-e-c...@googlecode.com
Comment #2 on issue 564 by jghaza...@screamingcodemonkey.com: Template
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
Hi thought'd Id pipe in and give my 2 cents,
I like the idea of using default WP template redirects etc, however we
painted ourselves into a nice little corner, as this relates to the whole
the_content, / lack of CPT template flexibility which we talked long and
hard about previously..
so.. if we get rid of the shortcode, and use default WP behaviour, id love
to see it :) two issues I see are:
1. How do we make a template that can cater for a majority of themes out
there, I know we dont cater for 100% but show me a CPT that does a better
job out of the box.
2. How do we make it backwards compatible? This is probably easier to
figure out once we have #1 sorted.
While developing 3.8 our main goal was to make it backwards compatible as
much as possible. our secondary goal was to make it work for majority of
themes out there, if we decide to make a new template that works with the
WordPress template redirect then we move back into the grounds of lee's
post on how CPT theming is borked.
Sorry, this might not be the case, and I may be totally off the topic, Im a
little rusty ;)
wp-e-c...@googlecode.com
Comment #3 on issue 564 by leewilli...@gmail.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
@garyc40 - yes, ideally we should. Ideally we'd let people choose the
following permalinks:
Category taxonomy slug
Brand taxonomy slug
Checkout page
My account page
Transaction results
I take Jeff's point about the template hierarchy (I think) - but it should
be a design goal. Re-implementing this stuff ourselves is looking very
prone to errors. I'd be curious how the other CPT-based stores do it
(MarketPress for example).
wp-e-c...@googlecode.com
Comment #4 on issue 564 by gary...@garyc40.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
Hi,
Jeff's points are all valid. There are other problems that we need to focus
on for 3.9, so I don't think a big change in our template hierarchy would
fit, not even for 3.10 or 3.11 . But 4.0, maybe.
Regarding Jeff's 1st point about templates that are compatible with most
themes out there, here's a really really crazy idea I have. I need all of
your feedback on this.
Instead of wpec as a plugin, why not think of it as a bundle, which comes
with our existing core plugin, and a dedicated theme. This theme has all
the template hierarchy that the user needs to customize the output of the
store. All the user has to do is to create a child theme of that, and just
edit it. I remember a discussion somewhere I had with Andrew Nacin (core WP
committer) about creating a Bug Tracker that utilizes CPT. He said that it
would probably be best to implement it as a bundle of theme and plugin (or
something like that).
The advantage of this, is people will have a solid foundation to build
their store. Currently we have a system of templates that are injected into
the page content. While it works out of the box for many themes, lots of
people are still complaining that it's not working for them. And I can't
count how many stores that are broken because they didn't flush their theme
cache and replace their old templates with our new ones after they upgrade
to 3.8.x . But of course if they do this, their customizations are gone. Or
if they're a little bit more patient, they have to manually fix their own
custom templates.
We can solve all these problems if we have a dedicated theme for the plugin
which people can build upon. Of course this means that existing WordPress
sites that already have a theme would not work with wpec out of the box.
But in reality, most people who install WPEC, they do it from scratch, and
develop a new theme to work with the plugin. So I would say more people
will be happy about this change than upset because of it.
To me, this looks like the most sane solution to all this template madness.
But as I said, we can probably save it for 4.0, which I expect to be a
really major release.
Ideas and thoughts about this are welcomed.
wp-e-c...@googlecode.com
Comment #5 on issue 564 by jghaza...@screamingcodemonkey.com: Template
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
cool so Im not crazy ;)
the idea of making it a bundle is a good one, we did discuss this a while
back, as this follow suit with the BuddyPress system.. however bth dan and
I were hesitant as we do have a few 100, 000 users that are currently happy
with the setup they have and breaking it for a release would be a quick way
to loose users.. this is why we have the madness of templates currently..
If we want to move to this new system then yea I think waiting till 4.0
would be a great idea..
on a side note are we really going to release a 3.10? I've never seen such
a release version before.. I thought we would just from 3.9 to 4.0...
maybe what we need is to think about the system we have a little more.. its
naming conventions are probably a bit confusing.. wpsc-Products_page.php is
wpsc-products-content.php as it is the content replacement
and single product view has single-wpsc-product.php and
single-wpsc-product-content.. does this make sense? just got given a few
free beers so am a little off 'trac'
wp-e-c...@googlecode.com
Comment #6 on issue 564 by gary...@garyc40.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
> I've never seen such a release version before.. I thought we would just
> from 3.9 to 4.0...
I don't think there's a rule about this :) In my opinion, the version
scheme should be something like this:
major.minor.maintenance
Looking back, 3.8 should have been 4.0 in its own right, since it signifies
a major change of the plugin's architecture. If so, our 3.8.3 would now be
4.0.3 .
We can go all the way to 3.50 if we like, as I don't think there's a rule
about this :) 4.0 should be an ambitious upgrade from what we have, so it's
probably a year or more from now.
I didn't really follow the development of BuddyPress, but I just took a
look their plugin + theme bundle, and it's exactly how I want wpec to be in
4.0! Imagine how awesome it would be to activate the bundle and then you
can forget about making it look pretty, because it already would be.
I agree about the naming convention issue with current templates. Fixing it
would also require some maneuver to ensure back compat. Or better, to avoid
confusion with the other templates, put them all in a separate folder in
the user's theme. Anyways, this should probably be spinned off into a
separate ticket.
wp-e-c...@googlecode.com
Comment #7 on issue 564 by leewilli...@gmail.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
For reference MarketPress now has a parent theme, and a sample child theme
available to use (With more in the works apparently)
wp-e-c...@googlecode.com
Comment #8 on issue 564 by gary...@garyc40.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
Thanks, Lee, for the update about MarketPress.
After spending more time thinking about this and read the discussion on
Lee's blog post
(http://www.leewillis.co.uk/wordpress-custom-post-type-theming-is-broken/),
I have to agree with the WP core developers that a plugin shouldn't take
over a theme's responsibility.
After 3.8.4, when Lee's patch for product tag template hierarchy is
committed, we already have a solid template hierarchy in place to start
building some kind of theme, and recommending people to begin using it for
new stores.
So if we have a concensus on this, we can implement some sort of transition
phase in 3.9 (and 3.10). For themes that want to use WP template hierarchy,
they can add_theme_support( 'wpsc_template_hierarchy' ). Then in our
plugin, we check get_theme_support( 'wpsc_template_hierarchy' ). If the
theme supports that feature, then we can skip the whole custom $wpsc_query
and our custom wpsc_theme templates, and rely on the theme totally.
Otherwise, we can fall back on the current way of doing things (filtering
the_content).
Then in 4.0, we can start deprecating the use of custom wpsc_theme template
and shortcodes (but perhaps still provide support just for back compat
sake, although this can be messy). It's a big change, but in the right
direction. And if we have a couple of minor transition releases (3.9, 3.10,
or even 3.11) then people will get used to it and start developing wpec
theme the right way.
wp-e-c...@googlecode.com
Labels: -Milestone-3.9.future Milestone-3.9
Comment #10 on issue 564 by g...@instinct.co.nz: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
(No comment was entered for this change.)
wp-e-c...@googlecode.com
Comment #11 on issue 564 by yitw...@gmail.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
Please change add_action('template_redirect', 'wpsc_all_products_on_page');
in theme.functions.php to
add_action('template_redirect', 'wpsc_all_products_on_page', 11);
This way, it won't break any themes or plugins that add a template_redirect
action with the default 10 priority.
thank you.
wp-e-c...@googlecode.com
Comment #12 on issue 564 by tran...@1bigidea.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
More to comment 11 - in the meantime, since WPEC hijacks the
template_redirect, we need to ensure that it runs dead-last. Themes like
thematic hook sidebars to template_redirect (it is a popular hook)
The attached patch merely moves the wpec hook to position 99999 - which is
likely to be well after anything else.
Attachments:
template-redirect.diff 470 bytes
wp-e-c...@googlecode.com
Comment #13 on issue 564 by gary...@garyc40.com: Template hierarchy
re-implemented unnecessarily
http://code.google.com/p/wp-e-commerce/issues/detail?id=564
Hi,
I attempted moving the hook to lower priority, but that didn't work for
some reason the last time I tried. Some testing needs to be done, so I'm
moving this issue to 3.8.8.
On a side note, I've been having conversations with a few premium themes
developers. I disagree with their approach of hooking
into 'template_redirect'. Some of them said that they need to hook
into 'template_redirect' because it's the earliest hook that you can
do "is_home(), is_single(), is_page() etc.". That is not correct. The
earliest hook (and I'd argue that the correct hook in 99% cases)
is 'wp'. 'template_redirect' should be used for, as the name of the hook
suggests, template redirection. All the other stuff that needs to be done
before the template is rendered should be hooked into 'wp' instead.