CUTCODEDOWN
Minimalist Semantic Markup

Welcome Guest
Please Login or Register

If you have registered but not recieved your activation e-mail in a reasonable amount of time, or have issues with using the registration form, please use our Contact Form for assistance. Include both your username and the e-mail you tried to register with.

Author Topic: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.  (Read 4543 times)

benanamen

  • Full Member
  • ***
  • Posts: 160
  • Karma: +14/-0
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #15 on: 13 Nov 2020, 08:21:50 pm »
I was going to suggest exactly this. There are a few things in the implementation I wanted to discuss.

In several Php files you have

Code: [Select]
; <?php die(); // prevent direct calls just in case
This doesn't block direct calls. If you could directly access the file you would just get an error. The die never executes. In fact, you don't even get past the starting semi-colon.

Your comments...
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #16 on: 13 Nov 2020, 08:29:57 pm »
In several Php files you have

Code: [Select]
; <?php die(); // prevent direct calls just in case

If a direct call does occur it does die. Why? Because the file is labelled .php and it immediately <?php die()'s. The only thing output if it is called directly is a semi-colon and a space, preventing the comments of the .ini from being output by a http request!

The semi-colon is only a comment in .ini files, so that line with the die is ignored during parse_ini_file, NOT when you call it directly.

Think about it. When called as .php via a direct http call it dies. When called via parse_ini_file the php is ignored because it's inside a ini file comment.
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

benanamen

  • Full Member
  • ***
  • Posts: 160
  • Karma: +14/-0
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #17 on: 13 Nov 2020, 08:37:15 pm »
Ok, I inadvertently left an opening <?php that my editor writes by default and pasted your code after it. Derp!
« Last Edit: 13 Nov 2020, 08:40:38 pm by benanamen »
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #18 on: 13 Nov 2020, 08:51:22 pm »
Aren't vanilla, framed, landscape and discs classes presentational concepts that have no place into HTML? since HTML describes what things are and not how they look.
*DING*DING*DING*DING*DING* we have a winner.

That template is actually an experiment and part of another project. Squire itself has little to do with the markup or CSS being output here. I thought I made that clear enough; guess not.

The experiment in question is to see if I can make a HTML/CSS framework that minimizes the damage done by the concept. These frameworks INHERENTLY use presentational classes, but if the other problem; endless pointless classes for nothing in the markup, non-semantic markup, gibberish markup by people unqualified to write a single blasted line of HTML (see bootstrap), and so forth could be reigned in, how bad would the result be?

I think I'm ok with a few semi-presentational classes that describe the overall concept of the layout, without coming right out and saying "box-shadow text-center" and so forth. It's not saying what "frame" is... is it a border? Is it a box-shadow? Is it a different coloured background? It's just saying that it MIGHT receive "a" style, not what that style "is".

Though "disc" and "porthole" obviously go above and beyond that.

One of the reasons I'm so oft able to stick the knife in and twist where it hurts the most, is I often che-checkity check myself by actually trying the methodologies, or attempting to find compromises and middle grounds, if for no other reason than to make sure I'm not full of shit and my conclusions are sound.

It always feels like there SHOULD be a middle ground, a compromise. I'm still testing and playing so I'm not sure this is viable, but I will say that having all those different layouts based on this single unified markup:

