Forums

Unfortunately no one can be told what FluxBB is - you have to see it for yourself.

You are not logged in.

#1 2015-06-08 11:53:23

micbr
Member
Registered: 2014-05-23
Posts: 58

FluxBB + Plates Templating

Like most members here still involved with FluxBB development, I've been thinking about separating the core logic from the interface templates. I remembered a post by Franz back in March in which he mentioned Plates, a PHP-based templating library that could serve as the engine for loading and processing template files within FluxBB.

I should mention that I have a tendency for taking on projects that are well outside of what my knowledge can handle. I decided to write a piece of Mac software several years ago with no prior knowledge, and that's how i learned REALbasic. What better way to expand my knowledge of PHP than to start in the deep end?

Without further ado, lets write some (probably terrible and completely clueless) PHP.


I've included the Plates package in includes/classes/League/Plates and autoloaded it inside include/common.php. Template files are stored as .tpl files inside the include/templates folder, where template files currently reside in FluxBB 1.5.x. The aim is to expand on the template files inside this folder, having separate files for either individual pages (index, viewforum, viewtopic, etc) or common components (header, footer, table_list, table_posts, etc) depending on whatever solution proves to be more elegant to work with.

The most common way to include Plates within the project is to use Composer. I haven't done this since I have no experience with Composer and this is FluxBB - the aim is to have only files that are absolutely necessary in the project folder.

A new Plates instance is called within the page itself (index.php), however this could also be called inside common.php since it should be consistent between pages.

What I have so far is a basic example of how this would look within a FluxBB install. The filesystem layout looks something like this:

Screen_Shot_2015_06_08_at_9_11_49_pm.png


The contents of the example PHP files are like so:

index.php

<?php define('PUN_ROOT', dirname(__FILE__).'/');

require PUN_ROOT.'include/common.php';


// Create new Plates instance
$templates = new League\Plates\Engine(PUN_ROOT.'include/templates', 'tpl');

// Check if Template File Exists
if ($templates->exists('welcome')) {
   
	// Template File Exists, Render
	echo $templates->render('welcome', ['name' => 'ExampleUser']);
   
} else {

	// Template File Doesn't Exist, Error
	echo '<b>ERROR:</b> Template File <i>welcome</i> Not Found.';

} ?>

A new Plates instance is created with the source directory set to PUN_ROOT.'include/templates' and the file type set as .tpl. The directory is checked for the presence of the template file, which in this example is called welcome.tpl, and if it is found it is rendered. An example variable called "name" is set with a value of "ExampleUser" to show that it is being successfully rendered with dynamically generated content.


include/common.php

<?php 

// Temporarily Enable Error Reporting
ini_set('display_startup_errors',1); 
ini_set('display_errors',1);
error_reporting(-1);

// Add the paths to the class directories to the include path.
set_include_path(PUN_ROOT . 'include/classes/');

// Add the file extensions to the SPL.
spl_autoload_extensions(".php");

// Register the default autoloader implementation in the php engine.
spl_autoload_register();

?>

This is rather simple. The class directory is added to the include path. In this case the classes are stored at PUN_ROOT.'includes/classes/'. Whenever a new instance is created, it checks this directory for the necessary class files.


It works, or at least the example does.

Screen_Shot_2015_06_08_at_3_35_31_am.png
Screen_Shot_2015_06_08_at_3_36_30_am.png


Doing some more extensive things with this engine such as rendering the headers and footers or even the forum index is something I would like to explore next.

From what I have so far, how does it look to our members that are more knowledgeable about PHP? Am I making a terrible mistake for a reason I haven't considered or does it look good so far? Are there any issues I should be aware of? I'm literally learning some of this stuff as I work on it, so apologies in advance if my eyes glaze over reading some of the responses.


Cheers,

~ micbr.

Last edited by micbr (2015-06-08 12:08:43)


Administrator, ThinkClassic - A vintage computer community.

Offline

#2 2015-06-08 13:17:05

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: FluxBB + Plates Templating

I've never head of plates before but it sounds interesting.

P.S. your site looks great!

Last edited by eric235u (2015-06-08 13:17:21)

Offline

#3 2015-06-09 11:49:32

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,677
Website

Re: FluxBB + Plates Templating

Plates is cool, and I'm all for a template language, I strongly argue against using a PHP-based one, though:
One of the biggest benefits of template systems is that you can secure yourself easily against XSS attacks (through escaping content by default). You cannot do that easily with PHP templates, which is why even the library's creator stresses that automatic escaping is more important than any benefit a PHP template library could bring.

