Forums

Are you using rc3 or the latest version from GiT.  I'm sure I already hid the unwanted text.

The real solution to things like this is templating rather than config options.

I would display the forum version data for the latest release. It just seems kind of incomplete without it. Also bear in mind people are lazy.  They may just have hit a link to the mod from the front page so they won't have filtered the mods.

However its put to the community I would be tempted to get 1.4 out the door first.

As I keep telling people, IE6 support is just markup and css.  Its upto the template author what browsers they support.  However, if you mean the default templates I'm OK with that.  We can always have an officially supported IE6 theme in the repo.

If people have to update their mods for 1.5, what about mods that use php4.  When its dropped in 1.6 the mods will need updating again.  Wouldn't it be better to dump php4 a.s.a.p which means things only have to be updated once.

Making a template extensible isn't difficult. You just do this

<?php $this-startBlock('Menu'): ?>
<ul>
<li>blah</li>
<li>blay</li>
</ul>
<?php $this->endBlock('Menu'); ?>

What happens is this, if an extension hasn't registered some markup for the 'Menu' block with the template class then the startBlock() and endBlock() functions simple exit which means the markup between them gets rendered.  If an extension has registered some markup for the 'Menu' block then startBlock() opens a buffer and endBlock() captures the buffer to a variable and then closes the buffer.  The instruction coming from the registered extension is then processed.  That instruction will either be before, after, replace, delete.  What happens next should be obvious.  Of course that doesn't address collisions but thats the job of the extension manager class not the template.

As for template nesting, with the approach I outlined thats not your call.  Its entirely upto the template author how they structure the template set.  They could just use one set of templates nested inside a page wrapper or could nest them 10 deep.

The way the templating system works (ignoring the compiler option) is this.  A simple template class is included via common.php.  The template class constructor takes the name of the calling file e.g. viewforum.php as a parameter together with the user style info.  It now knows that the main template is mystyle/viewforum.tpl.php.

The viewforum.php file is essentially the same as now except instead of spitting out markup it simply constructs an array of topics which it assigns to the template object.  It also assigns the language file arrays which are merged together by the template object.

Now a new file called page.php is loaded.  This replaces header.php and footer.php.  Again it works the same as the existing file except it assigns variables to the template object rather than producing markup.  At the end of page.php is the call to the template class render method.

Now here is where the templating gets a bit clever and very flexible.  At the top of viewforum.tpl.php there is a bit of php which tells viewforum.tpl.php to decorate itself with page_viewforum.tpl.php.  This is an intermediate wrapper which contains things such as breadcrumbs, pagination, posts links etc.  page_viewforum.tpl.php contains a call to another wrapper which is page.tpl.php which contains all the stuff common to all pages.  Essentially the page is being constructed from the inside out i.e. its the opposite of using include.  The buffered output is then rendered.

Of course not every page needs to use an intermediate wrapper, forms will go straight to the page wrapper and some pages can use the same intermediate wrapper.  The flexibility comes from allowing the main section templates to dictate their own wrappers which means you avoid having to to include code to decide whether a particular page gets crumbs or not etc. Further flexibility comes from the fact all data has been assigned to the template object prior to any of the template files being rendered.  This means the main section template can use data assigned by page.php and the page wrapper can use data assigned by viewforum.php.

If you are wondering why I'm going into so much detail its because I think it essential that the template system be introduced before doing anything else.  The reason is once the view layer is seperated out as described you no longer have to concern yourselves with markup, css or any other frontend stuff which vastly simplifies development.  As for the view layer, it is completely agnostic as to how the backend works, it only cares that the right data is pushed to it which means it keeps on working while the backend is being developed.

Or it was completed by somebody using a screen reader who didn't pay attention to the instruction (assuming there is one) not to complete the field depending on the technique used to hide the field.

Looking at them under a microscope you are right.  The horizontal of the four and the hash ran into each other perfectly making the strike through invisible at least to me.  I may need new spectacles.

I don't get the Bug Tracker background colours.  I would have assumed they reflected the tickets status but obviously not. Do the colours reflect the priority?  If so fixed items have no priority because they have already been done.

Isn't there a ski resort in France called Les Arc 2000. That would appear to be a town name with digits.