Squire Rethink

[Jason Knight]

I know there are hosts that do not let you go above root. I feel you need to get a new host if that is the case.

I often say much the thing about other server features / lack of features, but being that I remember neverNoSanity / Santy A, I remember how badly things can go to **** if you allow willy-nilly access above HTTP root.

To me the HTTP root exists to isolate the rest of the server; NOT the parent directory. Admittedly, it's been over a decade since I've seen anything THAT nasty grab hold, but I still think that even just allowing PHP to access stuff above the HTTP root is a worse idea that leaving it where it should be.

If for no other reason than I was always taught and have always advocated that if you have to "../" or use absolute paths on a web facing program, your code is utter shite. Hence why my "Request" object actively blocks the presence of "..".

You shouldn't have to code the app to make up for poor hosting. Also part of why I left out the Gzip code. That belongs in the server config or the vhost.

Excepting that the server often misses two out of the three supported mime-supports, and you might as well do it so you can header() and/or set cookies wherever you want. NOT that it's a giant penalty not to since output is separated from processing, but it's still nice.

Same goes for X-Frames Header.

Being a HTTP header, and therefor part of the HTTP output, it really makes no difference in code efficiency, performance, or much of anything else where you put that. In which case you might as well let the app do it instead of adding more stuff for Apache to parse through / check on every blasted request. People SAY that not using .htaccess for things like this is faster, and it is, but it's NOT "that much" faster as such checks for matching needs to be done, even if you're sending it to all files. And far worse if you're filtering. Much less the train wreck implementing headers are in ngnix where if you start screwing with that sort of thing, you can drag its normally stellar performance down SLOWER than Apache. You'd almost think they used a full scripting language for its config files instead of actual config files.

I have intentionally left out comments and explanations as I believe the code is simple and intuitive enough that anyone with basic knowledge can easily see how it works and how to add pages. I also want to hear feedback on that without having provided any assistance on how things work.

Well then, let's see it so we can comment.

[benanamen]

Squire Rethink is now available.

https://github.com/benanamen/squire-rethink

[GrumpyYoungMan]

Is PHP 8 supported?

When I get to the workshop later I’ll give this a look at too!

[benanamen]

Is PHP 8 supported?

It sure is!   

[benanamen]

@benanamen,
> I just made a slight change. Make sure you have version 1.5


Updated, many thhanks.

May I suggest adding the version number to the page somewhere, possibly in either the header or the footer.

Bringing you over here so we don't muddy the Milestone thread.

I don't really intend on doing anything more to it. It was just to show how much difference the architecture can make. It is the same site as Squire 3 but much, much cleaner and easier to understand.

Keep in mind, it is a refactor of Squire 3. I would do do things a bit different on a clean write. Mainly it would be class based, PSR-2 Auto-loading and most files outside the root directory. Basically everything that is considered current coding practices, everything Jason against. It does give the general idea though.

[Jason Knight]

You basically stipped out 90%+ of the functionality when it comes to future planning -- but worse? You've violated the separation of concerns.

How would I add a second template in parallel to the first? How would I handle internationalization? How does one dynamically add/remove menu items without touching the markup? Where's the ability for specific subpages -- like when you get to adding an admin panel -- to load their own CSS? Where's the session handling for form tokens? What makes the faux-body, header, and H1 part of the "menu"?

All you've done is slapped it together as static markup, meaning you've left 90%+ of the reason to even use PHP on the cutting room floor. It lays no groundwork for adding SQL integration, you've got ZERO provision for adding new pages without having to edit the index.php -- worse you've got that wasteful array that's only going to get worse the more pages you add. Don't even get me started about how you have zero provision for proper friendly URI's since you're blindly using JUST that derpy array.

You've gone far below the task complexity requirement of a CMS. I would't even call this a poor man's system, but if one were to scale this up it would illustrate what utter JUNK "routing" is... because having to manually edit the menu and that "routing" array just because you want another page? That's junk.

Laugh is though, we're ALMOST on the same page since if that's your idea of routing, I'm just using the existence of sub-folders as my "route".

Really weird part though being I'm not 100% sure how one adds a new page to your system, since it seems to have zero separation of template from content.

like... wtf does the contents of "Contact.php" have to do with contacting ANYTHING? Are you REALLY going to repeat the IE warning in each and every blasted page since you've got it in contact, 404, etc? Are you REALLY going to repeat the same markup for each and every joe blasted possible http error code?

And I really think you completely missed how/what the extra's even are / are for / are implemented... since if  you've got dozens of pages sharing the same "extras" how are you going to implement that?

You cloned the output, but you've crippled what it does, what something like this is even for, and as a result long term you've made it HARDER to add pages to. In fact, the more pages you add, the less efficient and more bloated it's going to get. You've cocked it sideways with card-stacking.