Code: [Select]
<section class="cards">
<h2>Default Cards</h2>
<p>
<code>class="cards"</code>
</p><p>
The default behavior for cards is pretty simple.
</p>
<div class="inner">
<section>
<h3>Heading</h3>
<p>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed purus mauris, porttitor eu diam euismod, vestibulum condimentum velit. Fusce pellentesque purus et vestibulum ultricies. Donec sollicitudin consectetur finibus. Quisque malesuada fringilla eros eget maximus. Nunc ornare a mauris sit amet tristique. Integer varius sed lectus quis suscipit. Phasellus sed molestie eros. Vestibulum ut neque vel metus rutrum ultricies.
</p>
<ul class="controls">
<li>
<a href="#">
View Details
<i class="fas fa-angle-double-right"></i>
</a>
</li>
</ul>
</section><section>
<h3>Heading</h3>
<p>
Sed egestas metus in auctor bibendum. Ut gravida ligula a diam gravida, non convallis nisl lacinia. Sed at lorem ex. Quisque maximus ex vel odio malesuada, ut venenatis massa posuere. Nulla eu turpis blandit, varius ligula eu, elementum nisi. Vestibulum nec posuere purus, ut condimentum nulla. Pellentesque lorem ipsum, eleifend vitae vulputate eu, scelerisque sed elit. Pellentesque at malesuada nulla, quis fermentum magna.
</p>
<ul class="controls">
<li>
<a href="#">
View Details
<i class="fas fa-angle-double-right"></i>
</a>
</li>
</ul>
</section><section>
<h3>Heading</h3>
<p>
Morbi lobortis, lacus a dignissim iaculis, dolor massa ultrices augue, id maximus nunc quam pulvinar nulla. Suspendisse arcu augue, aliquam vitae ultrices ac, venenatis a mi. Ut erat ex, tincidunt et sagittis nec, pharetra eget odio. Nunc porta risus augue, nec consectetur nisi rhoncus sed. Donec vel sapien eu lacus volutpat blandit. Nam porta elementum ante nec efficitur. Maecenas ultrices sed mi ac tincidunt.
</p>
<ul class="controls">
<li>
<a href="#">
View Details
<i class="fas fa-angle-double-right"></i>
</a>
</li>
</ul>
</section>
<!-- .inner --></div>
<!-- .cards --></section>

Where all I have to do is change the outermost element's classes has a lot of appeal.

That's the compromise I'm trying to find to try and make a framework that doesn't COMPLETELY suck. It's going to suck in a specific way, but if I can isolate that suckage to a single container for each section, perhaps I won't have to tell the whole concept to suck it.

I'm TRYING to be open to the concept. Even if I've railed against it for a decade and a half. I do this every five or six years since big ****s in your *** are bad for your health.

And there is appeal, I mean look at the difference between the above subsections, and an image one:

Code: [Select]
<section>
<picture>
<source srcset="/paladin3/images/avatars/curly.webp" type="image/webp">
<img
src="/paladin3/images/avatars/curly.jpg"
alt="Curly Howard"
loading="lazy"
>
</picture>
<div>
<h3>Curly Howard</h3>
<p>
The funniest of them all
</p>
</div>
</section>

All that gets added is the picture/img and a DIV, the wrapping parent section getting a different class, and done. The semantics does the heavy lifting without the flaw of throwing endless mindless stupid dumbass presentational classes at everything.

TRYING to find that safe middle ground between the ideal and what/how "normies" want it to work.

That make any sense, or am I wasting my time trying to be a bit less radical about it?
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #19 on: 13 Nov 2020, 08:52:05 pm »
Ok, I inadvertently left an opening <?php that my editor writes by default and pasted your code after it. Derp!

Happens to the best of us... frequently.
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

John_Betong

  • Full Member
  • ***
  • Posts: 209
  • Karma: +21/-1
    • The Fastest Joke Site On The Web
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #20 on: 14 Nov 2020, 12:42:19 am »
In several Php files you have

Code: [Select]
; <?php die(); // prevent direct calls just in case

If a direct call does occur it does die. Why? Because the file is labelled .php and it immediately <?php die()'s. The only thing output if it is called directly is a semi-colon and a space, preventing the comments of the .ini from being output by a http request!

The semi-colon is only a comment in .ini files, so that line with the die is ignored during parse_ini_file, NOT when you call it directly.

Think about it. When called as .php via a direct http call it dies. When called via parse_ini_file the php is ignored because it's inside a ini file comment.

Is there any reason that the "system files " are not installed above the root similar to the majority of modern PHP Frameworks and CMSs?

I find that using a PHP extension as a INI file is tremendously confusing.

Does this apply to all PHP named files with a leading ;
« Last Edit: 14 Nov 2020, 12:43:55 am by John_Betong »
Retired in the City of Angels where the weather suits my clothes

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #21 on: 14 Nov 2020, 08:19:03 am »
Is there any reason that the "system files " are not installed above the root similar to the majority of modern PHP Frameworks and CMSs?
Excellent question... and in general the answer is that said practice is mostly placebo nonsense.

1. The rewriterule prevents direct access to files not on its whitelist. ANYTHING not on the approved list of directorys or extensions is rerouted to index.php