Twig seems to be the most popular option these days...


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#4 2015-06-09 14:16:44

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: FluxBB + Plates Templating

Fascinating.  I'll check out the slides.

Last edited by eric235u (2015-06-09 14:32:46)

Offline

#5 2015-06-09 15:29:44

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: FluxBB + Plates Templating

This is probably going to show incredible ignorance but I don't see the need for a templating system for a very small project such as FluxBB.  It adds another layer of complexity or abstraction that isn't needed.  For a larger project I would agree with separation.  But in the end its up to who writes the code and makes the commits.  I have no super strong opinion on it.  :p

Last edited by eric235u (2015-06-10 13:31:43)

Offline

#6 2015-06-09 15:37:11

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: FluxBB + Plates Templating

micbr wrote:

I decided to write a piece of Mac software several years ago with no prior knowledge...

Very cool.  I just taught myself how to package .app and read through the Swift manuals in the last couple of months.  Fun stuff!

I just reread your first post, very well done.  Maybe this should be considered for use in the next release of 1.5.* if there is one?  There's another thread where community members are kicking around ideas and you have actually done some work.

Offline

#7 2015-06-09 15:58:03

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,677
Website

Re: FluxBB + Plates Templating

I don't think the 1.5 series would be a good place for such large changes, but I'd be very much in favor of a template system for 1.6 (if people step up and make that happen).


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#8 2015-06-09 21:39:13

Askelon
Member
From: Bretagne − France
Registered: 2010-06-09
Posts: 202
Website

Re: FluxBB + Plates Templating

eric235u wrote:

This is probably going to show incredible ignorance but I don't see the need for a templating system for a very small project such as FluxBB.  It adds another layer of complexity or abstraction that isn't needed.

Oh yes, it's very much needed. Long story short: using a dedicated template system means we separate the views from the logic, which allows us to 1) customize views much more easily (develop much more interesting themes and styles) and 2) implement better ways to build new features (the long awaited hooks). It sure adds a new layer, but it's a very good and useful one.

Offline

#9 2015-06-10 08:13:45

micbr
Member
Registered: 2014-05-23
Posts: 58

Re: FluxBB + Plates Templating

Franz wrote:

Plates is cool, and I'm all for a template language, I strongly argue against using a PHP-based one, though:
One of the biggest benefits of template systems is that you can secure yourself easily against XSS attacks (through escaping content by default). You cannot do that easily with PHP templates, which is why even the library's creator stresses that automatic escaping is more important than any benefit a PHP template library could bring.

Twig seems to be the most popular option these days...


I've downloaded Twig and could probably see if I could integrate it in the same way as Plates. In comparison Twig doesn't seem to be as lightweight as Plates, and even its installed size on the filesystem is noticeably larger (90KB for Plates, 900KB+ for Twig). It does look like the benefits outweigh the massive increase in size though, with automatic escaping and the syntax does seem fairly simple.


Ultimately I would like to work toward stripping the HTML out of the core files and moving it into separate template files stored in include/templates, following the same naming scheme as the core files (index.tpl, viewforum.tpl, etc). The template files would be loaded from here by default unless a template file with an equivalent name is stored within the directory for the currently installed style (so style/Air/templates/viewforum.tpl would take precedence over include/templates/viewforum.tpl).

As it currently stands, I don't intend to change the layout of the HTML itself. Just moving across the current HTML from FluxBB 1.5 into templates. The current stylesheets shouldn't need to be modified extensively to make them work.

Template Hooks would be nice as well, so a FluxBB extension can extend a template and add some additional UI elements for extra features (like displaying information in the footer, for example). This is something I have absolutely no idea how to implement and don't know where to begin. Could be something worth having a second set of eyes on to see if we can figure this one out.


I forgot to mention that in terms of FluxBB itself, I've started building around the current snapshot from Github (1.5-next) and have incremented the version number to 1.6.0 since I tend to agree that such changes are too grand for a version in the 1.5.x branch. It's also been established in other threads that a change as extensive as moving to a template system will break most modifications that have been built for the 1.5.x branch. I can't find an elegant way around this other than to continue supporting 1.5.x until such a time that enough extensions have been updated to take advantage of the new system (similar to phpBB's transition from 2.x to 3.x or 3.0.x to 3.1.x).