It might spit out the same markup, but on the back end you're leaving the ability to do anything of value high and dry.

You continue this "design pattern" it's going to be an utter ****-show by the time you get to having database and user-actions. Particularly given the lack of separation of concerns.

[benanamen]

I guess you missed this part

Keep in mind, it is a refactor of Squire 3. I would do do things a bit different on a clean write.

and the other posts where I clearly said it was just an architecture change with the same output as you already have. In any case it is still easily scaled up to a database and wouldn't require 28 pages for every database table. Which by the way you still haven't answered the elephant in the room...

*********************************************************************************
Jason, I have already "setup" your CMS. Will it in fact require 28 NEW files for each and every new table I add?

I added a suppliers table to the database. Please tell me the exact steps I need to be able  to add/edit/delete records from this table. I am not concerned with DB setup, the table already exists.
*********************************************************************************

All you've done is slapped it together as static markup,

All YOU had was static pages. I only refactored to output what was already there to do exactly what it already did. Nothing more.

It lays no groundwork for adding SQL integration

This is moot. Adding "SQL integration" is a nothing burger. A first week noob could add in any database functionality with no problem. Your implementation? Lol, even me with over 30 years experience isn't even sure how to add it with out a lengthy deep understanding of what you are doing or asking you for an explanation as I just did.

you've got ZERO provision for adding new pages without having to edit the index.php

Oh noes! I have to type a key & value into an array! A lot easier than having to create 28 pages for every DB table I add.

you've got that wasteful array that's only going to get worse the more pages you add.

That is not how I would do it on a real build but is similar so you would just say the same thing about that as well. It is pretty much how EVERY CMS does it (Except yours of course). We all already know your thoughts about other CMS's so no need for another rant about it.

Don't even get me started about how you have zero provision for proper friendly URI's since you're blindly using JUST that derpy array.

Seriously Jason? The URI can be anything you want it to be. Blindly? If your going to just blast out accusations how about backing up what you are talking about with a good explanation or a code example. Nobody knows what you mean by blindly. You can make whatever claims you want and I welcome it, but I have to insist you be clear about what you are saying, otherwise it is just meaningless hot air that doesn't help anyone.

You've gone far below the task complexity requirement of a CMS

I didnt make a CMS, I re-wrote what you did to do exactly what it already did.

if one were to scale this up it would illustrate what utter JUNK "routing" is... because having to manually edit the menu and that "routing" array just because you want another page? That's junk.

That is subject to debate. Wait, what?? "scale up"? What was all that hot air you were spewing about "scalability?"

Laugh is though, we're ALMOST on the same page since if that's your idea of routing, I'm just using the existence of sub-folders as my "route".

It routes, just as Paladin "routes", but it is not what would be considered a "Router" as one is commonly known to be. I used to do something similar to "sub-folders as my "route"" when I was a noob doing only procedural coding. There is nothing wrong with it. It just isn't OOP. In fact, I have a branch of my OOP CMS that I keep in sync that is the same type of thing as you are doing. I actually like it for the fact that I can just throw in a page and they "system" will automatically respond with the file matching the URL.

Really weird part though being I'm not 100% sure how one adds a new page to your system, since it seems to have zero separation of template from content.

Oh c'mon Jason! Serious? You really need an explanation? Okay..

Take your content page (Minus the header, footer, menu, & nav) and put it in the pages directory. In the index.php add a new key and value to the array. The key is whatever you want the URL path to be. The value is the actual name of the file you put in the templates directory. Now just go to the url path. Oh wowz, it works! I think you are just Coitusing with me on this.

Are you REALLY going to repeat the same markup for each and every joe blasted possible http error code?

Are YOU really going to create a separate text file for every "joe blasted" HTTP error when the server ALREADY handles HTTP errors on its own? I guess so because you did. You do know how servers work don't you?

And I really think you completely missed how/what the extra's even are / are for / are implemented

Yeah, you got me there. I have no clue. I have also never seen anything like it, so congratulations I guess. If you are having to constantly explain how things work even to experienced programmers, you are probably doing something wrong.

you've made it HARDER to add pages to. In fact, the more pages you add, the less efficient and more bloated it's going to get

Really? I just explained the TWO steps to adding a page. That is harder? Bloated?  A key/value for a page is bloated? Coming from "Mr. I have to create 28 new files that are scattered throughout multiple folders for every DB table I add". Now THAT is bloated!

It might spit out the same markup, but on the back end you're leaving the ability to do anything of value high and dry.

Now your just spewing unsupported nonsense. Anything can easily be added and very simply at that.

You continue this "design pattern" it's going to be an utter ****-show by the time you get to having database and user-actions.

Yeah, NO! More unsupported hot air. It would be so simple it is not even funny.