https://cutcodedown.com/for_others/squire3/live/template/default/common.template.php

The file is there, but it 404's because that's not a valid "Request".

Code: [Select]
RewriteEngine On
RewriteRule !(^(images|downloads))|(\.(gif|jpg|png|css|js|html|txt|ico|zip|rar|pdf|xml|mp3|mp4|mpg|flv|swf|mkv|ogg|avi|woff|woff2|svg|eot|ttf|json|webmanifest)$) index.php

If it's not on that list, and it's not a valid "Request", it will 404.

2. Most of the files output nothing if called directly, and the few that do contain no security or safety related actions. This "second ring" of protection is just good practice, and it's why the .ini file "die" is helpful as is that good practice of the majority of include() only containing functions and classes.

3) Anything that can access the files via non http methods can usually access it regardless of where you put it.

4) Many FTP logins do NOT give you access to directories above the HTTP root. It's increasingly less common, but by not trying to play that silly game it increases the audience and the hosting choices.

I find that using a PHP extension as a INI file is tremendously confusing.
It's a bit like banging your head into the wall. You get used to it. :P

More important though is to stop thinking about file extensions as just the LAST period onward. Indeed the proper behavior is supposed to be everything from the first period onward which is how a great many systems handle that. It's not a ".php" file, it's a ".ini.php" file.

Does this apply to all PHP named files with a leading ;
No, because you don't "parse_ini_file" other PHP files.

look in "/libs/common.lib.php" at the Settings.lib.php, these .ini.php are loaded via parse_ini_file, not readfile, include, or require.

It's a fun way to store data that http direct calls will bomb on... and with two rings of security there's no reason to crush portability by using that third silly method. Especially given the number of hosts where you might not even have access to create files above the http root.
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

fgm

  • Junior Member
  • *
  • Posts: 47
  • Karma: +5/-0
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #22 on: 14 Nov 2020, 08:32:08 am »
That template is actually an experiment and part of another project. Squire itself has little to do with the markup or CSS being output here. I thought I made that clear enough; guess not.
Oh, I came from To Route Or Not To Route - The Definitive Guide??? thread so I didn't read the first post. It's crystal clear now.

I really like a basecode to organize a website from scratch independently from the template used, and also the idea to offer an almost sane bootcrap alternative -- with or without Squire. Good job!
That make any sense, or am I wasting my time trying to be a bit less radical about it?
In my humble opinion, the use of section and nav bloat plus presentational classes like landscape somewhat defeat the pureness of HTML, but I suppose it's reasonable to achieve that middle ground as an starting point for developers accustomed to the typical frameworks.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #23 on: 14 Nov 2020, 09:52:09 am »
In my humble opinion, the use of section and nav bloat plus presentational classes like landscape somewhat defeat the pureness of HTML, but I suppose it's reasonable to achieve that middle ground as an starting point for developers accustomed to the typical frameworks.
Thing is where they are in the code are places that if I lacked them, I'd end up having to put DIV with classes from a layout perspective. As such they actually save me some code.

Though the "pureness" thing is why I dislike it... but something I'm always trying to remind myself -- and others -- of is it's not about ME. It's not about YOU. It's about trying to reach everyone.

And sometimes that means throwing even the best intentioned of rules in the trash. Even mine.

I honestly think that if I can meet the framework fanboys halfway, placing the emphasis on semantics and pre-constructed and uniform HTML structures, I might be able to drag them away from throwing classes at everything and using purely presentational classes like text-red or box-shadow.

Especially if I can show how much simpler the basic markup is.
« Last Edit: 14 Nov 2020, 09:53:46 am by Jason Knight »
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

benanamen

  • Full Member
  • ***
  • Posts: 160
  • Karma: +14/-0
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #24 on: 14 Nov 2020, 12:23:54 pm »
On the technical side... index.php line 76 you call

Code: [Select]
action_content($data);
and pass one parameter, $data. The actual function in test.content does not accept any parameters. Oversight?

While we are in test.content.php, why put what is nearly 100% html in a function and echo it out?
To save time, let's just assume I am never wrong.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #25 on: 14 Nov 2020, 03:03:44 pm »
and pass one parameter, $data. The actual function in test.content does not accept any parameters. Oversight?
Foresight.

