Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#13 Today 04:53:25
Re: The future of Textpattern docs; intentions & plans; RFC
phiw13 wrote #340341:
In the short run, moving to Read The Docs seems a good option.Some people I worked with did just that a few years ago, away from Jeckyl and poor search ( they had many more issues, + they moved away from GH). They now self-host the raw data (on a Gitea instance I think it is called).
Longer term using Textpattern to display the documentation would be great and a good example of the possibilities.
Connecting this to your post about Typepad, I agree that this should be a short term plan and that in the longer term, we have to consider self hosting them.
I remember many years ago there was a plugin that could save versions of the articles. A possibility would be to revitalise and update that plugin, if anyone remembers its name and somehow kept it. This will allow us to open the docs subdomain to contributors.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
#14 Today 06:20:15
Re: The future of Textpattern docs; intentions & plans; RFC
The problem with that approach is that we need everyone who contributes to have a Txp login. That’s not something I relish and would prefer an external site handles authentication for us to suck approved content changes in.
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
#15 Today 11:10:42
Re: The future of Textpattern docs; intentions & plans; RFC
Bloke wrote #340344:
The problem with that approach is that we need everyone who contributes to have a Txp login. That’s not something I relish and would prefer an external site handles authentication for us to suck approved content changes in.
I understand. What if we have this on another subdomain that the .doc site can suck from?:) It could be a very simple one, not accessible via search engines with basic styling for previewing purposes. Articles do not even have to go live!
Contributors could be Freelancers and admins can approve, revert, edit, or delete what they write before those articles are sucked:)
The front end of the site could be a generic page to the docs site, whereas, contributors who are logged in will be able to see their articles. ie.
<txp:if_logged_in not>
Visit the docs.
<txp:else />
You are viewing an article
</txp:if_logged_in>Last edited by colak (Today 11:17:09)
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
#16 Today 11:53:34
Re: The future of Textpattern docs; intentions & plans; RFC
Bloke wrote #340344:
The problem with that approach is that we need everyone who contributes to have a Txp login. That’s not something I relish and would prefer an external site handles authentication for us to suck approved content changes in.
Hmm, aren’t we confident in our user privileges management? ;-)
Offline
#17 Today 12:12:48
Re: The future of Textpattern docs; intentions & plans; RFC
etc wrote #340355:
Hmm, aren’t we confident in our user privileges management? ;-)
Hehe. If docs is a silo server, then I’d be happier.
But I was thinking more about the overhead of self-registration, unless we want to put in a process for people to manually request an account first?
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
#18 Today 12:40:25
Re: The future of Textpattern docs; intentions & plans; RFC
From a logistics point of view, there’s an A-to-B route for marked-up documents (e.g. GitHub) to a web-viewable & searchable site (e.g. Read The Docs). When A-to-B-and-A-to-C (where C is e.g. compilation to an offline format like EPUB or PDF), the ‘A’ part is still maintained as the one true source.
‘A’ (GitHub) can have a lot of heavy lifting added to it: we can convert files from the origin format (e.g. Markdown) to multiple other things (e.g. Read The Docs-ready files…EPUB compilation…PDF export…Textpattern import XML…compiled HTML…etc) concurrently. There’s a whole raft of pipeline stuff we can tap into that we’re not using at the moment. That pipeline stuff makes exporting to ‘B’, ‘C’ and anything else deemed useful.
I’d really like to have a public / transparent inbox and working area (‘A’, e.g. GitHub) that anyone can peruse and comment on without the need to maintain a Textpattern for that purpose of user management. That material goes into the conversion blunderbuss and lands at its destinations (plural), wherever that may be.
I’m absolutely not saying we need to may any old format available, but one person’s trash is another person’s treasure. If we make EPUBs and PDFs automatically, it takes practically zero person time. If they don’t get downloaded or used, we turn that part off.
In my experience, PHPBU does a very clean & clear job of offline docs: www.phpbu.de/documentation.html
I’m not quite yet in chronically online territory, but if can read some docs away from these infernal desktop screens and not use a browser (e.g. EPUB or PDF), that has value. Some organisations might have internal practices where ebooks are permitted in systems that aren’t connected to the internet.
Bloke wrote #340356:
If docs is a silo server, then I’d be happier.
Can you clarify what you mean by silo server please, Bloke? Thanks.
Online
#19 Today 13:19:57
Re: The future of Textpattern docs; intentions & plans; RFC
gaekwad wrote #340357:
That pipeline stuff makes exporting to ‘B’, ‘C’ and anything else deemed useful.
This. I’d much rather have a public changelog than have to do it inside Textpattern.
Can you clarify what you mean by silo server please?
I only meant that if we’re allowing self-registrations that any script kiddie can set up and then change docs and/or wreak havoc, I’d rather not have the docs located on the same physical space as important site assets like textpattern.com. It only takes one person with a crappy password, and privilege escalation is a possibility.
It’s a moot point if we’re doing stuff externally and pushing to Txp. Another plus.
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 Today 13:31:39
Re: The future of Textpattern docs; intentions & plans; RFC
Bloke wrote #340359:
I only meant that if we’re allowing self-registrations that any script kiddie can set up and then change docs and/or wreak havoc, I’d rather not have the docs located on the same physical space as important site assets like textpattern.com. It only takes one person with a crappy password, and privilege escalation is a possibility.
Perfect. Thank you.
Online