Testers needed: flat development (4.7+ only)

etc · 2020-10-10 07:08:51

mrdale wrote #326303:

delete a couple of forms in the file system

alter a couple of pages and forms in the filesystem

Result: No forms deleted, no pages altered.

If an asset is missing in the fs, etc_flat pulls it from the db. This could be changed or made alterable via Delete unused templates from database on import pref, let me see.

Re no pages altered, have you tried disabling cache?

Desired workflow: I merrily alter my codebase in the file system and anytime the site is hit from anywhere my edits are imported into the database.

I wouldn’t like to automatically write to the db every change I do in the fs, because:

as dev, I’m served from the fs anyway;
site visitors are served from the db, so they would be allowed into my dirty dev kitchen.

gaekwad · 2020-10-10 18:15:11

etc wrote #326305:

dirty dev kitchen.

I love this.

mrdale · 2020-10-15 17:56:55

The spec for themes look really promising and I can see that it represents a ton of work, so bravo to all involved. But I must be misunderstanding the workflow here.

I keep my dirty dev kitchen offline, running on MAMP and periodically rsyncing it to a live server. If the live site’s file structure is populating the database, I never need to do the database export/import shuffle and I don’t need to touch the TXP interface (pretty as it is) to code my website.

rah|oui_flat was perfect for this, but it seems not to be possible in the new file based theme setup + etc_flat.

Bloke · 2020-10-15 18:58:46

Give the end of the development staging server a quick read, as it explains the shift in thinking.

Now, in your case, you’re still using a physical staging/live workflow.

You have a dev site, running in-development code/theme that you’re working on, and viewing it on a staging domain. You want that code to auto-update into your staging site the moment you edit the filesystem. That’s cool, the plugin will (should) do that IF you keep it in testing/debugging mode.

Once you’re happy with the staging environment, you then rsync the files across to your live environment. And you want that code to auto-update into your live site the moment the filesystem is updated.

Off the top of my head, there are two ways to do that, currently:

Flip the live site’s production status to testing/debugging momentarily so the changes get pulled in, then toggle it back to live. That requires you to actually log into the admin side, though.
Change your template code throughout your site so, by default, it reads all your assets as form.flat. That will fetch them from disk and skip the database entirely.

I think that sums it up right now. Correct me if I’m wrong.

Bloke · 2020-10-15 19:10:51

Further:

Short of refactoring your code to use flat files, you might be able to ditch your ‘staging’ server entirely and use a parallel theme. So the workfow is then:

Duplicate your current ‘live’ theme assets into a new folder in /themes. Suffix it _rev_2 or something.
From the live site, visit Presentation>Themes and import the new theme.
Click Assign Sections and select the new theme from the multi-edit dropdown. Leave everything as-is (i.e. on *) and commit the changes.
Your dev workflow is now in place, in parallel, but on the live site.

I’m not sure of the plugin capabilities here, but it’d be totally awesome if any changes you make to the files in the ‘rev_2’ could be automatically sucked from the filesystem into the ‘dev’ workflow lanes, by virtue of them being ‘development’. i.e. even though the site production status is Live, changes to any theme that is “dev” would be automatically served from disk when changed.

Oleg, is that possible? (or does the plugin do this already?)

That would mean you could just donkey around on your live sever by editing rev_2 files, and immediately preview your changes on the site, as long as you’re logged in. Existing ~~suckers~~ visitors still see the live site, as it was.

Then, once you’re happy, to make it live, import your dev theme to the database, go to your Sections panel, select all sections, and use Developer Preview>Deploy to Live, and that “does the rysnc” for you by copying all dev assets over the top of the live ones. Your rev_2 files are now “live” assets and the old files are redundant.

There are of course limitations right now:

No prefs changes.
Plugins are shared across themes.

We’ll get to those eventually and figure out how to handle them.

Last edited by Bloke (2020-10-15 23:12:38)

etc · 2020-10-15 19:45:12

Under no circumstances the plugin is writing to the db.

mrdale wrote #326423:

I keep my dirty dev kitchen offline, running on MAMP and periodically rsyncing it to a live server.

