Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Feedback to: Textpattern CMS 4.7.0 beta released
etc wrote #310024:
Yes, it could be a per theme potentially confusing option switchable via multi-select.
Well that could be confusing ;-) I was thinking more along the lines of a single checkbox at the top of the panel, but it might be better as a regular pref that showed a banner or something on the Themes panel all the time it’s on, as a warning. Dunno. Do we need it per theme? Not sure.
Whether this would only be applied in certain production levels I’m not sure. We need to step back and assess what it is we’re trying to achieve, then figure the least intrusive / most convenient / most logical approach.
philwareham wrote #310011:
Can we please look at a way of doing web hooks too before 4.7 final?
For the uneducated (me), please outline how it works. A pref? A dedicated URL that triggers it? How’s it configured, that sort of thing. Primarily, is there room for improvement over the current plugin mechanism?
CodeWalker wrote #310023:
I think 4.5 was the last version I used in anger.
There’s been a lot of development since then. Stick around. Heck, if you fancy it later in the year we could hook up and you could help steer its direction over a few beers!
Now if we could just get direct read of the template files from the file system
Thinking in progress…
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
Re: Feedback to: Textpattern CMS 4.7.0 beta released
Bloke wrote #310025:
There’s been a lot of development since then. Stick around. Heck, if you fancy it later in the year we could hook up and you could help steer its direction over a few beers!
Sure, I’d hit a few beers with you and bash some ideas around. Whenever really, I’m usually pretty free.
Last edited by CodeWalker (2018-03-16 19:21:04)
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
The hook in rah_flat was a URL with secret key that you could define (or auto generate). Then it was simply a case of pointing your browser at that URL and it triggered a database import from flat files.
Sure that was just for one theme, but a combination of theme directory name and secret key could work pretty well I think.
People can build that hook into their build scripts to automate the procedure too.
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
philwareham wrote #310037:
The hook in rah_flat was a URL with secret key that you could define (or auto generate)… Sure that was just for one theme, but a combination of theme directory name and secret key could work pretty well I think.
Sounds doable for sure. If we’re making it per-theme, why not introduce an entry in manifest.json? Upon import / update, this endpoint would need to be stashed somewhere and activated (on-the-fly?)
Stashing it in the DB / prefs is an option but it’s an overhead to manage/update if the endpoint is changed. It’d be nice if each theme could just register their URL with a callback handler whenever it’s created/saved/updated or something. That handler could just be checked in pretext() in the same way we intercept draft article preview.
Heck, if we made this part of an actual webhook package, any plugin could play. Register an endpoint via an API call and get notified when it’s hit. Plugins could use that to do all manner of things. Maybe during theme preview, mapping the current Section’s Page/Style assignment to something else. That would allow people to overcome the limitation that we currently have where the page/style of the preview theme has to match the one assigned by the real site. Or to do generic redirects. Or to register new tabs. Or…
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
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
etc wrote #310058:
Sorry, I don’t understand how a flat file update would trigger these callbacks.
I meant when created/saved/updated in the DB. So when you Create a new theme, or Import one off disk, it reads the manifest.json and finds the field (e.g. txp_hook or something) that defines a URL endpoint.
This endpoint is added to the register (presumably overwriting any previous value for this theme). We just need to store the URL and an ‘owner’ (type, name, something?) which can be used to differentiate between identical registered URLs if necessary.
When navigating the site, the pretext handler checks if you visit one of the registered URLs. If so, it wakes up and fires a callback, passing along the additional registered data, that something (core, plugin) can respond to.
It’s not much different from registering a callback now, it’s just that instead of doing it in code, we’re giving people the opportunity to register one by passing in a value, and introducing a handler in pretext to service them. Will something like that work?
Last edited by Bloke (2018-03-17 09:53:02)
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
Re: Feedback to: Textpattern CMS 4.7.0 beta released
This could certainly be useful, but not for flat files editing. Even if we find a way to update the db on files update, that’s too stressing for the db: you change a comma, sync, not happy, revert, sync… I think one day we should be able to fetch forms from various sources anyway.
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
etc wrote #310065:
This could certainly be useful, but not for flat files editing. Even if we find a way to update the db on files update, that’s too stressing for the db: you change a comma, sync, not happy, revert, sync
Not sure I understand. It’s no more stressing to the DB to do this:
- Edit file(s) in the filesystem.
- Visit Themes panel.
- Select theme, multi-edit and import.
- All theme’s data is imported into the DB.
vs:
- Edit file(s) in the filesystem.
- Visit the webhook URL that is defined in the theme.
- All theme’s data is immediately imported into the DB.
I’m not talking about auto-updating on save or anything. It’s still a manual process, but instead of doing the multi-edit dance, it’s a quick refresh of a known endpoint page to inject the theme files into the DB.
I think one day we should be able to fetch forms from various sources anyway.
That’d certainly be useful. I was against it in the old spinning disk days but with SSDs, loading from “disk” isn’t the bottleneck it once was.
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
Re: Feedback to: Textpattern CMS 4.7.0 beta released
I meant if needed while developing, fetch themes directly from fs, without updating db. And sync manually, once everything is ok. Yes, it’s reading from the disk, but we read many things (includes?) from the disk anyway. And it would be for logged users only, and only until they switch to db mode.
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
Bloke wrote #310067:
I was against it in the old spinning disk days but with SSDs, loading from “disk” isn’t the bottleneck it once was.
Seems most of the discussion is around keeping the database happy and stress free. Technology has come along way, together with the way websites are built. I would strongly consider ditching storing the template code in the database all together, and going 100% flat files as far as a template is concerned.
I’ve been working with Textpattern long enough to know that its original concept was portability – just chuck a database up and your good. However, that was over a decade ago and I think today its actually holding TXP back. Databases are for content. Files are for templates.
If you ditched the ability to edit and store themes in the database itself completely (pages, forms, styles), and just kept the ability to choose from a list of themes based on the manifest files, and a way to assign pages to sections, would that be so bad?
Last edited by CodeWalker (2018-03-17 12:19:00)
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
CodeWalker wrote #310069:
If you ditched the ability to edit and store themes in the database itself completely (pages, forms, styles), and just kept the ability to choose from a list of themes based on the manifest files, and a way to assign pages to sections, would that be so bad?
DB are structured, indexed, requests cached, I’m not sure we can get the same performance with fs. And why not having both: develop in fs if you wish, sync and serve from db when finished?
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
etc wrote #310070:
DB are structured, indexed, requests cached, I’m not sure we can get the same performance with fs. And why not having both: develop in fs if you wish, sync and serve from db when finished?
I think you would be surprised. My own site is currently 100% flat files (for templates and content) and CMS powered. Its extremely fast (Although to be fair it’s running on an SSD based VPS). I’m tempted to rebuild it with TXP and run some tests on them side by side, with it running on common shared hosting.
I think it would end in a photo finish.
Offline