Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
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
Re: Improvements to Content Control
One issue of adding content through forms (or page templates) or variables or whatever is losing the possibility to search that particular content.
Of course, sometimes they are just small chunks of content, with not too much real value… so having them out of the search isn’t a matter.
On the other hand, a custom_field approach like the one suggested by hakjoon is a possible solution, although again, that particular article becomes searchable, and then it may appear in search results (i’m talking about results using the TXP search). Then, the URL could be exposed…
In this sense, the “sticky” approach may be still the best solution. A combination of sticky + custom_field may be even better, as the custom field will let you choose which sticky article is the chosen one for section front page.
Finally, directly using (on page template for a section) txp:article_custom id="xx" attribute is also a good choice to simplify all the jugglery with conditionals and/or custom_fields and/or status.
Again, an status (hidden…) that let you use an article on article lists (section context) but not on individual article context (permalink returning 404, or anything else) would be really useful.
I never took time to figure out gpb_permanent_links, but this is pretty interesting.
Playing once again with it on a rather complex project… I’m about to give up… This plugin seems to work very erratically each time I try to use it. It’s indomitable.
Graeme is working on a new version from scratch… since long time ago
I think I’m ready to try to fund further development, so I think I’ll drop Graeme a line…
Offline
Re: Improvements to Content Control
There are definitely times when sticky would be the right approach. Using the custom field lets you choose (like you said). I didn’t have to really deal with search the times I’ve used this so I haven’t had to solve that problem. I did want to implement dynamic navigation for the each article in a section (which I think sticky status complicated) and wanted to suppress the url’s for section home page so I ended up doing something like this using article_custom
<txp:if_custom_field name="Section_Home_Page" val="Yes">
<txp:section link="1">
<txp:output_form form="menu-text" />
</txp:section>
<txp:else />
<txp:permlink>
<txp:output_form form="menu-text" />
</txp:permlink>
</txp:if_custom_field>I wonder if you could somehow massage the permlink in search results in a similar fashion.
At this point the main hurdle for me was explaining all the steps in the TXP interface to create a new area since you have to jump from section back to write. Having a slightly modified admin interface geared to this workflow where one could pick “parent” pages to assign pages too might be simpler.
That would strictly an UI thing though since the underlying functionality is mostly there. I haven’t had a chance to look at what’s possible with themes in 4.2, but I always thought that being able to slightly change the ui workflow for specific implementations would be a huge feature, since the underlying infrastructure is so flexible already.
Shoving is the answer – pusher robot
Offline
Re: Improvements to Content Control
Don’t forget the power of the cononical rel attribute, as jakob pointed out. From my rudimentary understanding: even if the URL is ‘exposed’ in search results, when a spider actually visits that page and finds rel="canonical" it’ll index the preferred form. Thus:
<txp:if_article_section name="about, contact, other-one-page-section">
<link rel="canonical" href="/<txp:section />" />
</txp:if_article_section>(untested, just a guess).
Combined with some of the other techniques outlined in this thread it should be one more trick to at least help avoid ‘duplicate’ content.
I too really like the way adi_variables allows you to use stuff in pages. I’m sure a more general-purpose plugin could achieve what driz is after… and if it could be injected in the way hakjoon suggested using the pluggable_ui() feature of 4.2.0, the workflow is altered directly on the Write tab. Nice!
Last edited by Bloke (2009-08-07 14:46:36)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: Improvements to Content Control
I think the best solution so far is to be able to post to a fake section. From what I can gather in WordPress pages and posts are the same, except they are rendered differently on the front and the pages can choose a custom template if the user wants. So the same in TXP would be getting an article to render either as an article as part of a section like a blog post etc, or standalone and therefore more like static content. The problem is how to control this, we would need two options one to say what whether the article is standalone (perhaps this could be chosen in the section dropdown), and then an option to choose what page template to use for that article as that article will now be acting as section as well and wont have a page template choses already.
Thoughts? I personally see this as the winning solution, and it makes sense to both TXP semantics and the general user who understands none of it.
~ Cameron
Offline
#29 2009-08-10 22:34:04
- Neko
- Member
- Registered: 2004-03-18
- Posts: 458
Re: Improvements to Content Control
driz wrote:
@Neko Thanks :D What was it that I suggested that was so bad?
Sorry, nothing really. I was just kidding. :)
Offline
Re: Improvements to Content Control
Perhaps content-types like you get in Drupal could also be something to think about as well? But the problem occurs because of the TXP semantic model of HAVING to choose a section for it whether it needs one or not.
~ Cameron
Offline