When databases or dynamic sites are involved the various $startup will plug data into them to be shown. It's part of the separation of concerns.

Not all pages will use them, but the mechanism is provided irregardless.

For example, if we had BLOGS a single blog entry would be:

Code: [Select]
$data['action_blog_entry'] => [
  'title' => "Blog Titlte",
  'content' => "Your paragraphs of content and so forth"
];

Whereas

Code: [Select]
$data['action_blog_listing'] => [
  'title' => 'Directory Title',
  'stmt' => $stmt // the PDO statement linking to each of the blog entries
];

Note, I'll be extending PDO to allow for statements to be "locked", preventing their re-use if desired. part of preventing exposure of the interface to PHP execution in places it has no business like the template.
« Last Edit: 14 Nov 2020, 03:05:36 pm by Jason Knight »
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

John_Betong

  • Full Member
  • ***
  • Posts: 209
  • Karma: +21/-1
    • The Fastest Joke Site On The Web
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #26 on: 14 Nov 2020, 11:44:03 pm »
@Jason Knight,
I have uploaded Squire 3/ Paladin X.3 and also added another web-page and now concerned with future PDO changes...

When the PDO changes arrive will I have to install the complete project again and add my web-pages or will I be able to only add the "system files"?

I like the way the Github CodeIgniter Framework separates the System and Application files into two separate directories which simplifies essential security upgrades and improvements.

Are you considering a Github Squire 3/ Paladin X.3 repository?
« Last Edit: 15 Nov 2020, 12:18:21 am by John_Betong »
Retired in the City of Angels where the weather suits my clothes

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #27 on: 15 Nov 2020, 09:46:54 am »
When the PDO changes arrive will I have to install the complete project again and add my web-pages or will I be able to only add the "system files"?
The changes should be able to co-exist. There is one major change but so long as you've not messed with the index.php (which users of the system should treat as inviolate) it should be fine.

Right now what's there isn't true "Paladin", more a placeholder to show off the components of Squire. When it becomes Paladin -- since even most of the index.php gets moved into a main.lib.php and a main() instead of IIFE -- the existing functionality of /actions/ remains largely unchanged. Statics are statics, though one could move them out of being static files and into the DB.

I like the way the Github CodeIgniter Framework separates the System and Application files into two separate directories which simplifies essential security upgrades and improvements.
That involves having a separation of "system" and "application" which to me isn't where the line should be drawn or even a "thing" that should be. The two words mean the same thing to my mind so that separation just makes things HARDER, particularly upgrades and improvements.

The closest I get to that is the difference between library (system), actions (application?) and output.

Are you considering a Github Squire 3/ Paladin X.3 repository?
I don't GIT. I've watched it **** too many projects, let too many "project managers" sleaze by on not doing their damned jobs, and in general for anything simpler than an OS kernel it's a total and complete complexity mismatch. When a project has multiple workers is it so blasted hard to submit proposed changes to an actual flipping person who rides herd with accept/reject, and to set master code milestones via a lousy shell file or even just ^C^V?

I find GIT to be painful to use, painful to work with, and like a great many allegedly "useful" tools it just gets in my damned way! Hence why most people who use GIT seem to be a bit like eMacs wankers; they swaste ridiculous amounts of time dicking with the system that could have been better spent writing code! Like how people who program in eMacs spend more time dicking with macro's than doing anything useful.... and remember, I'm an assembler programmer, I know all about when and where macro's are useful.

Simply put, it doesn't fit my workflow, mindset, or methodologies. I can't work with it without the overwhelming urge to put my fist through the display.

But to be fair, there's a LOT of stuff in this industry people talk about being "easy", "simple", or "better" when it comes to tools or methodologies, where I honestly have ZERO huffing clue what the **** people are talking about. From convoluted train wreck messes like version control and "programming models", all the way down to simple stuff like colour syntax highlighting, code completion, and tabbed editors. For me many of these things take the simplest of tasks and make them as painful and difficult to do as possible. Typically because the people who CREATED this stuff weren't qualified to write software in the first place.
« Last Edit: 15 Nov 2020, 09:52:03 am by Jason Knight »
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #28 on: 15 Nov 2020, 09:53:36 am »
Oh, and for the curious, the new index.php when it becomes paladinX

