You are not logged in.
all right kids, here’s the sitch:
i have a movie review section on my site, called ‘movies.’ right now, the index page is sorted by rating (which i have organized as categories named 5 stars, 4 stars, etc).
ideally, i’d like the main index to display a list of articles by date, and options to view by rating or by title, as in each view would be on a separate page (it’d be cool if the URLs could be something like intensify.org/movies/, intensify.org/movies/byrating, intensify.org/movies/bytitle, but i don’t know if that’s feasible since the ‘folders’ sections in TXP are actually just placeholders and not folders).
i don’t know how to do this, because TXP won’t let me have three different indexes for one section.
also (and this is secondary to the above), if i REALLY want to be fancy, i’d like to have something like this for the ‘view by rating’ page:
5 stars (link to 5 star reviews)
4 stars (link to 4 star reviews)
3 stars (link to 3 star reviews)
…and so on
Have a look at the “rss_suparchive”:http://forum.textpattern.com/viewtopic.php?id=4647 plug-in. It will do archives by date and category.
stuart, i considered rss_suparchive (i use it for my main archive), but i don’t know how to make it do what i want it to without creating more sections, i.e. ‘moviesbydate’ and ‘moviesbytitle’, since i can only create one index page per section.
you could use article_custom
That will list you articles independent of where you happen to be and then sortby=“title” or “posted”. The more you play with it the more versatile you will find it.
yeah, article_custom would work… but how would i get each view (title, posted, category) to be on a separate page? i tried just putting the code in an entry, but it didn’t output anything.
My quick’n‘dirty solution to this problem looks like this:
1) make a new document for each list form e.g. an article with title “bytitle” and then use a custom field named “viewtype” to designate the viewtype. In this case fill it with “bytitle”. You can put text in the body if you want.
In the page template then:
<txp:article form=“movie_views” limit=“999” />
the form “movie_views” would look something like this:
<txp:if_custom_field name=“viewtype” val=“bytitle”>
<txp:article_custom section=“movies” sortby=“title” sortdir=“asc” form=“movie_infos” limit=“999” /></txp:if_custom_field>
<txp:if_custom_field name=“viewtype” val=“bydate”>
<txp:article_custom section=“movies” sortby=“posted” sortdir=“asc” form=“movie_infos” limit=“999” /></txp:if_custom_field>
<txp:if_custom_field name=“viewtype” val=“byrating”>
(your rss_suparchive here)</txp:if_custom_field></code>
Or something along those lines. It needs the custom field to detect what to do. The article is just a placeholder for that, though you can have a different intro text to each page if you want. It also gets you halfway to your desired url structure.
Something else occurred to me just now: The textpattern.org rss-feed just proclaimed a new plug-in called chs_ifurlvar which detects variables in the URL in the address bar and allows you to output the page differently depending upon those. I can’t find a thread on it here, nor on the author site and have only just read the entry on textpattern.org so have not yet installed it to read the help.
But, if it works like I think it does, you could set up a link “list by title” to link to an URL something like <code>/movies?bytitle</code>, then use the plug-in to output your list using article_custom if “bytitle” is in the URL. If the plug-in works that way, you can do that with one page template and different conditionals (if urlvar=“bytitle” output this way, if urlvar=“byrating” output that way…) without the need for dummy articles or custom fields.
Let us know what you decide to do.
Last edited by jakob (2005-10-02 08:32:13)
excellent! chs_if_urlvar (note the different URL) did the trick, jakob. here’s the code i used (code for article lists replaced by description of output, for clarity):
<txp:chs_urlvar_default var="view">MOVIES BY DATE ADDED (default)</txp:chs_urlvar_default>
<txp:chs_if_urlvar var="view" value="rating">MOVIES BY RATING</txp:chs_if_urlvar>
<txp:chs_if_urlvar var="view" value="title">MOVIES BY TITLE</txp:chs_if_urlvar>
so when the URL is http://intensify.org/movies/, MOVIES BY DATE ADDED shows up (well, theoretically – i’ve only just tested it and have yet to implement it, but it works. i’ll post a link once it’s actually up and running). when the URL is http://intensify.org/movies/?view=rating, MOVIES BY RATING shows up. and so on and so forth (it appears you can set as many variables as you want, which rocks).
very cool; this is exactly what i wanted. thanks for all the help!
oh, lil’ question about semantics – is the ‘correct’ syntax
www.url.com/folder?var=value<br /> or <br />www.url.com/folder/?var=value
?? (both output the same thing, but i’m just wondering ‘cause i’m weird like that)
edit: the difference is whether or not there’s a slash after the folder…
Last edited by Rachel Rachel (2005-10-06 04:00:34)
Obviously, either one works. It’s not so much a question of semantics as it is one of efficiency. The way the mod_rewrite rules work, the query string is handled independently from the rest of the URL. So we’re just concerned about what comes before the ?. If memory serves correctly, Apache will handle both situations, but the version with the trailing slash will be more efficient, because without the trailing slash, Apache will look for a file named “folder” first, then when that fails, look for a directory named “folder” before deciding the request is invalid. Since the rewrite rules say “don’t rewrite if the request is for an existing file or directory”, the example without the trailing slash will perform two existence checks as opposed to one check in the case of the trailing slash.
Probably more of an explanation than you wanted, but hey, you asked :)
And then my dog ate my badger, and the love was lost.
excellent. Glad it worked and thanks for trying it out. I can imagine lots of scenarios where this could be very useful. There’s probably quite some potential to this little-known plug-in.