SimplePortal
Development => Feature Requests => Topic started by: Chen Zhen on April 11, 2016, 09:20:31 AM
-
Many scripts for blocks require style sheets and/or js files (ie. jQuery plugins & libraries) to be loaded within the <head> of the document.
Although js files can be added in the body it is not standard practice to do.
However for css files this is mandatory.
I propose a single PHP input (similar to the PHP block textarea) to be put at the very top of the block list.
Allow globals & html content to be added to $context['html_headers'] so that it can be executed in the head of the document.
If it is html content only then globals can not be used and the admin will be forced to add whole url's and restricted/lengthy content.
This is why I suggest PHP execution.
It can be executed at the start of the sportal_init() function in Subs-Portal.php.
Current block content is executed in the body of the template where $context['html_headers'] has already been used in the template.
-
Not as techy as you, but I like the idea.
-
As far as I remember (unfortunately it's been a while since I touched the code so I may be wrong), SP (similarly to most if not all the other portals) have the "bad habit" of running the blocks code directly "in place" while the page is generated, in other words when the code of a block is executed, anything in the template before that block has already been echo'ed to the buffer.
This approach is for sure the easiest and the one that gives end-users the fastest approach to writing their code in a block: 1) grab stuff, 2) do something, 3) echo anything.
The drawback, it that the way it is now, it's impossible doing some stuff (like adding css to <head>) without hooking the buffer into the block (this is possible, a bit ugly but definitely possible).
To solve this problem (and few others alike), each and every block (php blocks as well, don't forget that because I'll come back on the point later) needs to be composed of two parts: the "code" and the "template". This is the path I'm taking with the changes I did a while ago to the ElkArte port of SP.
It's not a terribly huge task, surely a tedious one, potentially a problematic one for non-tech-savvy users, especially when it comes to php blocks.
Why, you ask?
Obviously because anyone has to adopt the "MVC" mentality of "preparing" all the data needed for the output in a place, and use it in another. Once grasped it's not at all a bad thing, though it's another piece of "junk" to each to people that want to write "a simple php block".
Of course there are alternatives (i.e. run the code before sending out the template, instead of using "echo" build a string and return it) that may be better suited, anyway, changes are needed, and changes that will break any currently existing block (unless you pick up yet another (ugly) path, creating the block "source-side", capture the partial buffer created by the block, clean up the buffer, and return the block output).
-
Actually my idea is a bit simpler as far as modifying the existing process that SP uses.
I meant just to add 1 single option at the top of the block list (or perhaps from the settings menu) that allows one single php block input specifically to be executed prior to any output. The Admin would have to understand that using echo at that point would break the template and that only filling variables (ie. $context['html_headers']) is what it is made for (ie. warning in red at the top).
-
i.e. introduce another special case instead of actually fix the behaviour? :P