Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#13 2008-10-09 07:08:58

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: [wiki] Tags Reference

Thanks, Patrick, I discovered that when doing the upgrade as well when rewriting the former “admin:Planning” information to their own topics in the “help:” namespace (yesterday). That old page is gone (more of that faux namespace nightmare we want to avoid) and the new content is written under the Admin / Sysops section of help:Contents. You might give the upgrading and testing pages a quick look to ensure I didn’t lose something. We should definitely want to use the test wiki you’ve set up.

Offline

#14 2008-10-09 08:39:42

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: [wiki] Tags Reference

All,

With regard to the method of rebuilding the Tag Reference pages in a systematic/intuitive way (under the constraints), here’s one plan:

  1. Add the MultiUpload extension to wiki.
  2. Make temporary .txt files of the exisiting tag page content and upload them in the wiki. (By doing step #1, you can batch upload files, instead of one at a time).
  3. In the Alphabetical Tag Listing, Tags in Development pages and zem_event Tag Reference pages, add two additional links next to each tag page link: one for the uploaded text file (sample syntax: [[media:tag_label.txt]]) and one for the new tag page under the new title convention (label only, lowercase, underscores on compound labels), so for example a given tag entry in a tag list would look like:
  4. When all .txt files are in place, which will be easy to see using this method, then:
    1. delete the old tag pages (necessary because when the next step is done and these pages are not deleted in advance, they will still appear in the main: namespace even though they are not usable (appear empty)
    2. implement the CapitalLinks=false config
  5. Copy/paste the .txt file content into the new tag pages via the pre-set links (Must not be done until after the config is set in previous step!!!), and at the same time add the [[category:Tag Reference]] to the bottom of each new page (which adds it to — and alphabetizes it in — the category)
  6. Delete pages like “Alphabetical Tag Listing” that reference the old tag pages, and delete the .txt files from wiki gallery.
  7. Change nav links to point back to the new categorized version of the Tag Reference.

The only real drag in this is the creation/uploading of the .txt files, but that extension helps with the latter, and if 3, 4, 5 people chip in with the adding the links and .txt creation it should be quick work. Everything else, because of the dependency of implementation and timing of the no-caps config, will need done by admins, and assumingly mostly me since I’m kind of pushing this forward. The copy/pasting of the .txt content later in the new pages shouldn’t be more than 10-15 minutes by 1 person (again, this — step #5 — should not be done until after all .txt files are ready and the no-caps config is implemented or MW will not recognize the lower-casing of the page titles).

Note: We could probably avoid the annoying step #4.1 if Patrick knew how to run a query on the database to remove those pages in one command. If so, this could be done at anytime and not necessarily at that point.

People could help out now by working on steps 2 and 3. Each .txt file uploaded is a step closer. I’ll look into the extension in the meantime as it will be useful in the future for images too.

Any flaws in this plan? If we can optimize it even more, let it be known.

Last edited by Destry (2008-10-09 08:52:46)

Offline

#15 2008-10-09 12:41:42

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: [wiki] Tags Reference

Uh, I think I just realized how to simplify all that tremendously. Thanks to Patrick, we have the test wiki, and the old tag pages outside of TxB proper; so, no, we don’t need to create all those text files (thank heavens), we simply copy/paste from the test wiki. This means we can move forward with making the no-caps config sooner than later. :)

Am I missing something?

Offline

#16 2008-10-09 20:11:59

hakjoon
Member
From: Arlington, VA
Registered: 2004-07-29
Posts: 1,634
Website

Re: [wiki] Tags Reference

Not sure how up to date the test-wiki is so you might want to sync the databases first or something like that. It would only get updated when I did upgrades or was testing things out.

I need to see what’s involved in deleting all the pages. MW has a lot of foreign constraints on tables.


Shoving is the answer – pusher robot

Offline

#17 2008-10-10 11:41:23

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: [wiki] Tags Reference

hakjoon wrote:

Not sure how up to date the test-wiki is so you might want to sync the databases first or something like that.

Good point. I’ll do it. Suggests we should implement the new skin there too since a lot of categories, templates… are created/used in main, some of which rely on the new css.

I need to see what’s involved in deleting all the pages. MW has a lot of foreign constraints on tables.

No biggie, we can always one-off them from the front-office. Though I think even that does not truly delete them (due to the “recovery” feature) unless someone thereafter uses the newly available page title to overwrite the history trail, theoretically.

Offline

#18 2008-10-13 14:43:31

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: [wiki] Tags Reference

A) With regard to the Tag Reference label, not a lot folks in the TC community chimed in about the form/usage, but suggestions were for:

  • Tag Reference
  • Tag References (with some interesting explanations why)

Since we had a validation here in the Txp community for Tag Reference, that’s how we’ll do it (still a wiki category, however — category:Tag Refernce).

B) I need some more clarification on structuring the reference going into 4.0.7. Especially looking for ruud and wet’s feedback on this for their knowledge of what’s in the pipeline.