Code: [Select]
<?php

/*
index.php
Paladin X.3 (Squire 3.0) "one index to rule them all"
Jason M. Knight, November 2020
*/

include('libs/main.lib.php');

main(
'mysql:dbname=paladinx.3;host=localhost'// dsn
'paladinTesting'// username
''// password
[
PDO::ATTR_EMULATE_PREPARES => false,
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC
]
);

The index itself becomes a config file for the DB.
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 791
  • Karma: +143/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Squire 3 / Paladin X.3 -- Rebuilding from the ground up.
« Reply #29 on: 15 Nov 2020, 10:48:26 am »
Alright, before I start showing the database stuff, I really want to talk about the architecture of this system. Sadly I've not been able to devote a lot of time into this the past week because, well... this is basically the equivalent of a normal client project, just without the paying clients. Guess who takes precedence.

Being Sunday and waiting for a client to get back to me which won't happen 'til tomorrow, I've got all day for this. Maybe I should mark Sunday as my day to work on this full time? A number of you seem enthused and interested, and it seems as good a hobby project as any to turn into a full blown CMS for the "normies".

Now, I do these types of file by file function by function breakdowns EVERY time I write a system like this, as not just a reference for myself and others, but as part of my debugging and refactoring process. It's amazing how often I'll find mistakes just by doing this.

The general architecture for this closely matches how PHP and HTTP requests work. HTTP is request driven, the request is our event. The HTML once CLIENT SIDE is what some programming models would consider the "view", where server side it's just "output". This is where IMHO MVC is a complexity mismatch as it tries to shoe-horn server side only many concerns that have no business on the server.

Hence if one were to make a cutesy acronym that sums up this programming model, it would be IPO.

Input > process > output

"Input" we figure out what the user wants or is trying to do, "process" we perform those actions and gather up any resultant data, then on "output" we glue those results to markup. Some "output" control -- session creation, gzip handling, and so forth -- ends up before input processing just as a safety precaution and so if we need to set things like headers or cookies during "input" or "process" we can.

When it comes to process, the overall concept is that we use the directory system to map user request handlers. Because the "one index to rule them all" is powered by this rewriteRule: (which could be considered part of "input")

Code: [Select]
RewriteRule !(^(images|downloads))|(\.(gif|jpg|png|css|js|html|txt|ico|zip|rar|pdf|xml|mp3|mp4|mpg|flv|swf|mkv|ogg|avi|woff|woff2|svg|eot|ttf|json|webmanifest)$) index.php
Only files in the two directories (images | downloads) and files with the above extensions are allowed to be served normally. ANY request that doesn't match either of those patterns is routed to our index.php where the requested path is parsed out of $_SERVER['REQUEST_URI']

With that in mind, let's just summarize files and each of their subsections.

/index.php -- the main user call.


Note that what much of this file does is part of Squire, the file itself is not. It's just stuff I copy/paste in to wherever is appropriate for the turnkey solution.

Code: [Select]
// before we do ANYTHING else, let's set up gzip compression
foreach (['gzip', 'x-gzip', 'x-compress'] as $type) {
if (strpos($_SERVER['HTTP_ACCEPT_ENCODING'], $type) !== false) {
ob_start('ob_gzhandler');
ob_implicit_flush(0);
header('Content-Encoding: ' . $type);
register_shutdown_function(function() {
ob_end_flush();
});
break;
}
}
Blindly starting the gzip compression without manually setting the content-encoding can cause pages to load broken, same for trying to set this from php.ini or httpd.conf. By checking for all three possible compression types we actually can deliver gzipped to more UA's (IE, Konqueror, Blazer) than simply starting ob_gzhandler can handle, and it dodges the issue where Yandex will occasionally not index PHP pages that don't support x-compress as a parameter.

It's just better to manually start it and explicitly ob_end_flush with a shutdown handler.

Have you ever noticed that if you ob_start the zip handler, then try to DIE or PHP outputs an error, the gzip compression ends up mangled and you get a gibberish page? That's what registering a shutdown function to end the buffer accomplishes.

... and by starting output buffering as our first thing, we can header() or set cookies until blue in the face regardless of when/where in the code; even after we have output!