Last edited by micbr (2015-06-10 08:21:12)


Administrator, ThinkClassic - A vintage computer community.

Offline

#10 2015-06-10 08:54:54

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,677
Website

Re: FluxBB + Plates Templating

The problem with making templates overridable per style is that that would mean that modifying the templates (through mods etc.) would not be allowed anymore (because there's no way to sync these changes to the overwritten templates).

So we would need template hooks indeed.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#11 2015-06-10 10:29:49

GWR
Member
From: Germany
Registered: 2010-08-06
Posts: 214

Re: FluxBB + Plates Templating

I assume most template engines allow triggering methods : $this->methodName().

As Methods could get overridden it is just needed to either:
- get methods injected by mods/hooks
or
- have some generic method taking care of unknown methods and emitting "hooks" for it.

So when calling $this->hook("bla") this could run the "fluxbb-specific" function "templateobject::hook" which runs the fluxbb-hook-function.


If you want to have "fluxbb mods" takeover templates at all, you will have to use some kind of custom template or to pass the template engine modded content.

$templateData = GetTemplateContent("bla");
$templateParams = ["title"=>"Page Title"];

//emitHook must accept the param as reference to enable modification
//else you must do casting as the emitHook surely just returns a generic object
emitHook("templatebla", ["data"=>$templateData, "params"=>$templateParams);

RenderTemplate($templateData, $templateParams);

Done something similar for a custom CMS. In this case the hooks triggered website-theming-specific addons (was vor VW/Audi-Seller-Websites having to care special models are not visible in all cases or to display certain logos).

If done properly, that "GetTemplateContent" does not need to get "pre-rendered" or so to handle "child-templates/partials" - they just call the same function and trigger their own hooks.

Like I suggested some weeks ago when hooks were discussed, this needs passing data to the hooks. As you do not have threading in PHP you could also store everything in a "hookData"-Global ...



bye
Ron

Last edited by GWR (2015-06-10 10:30:54)

Offline

#12 2015-06-10 13:44:53

eric235u
Member
From: free software land
Registered: 2008-05-10
Posts: 132
Website

Re: FluxBB + Plates Templating

Askelon wrote:
eric235u wrote:

This is probably going to show incredible ignorance but I don't see the need for a templating system for a very small project such as FluxBB.  It adds another layer of complexity or abstraction that isn't needed.

Oh yes, it's very much needed. Long story short: using a dedicated template system means we separate the views from the logic, which allows us to 1) customize views much more easily (develop much more interesting themes and styles) and 2) implement better ways to build new features (the long awaited hooks). It sure adds a new layer, but it's a very good and useful one.

I'm just worried about bloat.  I like a very small surface area.  Nevertheless your point is a good one.

Offline

#13 2015-06-13 17:52:42

micbr
Member
Registered: 2014-05-23
Posts: 58

Re: FluxBB + Plates Templating

I've started attempting to build an example with Twig and it should be said that while I like the template syntax, it's taking some additional effort to make it work. There's also a steeper learning curve involved which is slowing me down.

If this code were to be used exclusively on my own website where I know we're strict about auditing our own code and know at least the basics of PHP, I would choose to use Plates and manually escape variables. The main reason I'm looking at Twig at all is because we're aiming for a common goal to build a new release of FluxBB and once it is made available to the public and third party templates are made available for it, automatic escaping becomes important to maintain security.

I intend to continue working on this but it isn't simple, especially for someone relatively new to PHP like myself, and it's dependent on allocating time to it in between classes, assignments and some other things at the moment.


Administrator, ThinkClassic - A vintage computer community.

Offline

#14 2015-06-13 18:05:43

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,677
Website

Re: FluxBB + Plates Templating

Thanks so much for looking into it! Is your work public somewhere on GitHub?


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#15 2015-06-14 12:04:50

micbr
Member
Registered: 2014-05-23
Posts: 58

Re: FluxBB + Plates Templating

Franz wrote:

Thanks so much for looking into it! Is your work public somewhere on GitHub?

Nothing on there yet. I haven't used GitHub before but I hope to find some time to learn how to use it. Then I'll start throwing what I have on there.

Here's the current example code I have though.

https://app.box.com/s/tbwwydnw2u8or2l9g5jhpqpehse35orp

Download, Open and move to a web server. No installation required.


This is only an example, it doesn't actually do anything so far. It does however follow the same file names and directory structure as FluxBB and shows what code is required in each file to implement some basic Twig functionality. It loads .tpl files from both include/templates and style/(current_theme)/templates with the style directory taking precedence, just like FluxBB 1.5 does already. It uses some existing FluxBB variables (pun_user, pun_config, languages, forums, categories, etc) to produce a replica of the FluxBB index using that information combined with Twig.


Screen_Shot_2015_06_14_at_9_34_53_pm.png


It's intended to show how Twig could in theory be integrated into FluxBB 1.6. The HTML itself hasn't changed, so existing styles work fine with it (as a matter of fact, "Air" in the demo is completely unmodified). The Languages are also mostly unmodified (the %s has been removed from some of the strings as I'm using Twig to handle all formatting and output) and I've included stripped down versions of the language files for demonstration purposes.

A sample set of data has been included. It's loaded from example/data.php. Some values like time and date values are hard-coded because it would have required too much work to implement it for the purposes of this example. The same goes for the QuickJump box.

Take a look inside header.php as well. I've rewritten the code that generates the forum navigation links to take advantage of the template engine (coupled with include/templates/header.tpl). I left some of the old, commented out lines for generating navlinks there so you can compare them side-by-side.

Hopefully it should be sufficient to get a feel for what can be done with an upgrade to the existing FluxBB codebase. I don't believe a total rewrite would be required, but a decent amount would need to be updated to take advantage of the template engine in its entirety. Existing functions, queries and most of the data handling code could be retained, but almost everything responsible for output needs to be looked at and rebuilt. It would be a time-consuming task (this example alone took around 6-7 hours) but certainly not impossible.

Last edited by micbr (2015-06-14 14:01:23)


Administrator, ThinkClassic - A vintage computer community.

Offline

#16 2015-06-16 16:18:59

micbr
Member
Registered: 2014-05-23
Posts: 58

Re: FluxBB + Plates Templating

So, I've started moving some of the work from the example into an actual FluxBB install, calling the Twig autoloader in include/common.php and I've started integrating it into header.php. It's working - I can generate output and have Twig render it just fine.

But this experiment has left me with a couple of questions.


First of all, how much separation between the logic and template should there be? I suppose ideally we would have all HTML in templates and only PHP in the core files, but there's a couple of potential grey areas here, particularly in the page headers. Here is one such example:

index.php, Line 54

if ($pun_config['o_feed_type'] == '1')
	$page_head = array('feed' => '<link rel="alternate" type="application/rss+xml" href="extern.php?action=feed&amp;type=rss" title="'.$lang_common['RSS active topics feed'].'" />');
else if ($pun_config['o_feed_type'] == '2')
	$page_head = array('feed' => '<link rel="alternate" type="application/atom+xml" href="extern.php?action=feed&amp;type=atom" title="'.$lang_common['Atom active topics feed'].'" />');

header.php, Line 150

if (!empty($page_head))
	echo implode("\n", $page_head)."\n";

$tpl_temp = trim(ob_get_contents());
$tpl_main = str_replace('<pun_head>', $tpl_temp, $tpl_main);
ob_end_clean();
// END SUBST - <pun_head>

// Start Twig Output
echo $tpl_file->render(array(
	'lang_common'		=>	$lang_common,
	'pun_user'			=>	$pun_user,
	'page_title'		=>	$page_title,
	'page_head'			=>	(!empty($page_head) ? $page_head : ''),
	'PUN_ALLOW_INDEX'	=>	(!defined('PUN_ALLOW_INDEX') ? false : true),
	'PUN_ADMIN_CONSOLE'	=>	(defined('PUN_ADMIN_CONSOLE') ? true : false)
	));

$page_head generates the feed meta tag and the canonical, next and prev meta tags when viewing forums and topics. It generates the HTML in the PHP and stores it in an array for later output. I can then call the variable page_head from within the template like so -

{% autoescape false %}{{ page_head }}{% endautoescape %}

- and it will slot those meta tags into the template.

This is the simplest method, however it has two drawbacks. There is still HTML contained within PHP files with this method, and so it's not a complete separation of the logic and template. I also need to wrap it in autoescape false tags to prevent Twig from automatically escaping the HTML meta tags and in turn destroying them.

An alternative is to move the HTML completely into the template, but this would require something like:

<head>

{% if page_head['feed'] is defined %}
    <link rel="alternate" type="application/{{ page_head['feed type'] }}+xml" href="extern.php?action=feed&type={{ page_head['feed type'] }}" title="{{ page_head['feed title'] }}" />
{% endif %}
{% if page_head['canonical'] is defined %}
    <link rel="canonical" href="viewforum.php?id={{ id }}{% if not p == 1 %}&p={{ p }}{% endif %}" title="{{ lang_common['Page'] }} {{ p }}" />
{% endif %}

</head>

...or something like that.

And repeat for prev and next, each requiring more conditionals in the template file, adding unnecessary complexity. Perhaps the headers (everything between the <head></head> tags should remain in the PHP, but layout (everything between the <body></body> tags) should be done in templates.


The second point is that I'm finding that I have to disable auto-escaping in a few instances, particularly for elements that can display HTML like forum descriptions. This involves scattering {% autoescape false %} and {% endautoescape %} tags throughout the templates. This isn't so much of an issue I suppose, but something worth noting.


Finally, the third observation is that while I recognise the importance of auto-escaping, because FluxBB has traditionally generated its own output, most of the output has already been escaped with pun_htmlspecialchars. As a matter of fact, this results in some information being escaped once by the pun_htmlspecialchars function, and then again a second time by Twig.

It makes me wonder whether the benefits of using Twig for its auto-escaping capabilities are then somewhat moot and something like Plates (or a PHP-based templating system) would be more than adequate for FluxBB while still retaining the simple and lightweight codebase that FluxBB is well known for. Certainly Twig's syntax is simpler for template/style developers, but I'm not sure if it's worth the trade-off.


I would be curious to see what everyone thinks.

I have some spare time coming up so I could dedicate some of it to rewriting parts of FluxBB to separate the core logic and templates. I'm starting to learn how to use Github as well, so hopefully that works out but since I'm currently sitting exams I can't make any promises just yet.


~ micbr.

Last edited by micbr (2015-06-16 16:32:10)


Administrator, ThinkClassic - A vintage computer community.

Offline

#17 2015-06-16 16:32:31

adaur
Developer
From: France
Registered: 2010-01-07
Posts: 843
Website

Re: FluxBB + Plates Templating

Hello mic,

You might want to take a look at my fork. I've already separated the logic and HTML without any templating system. PHP is enough for me, I don't want to add an extra-layer if it's not needed.

I'm currently porting it into SlimFramework, and I plan to stick to PHP files, since I don't see what benefits I could get from Twig apart from a performance drop (but that's just how I feel).

Slim allows me to do this (PHP files):

			$feather->render('header.php', array(
				'lang_common' => $lang_common,
				'page_title' => $page_title,
				'p' => $p,
				'pun_user' => $pun_user,
				'pun_config' => $pun_config,
				'_SERVER'	=>	$_SERVER,
				'page_head'		=>	get_page_head(),
				'navlinks'		=>	$navlinks,
				'page_info'		=>	$page_info,
				'db'		=>	$db,
				)
			);
			
			$feather->render('index.php', array(
				'index_data' => print_categories_forums(),
				'lang_common' => $lang_common,
				'lang_index' => $lang_index,
				'stats' => collect_stats(),
				'pun_config' => $pun_config,
				'online'	=>	fetch_users_online(),
				'forum_actions'		=>	get_forum_actions(),
				)
			);
			
			$feather->render('footer.php', array(
				'lang_common' => $lang_common,
				'pun_user' => $pun_user,
				'pun_config' => $pun_config,
				'pun_start' => $pun_start,
				'footer_style' => 'index',
				)
			);

Congratulations on your job, though.


FeatherBB - A simple and lightweight new generation forum system
Based on FluxBB, written in PHP, using Slim Framework for a proper OOP-MVC architecture.

Offline

#18 2015-06-16 17:31:21

cyberman
Member
From: Germany
Registered: 2010-01-11
Posts: 297
Website

Re: FluxBB + Plates Templating

micbr wrote:

An alternative is to move the HTML completely into the template, but this would require something like:

<head>

{% if page_head['feed'] is defined %}
    <link rel="alternate" type="application/{{ page_head['feed type'] }}+xml" href="extern.php?action=feed&type={{ page_head['feed type'] }}" title="{{ page_head['feed title'] }}" />
{% endif %}
{% if page_head['canonical'] is defined %}
    <link rel="canonical" href="viewforum.php?id={{ id }}{% if not p == 1 %}&p={{ p }}{% endif %}" title="{{ lang_common['Page'] }} {{ p }}" />
{% endif %}

</head>

...or something like that.

+1

So it's easier to add something like DC meta tags and so on ...

Offline

#19 2015-06-16 19:48:46

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,677
Website

Re: FluxBB + Plates Templating

micbr wrote:

So, I've started moving some of the work from the example into an actual FluxBB install, calling the Twig autoloader in include/common.php and I've started integrating it into header.php. It's working - I can generate output and have Twig render it just fine.

Thanks for spending so much time on this!

micbr wrote:

First of all, how much separation between the logic and template should there be?
[...]
Perhaps the headers (everything between the <head></head> tags should remain in the PHP, but layout (everything between the <body></body> tags) should be done in templates.

This, basically. I think we'll leave all the header.php and footer.php related stuff as it is right now. We can then look into layouts and such stuff.

micbr wrote:

The second point is that I'm finding that I have to disable auto-escaping in a few instances, particularly for elements that can display HTML like forum descriptions. This involves scattering {% autoescape false %} and {% endautoescape %} tags throughout the templates. This isn't so much of an issue I suppose, but something worth noting.

As far as I know, all that's needed is appending the "raw" filter when printing content that may contain HTML, like so:

{{ forum.description|raw }}
micbr wrote:

Finally, the third observation is that while I recognise the importance of auto-escaping, because FluxBB has traditionally generated its own output, most of the output has already been escaped with pun_htmlspecialchars. As a matter of fact, this results in some information being escaped once by the pun_htmlspecialchars function, and then again a second time by Twig.

The whole point of using an autoescaping template system would be that we didn't need these pun_htmlspecialchars() calls anymore. We could simply pass all data unescaped to Twig and the autoescaping would take care of the rest.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#20 2015-06-17 15:15:19

micbr
Member
Registered: 2014-05-23
Posts: 58

Re: FluxBB + Plates Templating

Franz wrote:

Thanks for spending so much time on this!

No problem, however I wish for the time spent on it I could have made a little more progress by now.

I'm still conflicted about building Twig into FluxBB, not because I don't think it has some major advantages, but because it does add quite a bit of overhead and complexity to a project that has always been rather simple and resource efficient. I just wish there were a simpler and cleaner way of doing it. That and learning how to build a PHP project with code that could potentially be used in the public domain... now that's a scary thought.

At least the proof of concept examples seem to work, so it shows it can be done.


Franz wrote:

This, basically. I think we'll leave all the header.php and footer.php related stuff as it is right now. We can then look into layouts and such stuff.

It's mostly header.php and the content between the <head></head> tags. I agree though - generating the meta tags within the PHP as opposed to in the template files is easier to manage.


Franz wrote:

As far as I know, all that's needed is appending the "raw" filter when printing content that may contain HTML, like so:

{{ forum.description|raw }}

I wasn't aware of the raw filter. Interesting to know.


Franz wrote:

The whole point of using an autoescaping template system would be that we didn't need these pun_htmlspecialchars() calls anymore. We could simply pass all data unescaped to Twig and the autoescaping would take care of the rest.

I assumed it was something like that. With automatic escaping in the template engine, pun_htmlspecialchars could be stripped from the core (although for compatibility the function itself could probably remain in there for a while longer).


adaur wrote:

Hello mic,

You might want to take a look at my fork. I've already separated the logic and HTML without any templating system. PHP is enough for me, I don't want to add an extra-layer if it's not needed.

I'm currently porting it into SlimFramework, and I plan to stick to PHP files, since I don't see what benefits I could get from Twig apart from a performance drop (but that's just how I feel).

Slim allows me to do this (PHP files):

~

Congratulations on your job, though.

Well I like what I see. I'm looking for a forum engine to serve as the basis of my community (where performance and simplicity is important as we cater to users of older computers and browsers with limited capabilities) and FeatherBB looks promising. I'll continue to follow the progress of development and see how it turns out. I would contribute but I'm not confident enough with my own code yet.


Some of the features I wanted to integrate for my own community include:

  • Separate Template Files

  • Style Template Files take precedence (templates are contained with include/template, but if a community requires a custom template file, FluxBB will load the template file in style/(current_style)/template over the built-in template file. In addition, a complete custom set of template files could be included with a style to make a completely custom frontend for certain applications.)

  • Code Hooks (particularly within headers and navigation, to include custom scripts, meta tags and dynamic navigation links - a Private Message add-on could display a "Messages" link but change to "Messages (1)" if a new message becomes available.)

  • Clean, Simple & Efficient Code

Personally, I would rather use PHP whenever possible as opposed to bolting on another full-scale templating library. Manually escaping output doesn't concern me because I would choose to do it anyway. I liked what I saw with Plates but I see how it perhaps it's the most practical solution for a project that is made available for public consumption.

Although I could develop a version of FluxBB based around Plates entirely in-house exclusively for my own community, it would be an ongoing effort that I'm not sure I can handle.

Last edited by micbr (2015-06-17 15:22:37)


Administrator, ThinkClassic - A vintage computer community.

Offline

#21 2015-06-17 15:37:05

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,677
Website

Re: FluxBB + Plates Templating

We could also use Laravel's Blade template system, that should be lighter than Twig.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#22 2015-06-19 11:52:26

micbr
Member
Registered: 2014-05-23
Posts: 58

Re: FluxBB + Plates Templating

Given some of the developments here, I'm thinking about discontinuing my efforts.

Adaur is certainly more experienced at PHP than I am and the aims of my community align with the aims of FeatherBB, in that it's an efficient, light project without any unnecessary overheads and the potential for expansion in the future.

That said, I would like to continue building onto FluxBB itself. However, truthfully I face several hurdles:

  • I don't know anything about Composer

  • I don't know anything about Laravel

  • Relative inexperience almost certainly means the code I write won't be completely clean

  • Relative inexperience almost certainly means the code I write won't be completely secure

  • Some solutions I have to issues may not be considered best practices (because I don't know what the best practices are)

  • Something doesn't feel right about bolting on a 900KB template library to escape output that is already escaped by functions inside FluxBB (I know pun_htmlspecialchars would no longer be required, but it's a three line function being replaced by a fairly extensive library)

And truthfully, I'm no longer able to commit to operating my own website full-time, let alone committing to another project and especially one of this size. It doesn't feel like it will be possible. If I were already more knowledgeable about PHP the amount of time required probably wouldn't be as great, but at the moment I'm learning, coding and testing and that blows out the amount of time required fairly significantly.

I would consider being involved in the development efforts, possibly in a week or two when time frees up a little, but it wouldn't be wise for someone like myself to take on such an extensive task alone.

Last edited by micbr (2015-06-19 11:57:04)


Administrator, ThinkClassic - A vintage computer community.

Offline

#23 2015-06-20 13:50:03

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,677
Website

Re: FluxBB + Plates Templating

Very sad, but absolutely understandable. I've learned lately that not taking on too many tasks sometimes makes me feel sad, but definitely is a good thing to keep me sane.

All the best for your exams!


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#24 2015-06-20 16:56:55

micbr
Member
Registered: 2014-05-23
Posts: 58

Re: FluxBB + Plates Templating

I was concerned about letting the FluxBB project down, especially since like most users here I still see a valid use for a forum engine that is designed to be as simple as possible (in our case, for older computers). I would like to continue being involved, but I look at the long term development required and currently I can't even commit to 5 weeks, let alone ongoing development for the next couple of years. It makes sense to focus on addressing some immediate issues like exams and life matters before taking on a project of this scale.

I'll revisit this after exams and see if I have more time available. I can't be sure yet though. If someone else wants to pick this up and run with it, I'll share what I know and help if possible.


Administrator, ThinkClassic - A vintage computer community.

Offline

#25 2015-06-20 18:52:45

adaur
Developer
From: France
Registered: 2010-01-07
Posts: 843
Website

Re: FluxBB + Plates Templating

It would be nice to share your work on GitHub smile They have made a nice GUI for Windows, they seem to have the same for Mac: https://mac.github.com/

Oh, it's funny that I found this, by the way tongue https://fluxbb.org/forums/viewtopic.php … 558#p35558

Franz wrote:
dsrmac wrote:

If you are looking for an awesome tool to separate style and content, and even produce awesome, valid markup, may I recommend to try phamlp? It provides the well known HAML and SASS/SCSS markup languages, and the stylesheet authoring framework Compass.

While I'm thankful that you posted these links (looks really good, want to try out!) I don't think this fits the FluxBB ideology. Adding yet another layer adds more complexity and after all PHP is a templating language already (the link to GitHub in that article is very interesting, by the way).


FeatherBB - A simple and lightweight new generation forum system
Based on FluxBB, written in PHP, using Slim Framework for a proper OOP-MVC architecture.

Offline

Board footer

Powered by FluxBB