(Note: In the remaining text the term “category” is used a lot. It referes to wiki categories used for organizing wiki pages; it does not mean in this case the specific “category” tag page(s).)

From these insights, it appears we should have both a functional and contextual structure. With that in mind, let’s consider it. Here’s what exists currently:

  • Alphabetical Tag Listing (default)
  • Tags by Function (not yet populated)
  • Attributes Cross-reference

As explained in the past, we’re going to make the Tags Reference default point a wiki category, which obfuscates the alphabetical listing page (a category auto-alphabetizes wiki pages already) and provides batch printing capabilities.

That leaves the Tags by Function and Attributes Cross-ref pages, which are less usable as single pages having multiple lists. Concerning ourselves with functions only, if we knew what the functional categories were supposed to be, then we could use additional wiki categories for these functional divisions, which can be made subcategories of the main reference that filter tag pages by the given functions. For example (where F1, F2, etc are the different functions)…

  • category:Tag Reference
    • category:F1
    • category:F2
    • category:F3
    • etc

Please realize that in addition to eliminating content redundancy and auto-alphabetizing lists (thus lower content overhead) the subcateogories will serve as subsections in a printed PDF manual. Without them the PDF manual will just be a long doc that goes through the tag pages in alphabetical order (i.e., at the category:Tags Reference level). A given tag page is easily added to one or more functional categories by adding the cat tag(s) to the bottom of the page. The wiki does the rest by auto-alphabetizing the pages in the different cat filters, respectively.

At this point all we need to know is what will the different functions will be so they can be named/created. Extracting this idea from that obsolete thread, it looks like they might be:

  • category:Tag Reference
    • category:Article Tags
    • category:Image Tags
    • category:File Tags
    • category:Link Tags
    • etc.
    • Attributes Cross-reference (for lack of knowing what else to do with this page)

Is that Article, Image, File… organization going in the right or wrong direction?

Next is the contextual organization at the tag page level. For this we can use the mininav template I designed and create as many contextual lists as needed (ensuring each custom list is named under a meaningful convention for clarity into the future).

This will be easier to see/realize when we can begin rebuilding the pages under the new titles (soon), and create a working example based on some tag relationships that already exist (your suggestions welcome), but hopefully you get a little bit of the idea.

Anyway, is this on the right track? Clarifications? Better to know now than after 25 attempts. ;)

Offline

#19 2008-10-13 15:10:16

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

Re: [wiki] Tags Reference

In my limited understanding of ‘category’ as it pertains to a wiki (must log in and play now I have an account, but fear I might break something!) your proposition sounds logical.

With reference to:

  • Category:Tag Reference
    • category:Article Tags
    • category:Image Tags

I seem to remember mention that some tags would appear in more than one category, e.g. article_image would be both an article category tag and an image category tag, right?

fwiw, to complete the list off the top of my head, I can see a few classifications of tags. Perhaps:

  • category:List Tags
  • category:Conditional Tags
  • category:Comment Tags
  • category:Search Tags
  • category:Error Handling Tags
  • category:Navigation Tags
    • e.g. link_to_next/prev/home, breadcrumb, etc
  • category:Meta Tags
    • meta_keywords, meta_author, page_title, lang??
  • category:Programmer Tags
    • not sure about this one but it covers txp:variable (4.0.7), txp:php, txp:txp_die, etc

That leaves a few odds and ends like txp:hide, txp:password_protect, txp:text, txp:else, etc that I’m loathe to put in a ‘miscellaneous’ category because misc is totally meaningless but I’m struggling to categorise right now. Is this too many categories>? Can any be consolidated or renamed and still make sense?


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

#20 2008-10-13 19:14:25

els
Moderator
From: The Netherlands
Registered: 2004-06-06
Posts: 7,458

Re: [wiki] Tags Reference

Maybe something like

  • category:Markup tags (not sure about this name, you will probably find something better…)

for txp:css, txp:site_name, txp:site_slogan, txp:page_title, txp:page_url, txp:hide(?)…
Maybe txp:section and txp:category could go in here as well?

Stef, txp:else should go in category:Conditional tags, don’t you think ;)

Offline

#21 2008-10-14 07:44:26

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

