Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Wiki development
You can see who made what changes via the contribution scores page, as one way.
Offline
Re: Wiki development
OK, thanks Destry, that’s helpful for tracking.
Offline
Re: Wiki development
Also: the public log and recent changes
Offline
Re: Wiki development
Destry wrote #278310:
“CMS” has always been a stretch for Textpattern (for the sake of search rankings). A web publishing system is more like it. Being able to use the acronym, API, would be a more distinguishing feature to boast. Alas.
Valid observation.
Offline
Re: Wiki development
I’d like to announce a freeze on any more wiki user accounts until it’s clear what the future of docs is; whether it will remain in the wiki, or move to a new platform. If it’s going to move, there’s no point creating more accounts that will rarely to never get used anyway.
Offline
Re: Wiki development
It will move to a Textpattern install somewhere eventually. I made a start on moving the documentation to GitHub for this purpose, if any of the articles you want to edit are already there, then feel free to amend them. I’ll add more pages as I get spare time.
Last edited by philwareham (2014-04-17 11:14:30)
Offline
Re: Wiki development
Okay. No more wiki user accounts, then.
Offline
Re: Wiki development
While were thinking about this, can we confirm/dispute a few more points so everyone is on the same page?
- Are we for sure ending support of doc translation efforts?
- Are we keeping docs editing to a restricted few editors?
- What will happen with the non- user docs content currently in the wiki? For example, all the developer stuff, etc.
- In relation with #3, is there a rough sitemap outlined yet for the new Txp-powered docs?
- Once there is an IA plan for new docs, can we run the wiki and new docs in parallel until the wiki content is fully ported?
My own thoughts on these points…
- We should end translation support because that was the whole point of the wiki, and user doc translation efforts have been pretty much a failed process since day one anyway. I’d also propose a push to those language communities to get their stuff out now if they want to keep it. Most of it will be pretty crude after the migration anyway because so much of the English content will be revised, and especially as we get closer to 4.6.
- I think we should restrict editing rights, for a number of valid reasons, including crowd control, consistent style/tone, accountability, etc.
- One thing that’s always been confusing about the wiki is the mixed nature of content. If we’re going to make this change now, it would be wise to keep end-user docs (what the wiki was really meant to be for) separate from developer docs, community projects, and whatever else landed in there by happenstance. I would really like to see the Textpattern install be end-user docs (core-based) only. Dev docs, for example, might be best left to Github, or something. On that I don’t really care, that should be a dev decision, but the dev content, etc, should not be mixed with the end-user stuff.
- ?? — If there is a rough plan, I’d love to see it. If not, I can probably help there.
- I think having the two sites running in parallel, temporarily, while editors work on the porting would be wise, and a lot easier for those doing the editing.
Offline
Re: Wiki development
Destry wrote #280287:
Are we keeping docs editing to a restricted few editors?
Since the docs are under VCS, they are going to be edited through that git repository. And, yes, anyone can contribute by sending pull requests. Pull requests are then merged as seen fit.
philwareham wrote #280285:
It will move to a Textpattern install eventually. I made a start on moving the documentation to GitHub for this purpose, if any of the articles you want to edit are already there, then feel free to amend them. I’ll add more pages as I get spare time.
I don’t honestly see any reason to use Textpattern for the wiki, when the content is entirely static and comes from VCS.
Textpattern’s doesn’t really work for that with its old-school web GUI based workflow and API-less codebase. I would rather use a static site generators and so on. Good option could be Sculpin or Jekyll, or building small CLI builder (or view bootstrap app) in Symfony.
If Textpattern was modern, used views and so on, and allowed pull in content from where ever (used ORM), we could do anything with Textpattern, but Textpattern is essentially just another procedural CMS.
We could write all that cool stuff, but we can’t even come into conclusion whether we should jump to PHP 5.3.0, or what framework we should use. And yes, we should use frameworks and package managers (Composer). And no, they do not affect end-users as they are downloading build packages with all dependencies already added in. We can’t use ORM or do APIs without conclusion whether we are requiring PHP 5.3.0 or not, and adapting the use of frameworks.
Last edited by Gocom (2014-04-17 09:57:52)
Offline
Re: Wiki development
Regardless of static (or not) content wouldn’t it be more appropriate to use txp? If we believe in its power and versatility it should be the way to go. Furthermore as people who will be contributing will be txp users its interface will be familiar to them.
re the GUI will it not change with v 4.6 and the introduction of “unlimited” custom fields?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Wiki development
colak wrote #280289:
Regardless of static (or not) content wouldn’t it be more appropriate to use txp? If we believe in its power and versatility it should be the way to go. Furthermore as people who will be contributing will be txp users its interface will be familiar to them.
But, contributions do not happen trough Textpattern. Content is managed via VCS and lives in a git repository. The reason why the site is static.
If we use Textpattern, or some other active system, its one more point for intrusion. If we don’t use Textpattern’s GUI, what benefit does the CMS give. If Textpattern had an API, a framework of its own, we would of course be using that, but it doesn’t. Only thing Textpattern is able to do, is to pull content from a database, limited to its preset structure. It has no views, no ORM. It doesn’t even have a documented, public API for adding content to that database.
Offline
Re: Wiki development
Well, I’ll continue putting the Wiki docs onto GitHub – where they go after that, and how, is not my area of knowledge.
Personally all I’m sure of is that I don’t want to maintain MediaWiki or attempt to style it to look like our proposed new brand design. And that the documentation should be in VCS, available to anyone to edit (although peer reviewed by us).
Offline
Re: Wiki development
philwareham wrote #280292:
Well, I’ll continue putting the Wiki docs onto GitHub – where they go after that, and how, is not my area of knowledge.
Personally all I’m sure of is that I don’t want to maintain MediaWiki or attempt to style it to look like our proposed new brand design. And that the documentation should be in VCS, available to anyone to edit (although peer reviewed by us).
In that case, Sculpin is probably the best option. It uses Twig as its templating language, and even supports PHP-Textile for article formatting. It makes setting up the site fast and easy. We don’t have to do anything else than build the views in Twig.
Since the site is then static, we don’t have to worry about security issues or running complicated software on the server, or optimisation or caching.
It would be cool to do the docs in Textpattern, but Textpattern isn’t just able. Textpattern could if it had autoloadable, modular framework, and ability to load content where ever, but it doesn’t and our only option would be to hack in a plugin (that is a hack as there is no public, documented APIs in 4.5.x nor in 4.6.0 atm) that imports the content from files to a database.
Waiting for the day when we have full Textpattern template parser, full API and specification for the templating language. It would be really cool and beneficial if other projects could consume the template language parser as a library dependency… but none of that exists at the moment.
Offline
Re: Wiki development
I am actually wondering if the site is or should be static. The tags both develop, as more attributes are scripted within them, and multiply as new tags come out on new txp releases. Furthermore, the usage examples are added as needed to make their use clearer.
Admittedly there are pages on the site which are indeed static but there are others (such as the aforementioned tag reference) which are more dynamic than most sites.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: Wiki development
colak wrote #280295:
I am actually wondering if the site is or should be static. The tags both develop, as more attributes are scripted within them, and multiply as new tags come out on new txp releases. Furthermore, the usage examples are added as needed to make their use clearer.
Admittedly there are pages on the site which are indeed static but there are others (such as the aforementioned tag reference) which are more dynamic than most sites.
Hi Yiannis
If I understund coorectly what gocom said the static website will be synced regularly (or automated!!) with the github version that will give us an up to date doc without the need of a dynamyc website.
@Gocom
If i didnt know that you are a txp dev i should conclude when reading your comments that txp is a bad system ;)
Offline