Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Improvements to Content Control
driz wrote:
Well that would require the knowledge of HTML and the workings of TXP. Clients would need to be able to create static pages like articles.
Driz, your original post never mentioned anything about clients doing this.
Keith
Blyth, Northumberland, England
Capture The Moment
Offline
Re: Improvements to Content Control
jakob wrote:
What I do is create an
/about/section and an/aboutarticle but never present a sublink to the individual article view, e.g. the page template shows the full article (form including body) with limit = 1 in both article list and individual article view. Theoretically the individual article view will never be seen as there is no link to it (one could leave out individual article view entirely but see below*). While not perfect in terms of internal workings (admin-side effort), it does at least presents a clean link to the world and is easy for the client to find and edit.There are two caveats: the
/about/aboutlink is revealed in the google sitemap and possibly the rss feed too. I don’t really ever offer an rss feed for the about area so that’s not really a problem. Thankfully rah_sitemap allows you to exclude certain sections as well as to include custom urls, so I exclude that section and enter the url I want to use in the custom section and all is well. *If I’m not mistaken, the only other time one needs a single article view is if an editor clicks the “view” link from the backend.
This is very similar to my process, but I have a couple other conventions that clear away most of the problems you talked about— here’s one, in simplified form (it can be slightly different for each site):
<txp:if_individual_article>
<txp:wet_if_sticky>
<!-- Get out of here. -->
<meta name="robots" content="noindex, nofollow"/>
<meta http-equiv="refresh" content="0; url=<txp:site_url/><txp:section/>/"/>
<!-- Really. Get out of here. -->
<script type="text/javascript">
/* <![CDATA[ */
window.top.location = '<txp:site_url/><txp:section/>/';
/* ]]> */
</script>
</txp:wet_if_sticky>
</txp:if_individual_article>Last edited by johnstephens (2009-08-05 19:45:34)
Offline
Re: Improvements to Content Control
This is when/where the status="hidden" would have come in handy. I’ve to dive into Textpattern forums archives, but this topic has come already a few times.
Setting the status as “hidden” could have been useful to avoid the /about/about issue. Then, yes, the article is “hidden”, but with the powers of Textpattern tags it would have been easy to retrieve it (using <txp:article_custom id="XX" />), so to force it to “unhide”.
Then, I think I’ve suggested this somewhere: a new category type for forms: “snippet”. Forms categorized as “snippets” will be automagically listed on a new “Content -> Snippets” tab.
Thus, your clients will be able to access there and edit those snippets forms.
This “snippet” type of form would be/work as just any other type of form.
Your client will be able to just write plain text, HTML, or if he is brave enough, even fiddle with some Textpattern tags (nothing he couldn’t do directly on an article…).
To overcome the “No textile” issue that Neko pointed above… you just simple wrap the form (on the place where it’s called, usually a page template or another form) with <txp:upm_textile />.
So, summarizing, “snippets” could be simple chunks of contents that doesn’t fit as articles but that client should have the “power” to easily edit them.
adi_variables may be the first step on that direction…
Offline
Re: Improvements to Content Control
@Neko Thanks :D What was it that I suggested that was so bad?
@Keith I didn’t mention the client b4 because it doesn’t really matter if their is a client or not, even for someone who works in the web industry and sees PHP in their sleep still would look at the current system and frown at the inefficient system in place for static pages.
@maniqui Adding snippets in the Content area sounds like an awesome idea, but im not sure about the name ‘Snippets’ as it gives the impression that its a block of content like a header etc. More other it should have a name that clearly states its more “Static Page”
~ Cameron
Offline
Re: Improvements to Content Control
driz wrote:
Adding snippets in the Content area sounds like an awesome idea, but im not sure about the name ‘Snippets’ as it gives the impression that its a block of content like a header etc. More other it should have a name that clearly states its more “Static Page”
Why limit it to Static Pages? It very well could be part of a header or footer allowing the client to edit that text.
I think I remember seeing this idea before and I like it. It seems this should be popular in a plugin.
Piwik Dashboard, Google Analytics Dashboard, Minibar, Article Image Colorpicker, Admin Datepicker, Admin Google Map, Admin Colorpicker
Offline
Re: Improvements to Content Control
MattD wrote:
Why limit it to Static Pages? It very well could be part of a header or footer allowing the client to edit that text.
I think I remember seeing this idea before and I like it. It seems this should be popular in a plugin.
If you was to edit text that was part of a header that would be a snippet! I’m meaning a whole page that is classed as a page, rather than a snip of text that is added to a part of page like a snippet would.
~ Cameron
Offline
Re: Improvements to Content Control
Maybe “Static Content” instead of “Static Page”
Piwik Dashboard, Google Analytics Dashboard, Minibar, Article Image Colorpicker, Admin Datepicker, Admin Google Map, Admin Colorpicker
Offline
Re: Improvements to Content Control
This is very similar to my process, but I have a couple other conventions that clear away most of the problems you talked about— here’s one, in simplified form (it can be slightly different for each site):
Setting the status as “hidden” could have been useful to avoid the /about/about issue. Then, yes, the article is “hidden”, but with the powers of Textpattern tags it would have been easy to retrieve it (using <txp:article_custom id=“XX” />), so to force it to “unhide”.
Both good ideas. I sometimes use the status="hidden" principle when I have a section with lots of articles that needs an author-editable intro text. Works very well. I hadn’t thought of using it as you suggest.
Regarding google, you can set rel=“canonical” to just the section too to avoid duplicate urls.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Improvements to Content Control
Having just begun a site in Wordpress, I can say that its handling of pages (static informaion) is decidedly inferior. The great thing about everything being an article (or a form, for that matter) is that it is entirely reusable. All I wanted to do was take my static “About the Author” information and put a snippet of it on every page – in Wordpress this was really complicated. In TXP it’s a cinch!
Offline
Re: Improvements to Content Control
I don’t follow? In WP that info could easily be put in a textbox (custom theme functions) and then displayed on your pages. In TXP you would either have to create an article or a form and then manually add it to each page you want to display it. So its the same, except in WP anybody could do it, where as in TXP only someone familiar with HTML/TXP could do it.
~ Cameron
Offline
Re: Improvements to Content Control
I have something pretty good working using gbp_permanent_links. I have a custom field called Section_Home_Page. In my page template I have.
<txp:if_article_list>
<txp:article Section_Home_Page="yes" limit="1" />
</txp:if_article_list>
<txp:if_individual_article>
<txp:article limit="1" />
</txp:if_individual_article>I then decide what section I want to be my “default” section in gbp_permanent_links and set that use /title only url scheme and set the rest to /section/title. This let’s you have /about if you want or /about/something-else.
Then you just need to make sure to have one article in a section that has the section_home_page custom field set with 1 (I use glz_custom_fields to make it a checkbox.
You could probably mimic this with sticky articles also but I needed the articles to stay in flow for other reasons.
It’s worked pretty well so far, doesn’t require sections unless you need them for subnavigation and one could come up with a nice tree based interface to actually build out all the specific details so the user wouldn’t even need to know what is going on. All the sections use the same page and style so that could even be created automatically behind the scenes from a different interface if needed.
However so far even my mom has been able to figure this system out so it seems pretty simple.
Last edited by hakjoon (2009-08-06 14:35:17)
Shoving is the answer – pusher robot
Offline
Re: Improvements to Content Control
I have something pretty good working using gbp_permanent_links. I have a custom field called Section_Home_Page. […] I then decide what section I want to be my “default” section in gbp_permanent_links and set that use /title only url scheme and set the rest to /section/title. This let’s you have /about if you want or /about/something-else.
That’s very cool, Patrick. Another demo of the magnificent versatility that Textpattern facilitates by not building stark divisions between “static” and “dynamic” content into the design.
To clarify, I think the WordPress way of adding new pages is fine for a very simple blog-focused sites with no appreciable information hierarchy, but I think that grafting that onto Textpattern would be a mistake.
Something like content snippets, on the other hand, could be very useful. I’m just beginning to appreciate having an admin interface for snippet content with adi_variables, and I’m interested in discovering and exploring the possibilities opened by the new txp:yield/output_form combo in 4.2.0.
I never took time to figure out gpb_permanent_links, but this is pretty interesting.
Offline