Re: [wiki] Tags Reference

Els wrote:

  • category:Markup tags

Nice, works for me.

txp:else should go in category:Conditional tags, don’t you think ;)

*cough* haha, of course. D’oh.


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

#22 2008-10-14 11:02:35

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: [wiki] Tags Reference

Bloke wrote:

I seem to remember mention that some tags would appear in more than one category, e.g. article_image would be both an article category tag and an image category tag, right?

I think this is exactly what wet and ruud were suggesting, yes, and it’s easy to do with wiki categories. A given tag page can be added to any number of wiki categories (in this case signifying Txp tag functional groups) by simply adding the respective wiki cat tags to the bottom of the txp tag page. (This is how it works.)

A summary of your ideas so far:

  • category:Tag Reference
    • category:List Tags
    • category:Conditional Tags
    • category:Comment Tags
    • category:Search Tags
    • category:Error Handling Tags
    • category:Navigation Tags (e.g. link_to_next, link_to_prev, link_to_home, breadcrumb…)
    • category:Meta Tags (e.g., meta_keywords, meta_author, page_title, lang??)
    • category:Programmer Tags (e.g., variable (4.0.7), php, txp_die…)
    • category:Markup Tags (e.g., css, site_name, site_slogan, page_title, page_url, hide??…section, category ??)

Comments:

  1. “Programmer Tags” makes sense to me as a non-programmer, and it has a stronger distinction than if you tried using “Developer Tags,” which could be more misleading to people…maybe not.
  2. “Markup Tags” … could this be “Template Header Tags”? (excepting the section and category tags) Ed. Nix that, clearly they are not all suggestive of HTML header tags, strictly.
  3. “Structural Tags” ?? (e.g., section and category)

Last edited by Destry (2008-10-14 11:22:15)

Offline

#23 2008-10-14 11:53:33

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

Re: [wiki] Tags Reference

Thanks for the category link: helps in my understanding.

Destry wrote:

“Structural Tags” ?? (e.g., section and category)

Yep, that works for me. So adding in the original categories (article, image, link, etc…) gives us, what, 14 categories? Sounds a lot but I suppose if some of the tags are in more than one, it increases the chance of finding what you’re after.


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

#24 2008-10-17 08:34:44

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: [wiki] Tags Reference

The Tags Reference conversion is now underway and any help is welcome.

The wiki is now case-sensitive for page titles. This means you can save a page called “Comments” and “comments” as two different pages. (That happens to be the only case where a tag page has the same spelling as an existing page, so the case-sensitivity is a good thing here.)

Here’s the steps as I will be approaching them:

  1. DONE [creating (not moving) new tag pages with the new titling convention (e.g., txp:article_custom / now becomes just article_custom) You can follow along with which ones are created by watching the page links change color here.
  2. DONE Adding the category tage (namely [[category:Tag Reference]]) to bottom of each page so it alphabetizes in the new index location, category:Tag Reference. (Actually, I’ll be doing this at the same time as step 1.) Note: At the same time, change the HTML comment to read just as “Keep at bottom!” so that it’s valid for both wiki category and language link tags.
  3. Organize content to have the following top-down structure (see article as a finished example):
    • tag syntax example (in code markup) — this replaces the former “Syntax” section
    • description (no header)
    • Attributes
    • Examples
  4. Edit content to:
    • add the mininav list template tag at very top of the page code (see “article” page as example)
    • Wrap the first instance of the tag name in description in double straight brackets (like a wiki link) to make it function as a bold contextual link (not hot)
    • remove links referencing “Single Tag”, “Conditional Tag” etc in glossary (which is deprecated). Instead, simply put these in italic text. (Note: definitions for “sigle tag”, “conditional tag” and “container tag” are now in category_talk:Tag_Referenc, if you would rather use that.)
    • change section headers so all move up one level. I.e., h3 headers to h2 headers, h4 headers to h3 headers, etc
    • edit links referencing old tag pages to reference new pages. (Simply delete the “txp:” prefixes and the tailing “/” from existing links, and removing blank spaces. Keep the underscores in compound tag names!)
    • edit links that go to the attributes cross reference using the correct title of that page: Attributes Cross-reference
    • remove unnecessary extra blank lines between block element content (headers, paragraphs, etc.)
  5. Begin subcategorizing tag pages into functional groups (as discussed in the previous posts in this thread).

If anyone can help, feel free to jump ahead to any of the other steps for pages already converted. Together this will be quick work. Otherwise you just have to wait. :/

Last edited by Destry (2008-10-17 13:35:32)

Offline

Board footer

Powered by FluxBB