Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: TXP git repo best practices?
Realizing now that this discussion is about production workflow, for people who build new sites on an ongoing basis. That’s not really what I’m after with CSF, of course, so that probably didn’t make any sense. Sorry for the distraction.
/ slips out /
Offline
Re: TXP git repo best practices?
public is the build directory, regardless of whether it is on local or a remote server.
Ah, thanks to your pointer I now understand. Your templates, assets etc. are all in the /src directory and the actual site are in the parallel /build directory. That now makes perfect sense to me.
Since you are version controlling anyway, you’ll need flat files of your templates. But yes, copy all your forms/pages out of Textpattern into actual files manually if necessary when first setting up, in the directory structure expected by rah_flat.
Agreed. If you are making your own forms from scratch or have a ready-built startup configuration of templates, it won’t matter, but it may surprise people coming from cnk_versioning, hence the warning. BTW, are there not some default forms that are advisable to keep, because they are used as default when no user-defined form is specified?
TXP Builders – finely-crafted code, design and txp
Offline
Re: TXP git repo best practices?
One more thing on the DB sync front. I read that MySQL Workbench (available for multiple platforms) is supposed to have a db compare module.
TXP Builders – finely-crafted code, design and txp
Offline
Re: TXP git repo best practices?
Thank you all for these exchanges, and Jacob for his answers.
If I can work on a new project textpattern, I’ll improve a lot of things.
Another question about rah_flat : with this plugin, Is it possible to organize flat files into subfolders ? is he searched recursively files into “form” folder per exemple to make these imports ? This would allow me to organize more clearly the many forms :
Forms/
- site-stucture/
- site-header.misc.txp
- site-footer.misc.txp
- main-nav.misc.txp
- Components/
- btn.misc.txp
- accordeon.article.txp
- external-output/
- rah_eo_custom-atom.misc.txp
- rah_eo_some-json.misc.txpOffline
Re: TXP git repo best practices?
Is it possible to organize flat files into subfolders?
To be honest, I don’t know.
But you could achieve something similar by adopting a naming convention for your forms, e.g.:
forms/
- layout_site-header.misc.txp
- layout_site-footer.misc.txp
- components_main-nav.misc.txp
- components_hero.misc.txp
- components_accordeon.article.txp
- objects_btn.misc.txp
- rah_eo_custom-atom.misc.txp
- rah_eo_some-json.misc.txp… or however you like to organise them. There are only a few cases (like rah_eo_ and smd_tabber) that have to follow a naming convention, but it doesn’t break the idea.
TXP Builders – finely-crafted code, design and txp
Offline
Re: TXP git repo best practices?
If you are considering migrating to flat (text) files for managing your pages, forms & styles, you might find these little python scripts helpful. Basically, they will help you with the initial exporting of pages, forms & styles to flat files. Really helpful if you have many forms & pages and want to avoid manual work.
Offline
Re: TXP git repo best practices?
Thanks Julián. That’s really useful and fills a gap in rah_flat. I saw your post and tried it a week or two ago but kept getting python errors (nothing to do with your script – probably my python installation). I must try it again with more diligence.
I did think that this is something that would have great potential as a separate txp plugin. It’s really a one-time operation, so it would be fine as a standalone plugin. Potentially that could be extended for other uses, e.g. as a data output to flat-file exporter for article data for use in other contexts – e.g. for porting to another system in haml, xml, json or csv structure, for structured output of data for inclusion in print merge cases, or for giving to site owners as a content inventory for editing. I’ve done this once or twice before by creating a custom page template or using rah_external_output and then saved the page source as text. That’s fine when you need one long stream but more laborious when you need lots of small items – either you call up and save each page one by one or you save the long stream and then have to break it down manually into chunks. For small sites, that’s okay if a little tedious, for larger sites, it’s a major bore … or even impractical.
I’ve veered off topic here, but I’d love to hear if others have found good solutions for this – in a new thread perhaps…
TXP Builders – finely-crafted code, design and txp
Offline