Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#85 2018-03-17 12:57:50
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,306
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,306
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
Re: Feedback to: Textpattern CMS 4.7.0 beta released
etc wrote #310068:
I meant if needed while developing, fetch themes directly from fs, without updating db.
Ah then we were talking at cross-purposes, sorry. I’m talking about the webhook that Phil and others want us to explore now. Fetching from disk directly, fine if it’s an easyish win.
CodeWalker wrote #310069:
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.
We’ve been back and forth on this for nearly a decade. While all our competitors pretty much rely wholesale on the file system for serving templates, we’ve stuck with the database. And we outperform most of them – sometimes by several orders of magnitude. Architecture, or coincidence? Maybe a bit of both. Difficult to say. Apples. Oranges.
Ultimately, I’m with Oleg on the access argument. Storing, searching and indexing a database is more flexible (even on crappy relational DB technology, virtually unchanged since it was conceived to work with the disk environments of the 1970s) than trying to do the same thing across a file system with current tools. Yes, file systems are slowly catching up at storing useful metadata but we have little control over what they store. In a DB we choose the metadata and how to index it.
My original stance has always been that the cost of moving the disk head when you’re already serving a) core files, and b) database caches for stuff in columns > VARCHAR is immense. Adding templates to that is just more of a bandwidth bottleneck. The latter is slightly moot in some respects because all our template columns are TEXT or higher so are likely to incur a disk hit anyway, unless the database content is capable of being cached after first load by your chosen DB engine (and we do caching internally anyway so it only really affects first load of each asset per page).
SSDs tip the playing field a bit. Random access NAND flash is fast enough, albeit still at the expense of having to tear down entire blocks on rewrites or for wear levelling algorithms, to make it worth considering. We’re still limited by the disk buffer, plus how many concurrent operations the controller permits, and the raw performance depends on which memory architecture the manufacturer chooses. But on the whole, for reading – which is where it matters when serving a website – it’s far better than spinning platters.
I’m all for a hybrid approach if we can manage it sensibly. Index and content in the DB for searchability; content optionally served from disk if someone wishes.
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’m personally fine with templates stored in the database. It’s easily cacheable and allows for some pretty dynamic code.
Flat files for me is solely so we can edit, build and version control using modern workflow and tools. The web hook URLs if available can be built into any build tool script (Webpack, Grunt, Gulp, NPM, whatever) so effectively that can mimic browser reload anyway.
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
Bloke wrote #310082:
Ah then we were talking at cross-purposes, sorry. I’m talking about the webhook that Phil and others want us to explore now. Fetching from disk directly, fine if it’s an easyish win.
We’ve been back and forth on this for nearly a decade. While all our competitors pretty much rely wholesale on the file system for serving templates, we’ve stuck with the database. And we outperform most of them – sometimes by several orders of magnitude. Architecture, or coincidence? Maybe a bit of both. Difficult to say. Apples. Oranges.
Ultimately, I’m with Oleg on the access argument. Storing, searching and indexing a database is more flexible (even on crappy relational DB technology, virtually unchanged since it was conceived to work with the disk environments of the 1970s) than trying to do the same thing across a file system with current tools. Yes, file systems are slowly catching up at storing useful metadata but we have little control over what they store. In a DB we choose the metadata and how to index it.
My original stance has always been that the cost of moving the disk head when you’re already serving a) core files, and b) database caches for stuff in columns > VARCHAR is immense. Adding templates to that is just more of a bandwidth bottleneck. The latter is slightly moot in some respects because all our template columns are TEXT or higher so are likely to incur a disk hit anyway, unless the database content is capable of being cached after first load by your chosen DB engine (and we do caching internally anyway so it only really affects first load of each asset per page).
SSDs tip the playing field a bit. Random access NAND flash is fast enough, albeit still at the expense of having to tear down entire blocks on rewrites or for wear levelling algorithms, to make it worth considering. We’re still limited by the disk buffer, plus how many concurrent operations the controller permits, and the raw performance depends on which memory architecture the manufacturer chooses. But on the whole, for reading – which is where it matters when serving a website – it’s far better than spinning platters.
I’m all for a hybrid approach if we can manage it sensibly. Index and content in the DB for searchability; content optionally served from disk if someone wishes.
Gracious. A very thorough answer :) Trust me to stoke up a decade old argument. Again. I totally get both arguments, but as a front-ender, I would just love a speedy way to develop with TXP without having flick back and forth into the backend to press a button when I change a template.
philwareham wrote #310083:
I’m personally fine with templates stored in the database. It’s easily cacheable and allows for some pretty dynamic code.
Flat files for me is solely so we can edit, build and version control using modern workflow and tools. The web hook URLs if available can be built into any build tool script (Webpack, Grunt, Gulp, NPM, whatever) so effectively that can mimic browser reload anyway.
Thats exactly what I want, and if that means a button to suck it up into the database for production, then so be it.
I’m simply aiming to speed up local development, using tools such as you mentioned (Npm + Browsersync). If i press save on a template file thats open in Atom, it should reload in the browser without intervention.
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
CodeWalker wrote #310085:
Trust me to stoke up a decade old argument.
You aren’t the first. You won’t be the last. :)
It would be nice to be able to edit a template live in Atom or Sublime or Notepad++ without copying and pasting, though. Maybe someday.
Offline
Re: Feedback to: Textpattern CMS 4.7.0 beta released
CodeWalker wrote #310069:
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.
Please don’t:). Some of us love to work in computers without an ftp client. I actually prefer to work on the browser. What I believe we are in need for, is for the functionalities of rvm_css and spf_js to become part of the core. That is, working on the browser and on save, the files are also stored as files.
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: Feedback to: Textpattern CMS 4.7.0 beta released
colak wrote #310087:
Please don’t:). Some of us love to work in computers without an ftp client. I actually prefer to work on the browser. What we are though in need for, I believe, is for the functionalities of rvm_css and spf_js to become part of the core. That is, working on the browser and on save, the files are also stored as files.
Oh man, I’m really causing trouble today :) Sure, working out of the browser suits some people, it’s just not for me (unless im writting content). I think it should be possible to choose either way without being forced in either direction, I was probably a bit brutal when i suggested ditching it all together, I know the feature has some love out there.
Last edited by CodeWalker (2018-03-17 18:24:17)
Offline