Code: [Select]
session_start();
/*
regenerating the ID on every pageload reduces the time window
in which a session key can be exploited for MITM attacks.
*/
session_regenerate_id();

I'd hope you folks would know what that does by now. I imagine the comment helps. :D

Code: [Select]
/*
prevent displaying site in frame. Some people will say do this
in the httpd.conf or other server config, it takes NO processing
difference here, it's easier to say do it only for our single
entry-way from here, I prefer not to put something this important
outside our portable code, and it's better not to make assumptions
about what server software is in use. Not everyone uses Apache.
*/
header('X-Frame-Options: DENY');

I know a LOT of dev's will say "don't do that from the php" -- why? PHP is going to run anyways, it can set headers, it takes no more processing time -- in fact it can take LESS because we don't need a regex to not blanket apply it from the config files -- and putting it in our single entry point is just simplest.

I see a lot of people get their panties in a knot over using header() for anything but redirects which is funny, I'm the exact opposite. I hate redirects and avoid them whenever possible.

Code: [Select]
/*
Load functions and methods common to all pages
*/
include('libs/common.lib.php');
Speaking of bad commenting practices, did I REALLY have to explain that?

Code: [Select]
/*
Many settings are loaded from ini as the setter and are
only retrievable with a getter.
*/
Settings::loadFromIni(
'default.ini.php',
'user.ini.php'
);
The Settings static object comes from common.lib.php. It can load settings from ini files or directly set them. Values from ini files cannot be directly overwritten, though when it becomes Paladin that will change... slightly. Paladin uses a more complex flavor of this same routine. For now just know that these ini files values are being loaded.

Code: [Select]
define(
'TEMPLATE_PATH',
'templates/' . (Settings::get('template') ?: 'default') . '/'
);

There's an old saying, use define... a lot. No, A LOT!

The template path is a perfect candidate for this. We will need it all over the codebase, it can be handy inside the template itself since our URI's could be almost anything, so let's set it. Once we get to Paladin this value will likely be changed to TEMPLATE_DEFAULT_PATH since the user may have their own value. Multi-skinning -- like most forums offer -- being an essential part of our structure.

Code: [Select]
templateLoad('common');
Loads TEMPLATE_PATH . 'common.lib.pgp' using require_once. See common.lib.php for more. It's just easier to have a function for a method that we call not just here, but inside actions as well. Some actions might need the forms.template.php, others might have their own.template.php.

Note that template_load actually checks for if the file exists in TEMPLATE_PATH, but then also an optional
$action_path parameter. This allows actions to contain their own default template separate from the system one, letting actions be modular. When making separate templates everything falls back on the default or the action. We'll talk about that more in the common.lib.php discussion.

Code: [Select]
/*
IIFE to isolate scope, so a code appendage can't see anything
we want to keep local here just in case. Thankfully PHP now has
proper IIFE
*/
(function() {
Comment says it all. This will become main() in the proper "paladin" system.

Code: [Select]
$action = Request::value();
if (!$action) $action = 'static';
if (!is_dir('actions/' . $action)) httpError(404);
$actionPath = 'actions/' . $action . '/' . $action . '.';
safeInclude($actionPath . 'startup.php');
$data = action_startup();
template_header($data);
if (file_exists($fn = $data['contentFilePath'] . '.content.php')) {
safeInclude($fn);
action_content($data);
}
if (file_exists($fn = $data['contentFilePath'] . '.static')) readfile($fn);
template_footer($data);

We set our $action to be included, reverting to "static" as the default if none is found. We 404 if there's no corresponding action (see httpError in common.lib.php), otherwise we include the startup file.

Startup files are our "process". A normal process handler will return $data to be output (if any) including the "contentFilePath", which can be a PHP file that performs output logic, or a static file, OR BOTH! Note that statics are always loaded after PHP driven content.

The template is auto-added as appropriate. Note that some PROCESS may call the template themselves and then die() for the handling of special cases such as errors.

In a full Paladin system I often condense down httpError  and so forth to methods on a "Bomb" static that also calls error_log.

Alright, gimme a few and I'll do the same for common.lib.php
I'll fix every flaw, I'll break every law, I'll tear up the rulebook if that's what it takes. You will see, I will crush this cold machine.

 

SMF spam blocked by CleanTalk

Advertisement