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
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
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.
Hire Txp Builders – finely-crafted code, design and Txp
Online
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
#85 2018-03-17 12:57:50
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,316
Re: Feedback to: Textpattern CMS 4.7.0 beta released
On Admin > Sections and Styles I get each:
Parse error: syntax error, unexpected '.', expecting ')' in /Users/Uli/Sites/txp470-dev/textpattern/vendors/Textpattern/Skin/Css.php on line 44On Admin > Forms I get:
Parse error: syntax error, unexpected '.', expecting ')' in /Users/Uli/Sites/txp470-dev/textpattern/vendors/Textpattern/Skin/Form.php on line 47Usage of plugins is switched off in Admin > Preferences.
Edit: All checks passed in Diagnostics.
BTW: The above line in Diagnostics has an empty class for the span inside #pre_flight_check. (Gone after installing the nightly build) Previously it had .success, I think. The warning class — for when I still had the setup directory — was displayed, though.
Last edited by uli (2018-03-17 14:23:52)
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
CodeWalker wrote #310071:
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.
Sorry, I don’t see the point in comparison between two CMS with rather different feature sets. The game is db txp vs fs txp, but the latter does not exist (yet).
Incidentally, from my place your frontpage takes ~200ms runtime vs 125ms for mine, but these figures are meaningless ;-)
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
etc wrote #310075:
Sorry, I don’t see the point in comparison between two CMS with rather different feature sets. The game is db txp vs fs txp, but the latter does not exist (yet).
Incidentally, from my place your frontpage takes ~200ms runtime vs 125ms for mine, but these figures are meaningless ;-)
My point is that reading from the file system doesn’t need to be slow, using the only point of reference I have since TXP doesn’t yet read from the file system.
Merely offering up ideas :) TXP is fast, it’s one of the reasons i started using it using it in the first place 8 years ago. I just don’t think that reading the templates from disc is going to damage that speed.
Peace.
Offline
#88 2018-03-17 15:06:30
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,316
Re: Feedback to: Textpattern CMS 4.7.0 beta released
I edited the above errors away in /vendors/Textpattern/Skin/Form.php and /vendors/Textpattern/Skin/Css.php and I’m baffled that I don’t get a message for changed files on Diagnostics. Is that expected in the dev version?
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
Oh, I hope you don’t perceive any aggression in my arguments, peace. Sure, reading a flat file from disc is fast, but txp queries can be more involved than that: seek for a form, link it with other forms, seek inside a form (plugins like smd_where_used). And in these cases SQL is easier to use than grep or other fs tools.
This said, I am for flat files option for easy development, but without dropping the db storage for advanced use.
Offline
Offline