Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2012-12-14 12:13:55

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,137
GitHub

Tag attribute uniformity

Hi, dev folks.
I’m doing some background work on the wiki to plug a few minor gaps in the tag reference. Part of this involves me making a spreadsheet of tags and their attributes from the Textpattern source. After I’d had a first pass of taghandlers.php, it struck me that there’s a little disparity between some of the tags. It’s not huge, and arguably an exercise of completeness, but here’s an example:

  • recent_comments has an offset attribute
  • recent_articles does not have an offset attribute
  • related_articles does not have an offset attribute

All three are essentially outputting stored data in list format. Now, if I want to split this list over >1 columns/pages/divs I can with recent_comments but I can’t with the others. Sure, if I spent some time thinking around it I could perhaps bodge it with some handy form action, but it’d be nice to be able to have existing functionality extended across all relevant tags.

Taking this a step further, I’d love to see this — and I’m happy to put the work in to make the business case: related tags should have common attributes. Here’s an example: comment_time, file_download_created and posted work in a fundamentally similar way by outputting a timestamp. Here are the attributes for each tag (info scooped from r5048):

comment_time

  • format
  • gmt
  • lang

file_download_created

  • format

image_date

  • name
  • id
  • format

posted

  • break
  • category
  • class
  • label
  • labeltag
  • limit
  • section
  • sort
  • sortby (deprecated)
  • sortdir (deprecated)
  • wraptag
  • no_widow

I loves me some gmt; it helps me hugely with international servers and timezone discrepancies (which are no fault of Textpattern, the blame falls squarely at ISO, there). I can use gmt on some but not all of the above tags, which is a shame. Yes, I can use a plugin, of course, but core almost has it nailed.

Now, I fully understand how articles could be construed as more important or have a higher visibility/priority than files and comments, that’s perfectly valid. However, it’s been said that Textpattern is not a blogging platform per se, it’s a content management system. Articles are content, files are content, images are content, comments are content, at least in this authors opinion, he says, referring to himself in the third person and using vastly more commas than are strictly required.

At the same time, I’m conscious of code bloat. There should be a balance, of course, between adding functionality and maintaining a tight ship — that’s an excellent selling point of Textpattern; it’s nimble, powerful and efficient. Similarly, the work involved with getting each tag up to scratch attribute-wise might detract from other development. There again, the code already exists in some form because some tags can already do some things, so it might just be a case of joining the dots together.

Now, I can’t read or write PHP at the present time, although I’m learning very slowly, so I can’t provide accurate patches to fill the blanks. I am happy putting together some data from taghandlers.php etc to show visually what tag uses what attributes and what is required. What I’d really like is some feedback on whether this is a good idea, or if I should divert my time elsewhere within the project.

Thank you in advance.

Offline

#2 2012-12-14 12:52:25

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,269
Website GitHub

Re: Tag attribute uniformity

It’s worthwhile. Tags have grown organically over the years with attributes added by many developers, so some get newer functionality while others don’t. Another example.

I’ve also undertaken to revisit the comments and have put together a similar matrix of which tags can be consolidated, deprecated, which attributes are missing from tags and so forth. It’s not complete yet but I can share it (perhaps here, perhaps as an email conflab at firs). That would save duplicating effort in the comments domain.

EDIT: also the docs sometimes slip out of sync, especially the Attribute cross-reference so this is a good exercise to make sure things line up.

Last edited by Bloke (2012-12-14 12:55:18)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#3 2012-12-14 13:31:13

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,137
GitHub

Re: Tag attribute uniformity

Thanks, Stef. I’ll start a Google Doc spreadsheet with my initial findings so it’s openly visible and comment can be made here.

Regarding the wiki, I’m making comments on some of the Talk pages for tags if something needs doing; they’re mostly quick copy + paste jobs, to be frank, but I didn’t want to slow down my momentum of manually processing the tags from taghandlers.php.

Offline

#4 2012-12-14 13:45:49

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,137
GitHub

Re: Tag attribute uniformity

Right, this is a work-in-progress Textpattern tag + attribute matrix on Google Docs. Fully work-safe, everyone has view rights. I’m prettying it up today.

Offline

#5 2012-12-14 21:06:51

merz1
Member
From: Hamburg
Registered: 2006-05-04
Posts: 994
Website

Re: Tag attribute uniformity

Pete Great maintenance (sub-) project. Thanks for the check & hat tip!


Get all online mentions of Textpattern via OPML subscription: TXP Info Sources: Textpattern RSS feeds as dynamic OPML

Offline

#6 2012-12-15 02:35:30

gomedia
Plugin Author
Registered: 2008-06-01
Posts: 1,373

Re: Tag attribute uniformity

To improve consistency & usability, I reckon all tags that generate markup – such as title, body, custom_field etc should have wraptag, class attributes etc.

And to be brutally consistent output_form name="xyz" rather than output_form form="xyz"!

Offline

Board footer

Powered by FluxBB