Ah, ok, this is a slightly different workflow, sorry for misunderstanding. Putting your live site in debug mode (with plugin enabled) should work (almost) as you desire, save that all assets are fetched from the fs. If you need it in live mode too, replace

if ($production_status === 'debug' || $production_status !== 'live' && is_logged_in())

condition with

if (true)

in plugins code. More generally, feel free to change it in whatever way you prefer and post here, it was just a test :-)

mrdale · 2020-10-16 20:22:35

Alright. Now I get it… I’m not a smart man…

When you’re in dev mode it pulls from the file system and never touches the DB, and if you go to the forms page it will not display the corresponding form in the file system, but the one in the database until you trigger an import manually

mrdale · 2020-10-17 15:45:30

Now that I understand the workflow. It occurs to me that this would be a great way to do An initial build out of site content.

Flat markdown or textile files serve articles when in dev mode. Images, files and links could be likewise handled in directories then a manual import could pull all that into the dB.

Essentially you’d be getting a Super fast initial build like with Kirby or grav and the power of a database.

Thoughts?

etc · 2020-10-18 10:49:01

mrdale wrote #326450:

Flat markdown or textile files serve articles when in dev mode. Images, files and links could be likewise handled in directories then a manual import could pull all that into the dB.

Essentially you’d be getting a Super fast initial build like with Kirby or grav and the power of a database.

Thoughts?

Could you explain how sections, categories, custom fields etc would be imported from the fs?

mrdale · 2020-10-18 15:15:07

IIRC. Kirby and grav basically throw that kind of information Into specially formatted lines of raw text with prefixes. I’ll update with examples.

Update: Here’s how kirby handles custom fields and tags, etc in content files. Kirby Custom Field

Title: My Page
----
Subtitle: A page about me
----
Text: I'm a chunk of markdown
----
Location: Crackington Haven
----
Aptitudes: knitting,sewing,animal husbandry
----
Bald: true
----
Eye-Color: Chartreuse
----
Link: https://mememe.com/mypage
----

etc · 2020-10-22 17:38:24

mrdale wrote #326470:

IIRC. Kirby and grav basically throw that kind of information Into specially formatted lines of raw text with prefixes. I’ll update with examples.

Thanks, but if you just need to import a Kirby article into txp, that looks like an import module/plugin for me. Working with text files when, say, filtering by cf, could be expensive.

mrdale · 2020-10-22 18:38:11

etc wrote #326508:

Thanks, but if you just need to import a Kirby article into txp, that looks like an import module/plugin for me. Working with text files when, say, filtering by cf, could be expensive.

I’m actually kicking around the idea of a flat file content workflow in txp, not a specific import need. I’m suggesting that such a workflow would speed content creation dramatically at the time of initial site build.

Imagine just throwing a bunch of images, text and other files into directories and having them automatically imported into the database. I’ve built this way with kirby and was blown away by the efficiencies gained. Not wild about some of kirby’s other limitations though.

Textpattern CMS

Textpattern CMS support forum

#181 2020-10-10 07:08:51

Re: Testers needed: flat development (4.7+ only)

mrdale wrote #326303:

#182 2020-10-10 18:15:11

Re: Testers needed: flat development (4.7+ only)

etc wrote #326305:

#183 2020-10-15 17:56:55

Re: Testers needed: flat development (4.7+ only)

#184 2020-10-15 18:58:46

Re: Testers needed: flat development (4.7+ only)

#185 2020-10-15 19:10:51

Re: Testers needed: flat development (4.7+ only)

#186 2020-10-15 19:45:12

Re: Testers needed: flat development (4.7+ only)

mrdale wrote #326423:

#187 2020-10-16 20:22:35

Re: Testers needed: flat development (4.7+ only)

#188 2020-10-17 15:45:30

Re: Testers needed: flat development (4.7+ only)

#189 2020-10-18 10:49:01

Re: Testers needed: flat development (4.7+ only)

mrdale wrote #326450:

#190 2020-10-18 15:15:07

Re: Testers needed: flat development (4.7+ only)

#191 2020-10-22 17:38:24

Re: Testers needed: flat development (4.7+ only)

mrdale wrote #326470:

#192 2020-10-22 18:38:11

Re: Testers needed: flat development (4.7+ only)

etc wrote #326508:

Board footer