Forums

I think I would probably go for helper functions to generate form fields not only because they are tedious to write particularly in admin but because it reduces the chance of errors and inconsistency creeping in.  Provided its done right there really is no good reason why anybody would want to tinker with the markup for the individual fields anyway.  Of course, its quite possible to load helper functions which are template specific for anybody who is desperate to tweak things.

A more important thing that has to be decided is how to handle language strings.  Either the controllers can merge the data and language string and then send it complete to the template which is what happens now or the language strings can be assigned to the template and the merging done on output.  The second way is cleaner but it means the templates will need to use printf() or a method which is a wrapper for printf().

Personally I think the principle should be that the controllers never generate markup, only data.  Markup is the responsibility of the view layer either being created in the templates or via template helpers.

Here is another idea that has been on the agenda for sometime, post approval i.e. posts don't appear in a thread until approved by mods or admins.

I did come up with a very simple way to implement this sometime ago.  Basically you create tables which are identical in structure to the tables which hold post and topic data; call them temp_posts and temp_topics.  When somebody posts whose posts need moderating then the posts go to the new temp_ tables.  This requires one new update query in viewtopic which is an exact duplicate of the existing query save for the table names.  The contents of posts held in the temp tables will then be displayed in admin on a page similar to the moderate topic page.  When posts are approved the data will be retrieved from the temp tables and posted to the public post and topic tables as if the post was being made there and then.

The beauty of doing it this way is that posts awaiting moderation don't have to be hidden because they are not included in the public tables to begin with.  As a result, no alteration of existing queries is required to deal with permissions and the code changes are all in admin save for a trivial adjustment to viewtopic.

Updated to FluxBB 1.4 Final and includes an Opera 10.6 fix which is shortly to be included in FluxBB itself.  Also inclues a bug fix for Chrome.

Lets say you wanted a space between each category. The easiest way would be to apply a top margin or padding to each category and then set it to zero for the first category.  There are other ways of doing it but as a general rule whenever you have repeated items its useful to be able to pick out the first item.  Of course, if it weren't for IE6 there you could do it with css selectors alone.

That is exactly the reason.  In some cases it doesn't matter e.g. when posting a message, its obvious because a new post appears.  This is something Rickard had on his personal list to change at some point though I'm not sure what he had in mind, presumably some sort of immediate feedback on the active page.

Would it not be better to start a new public thread and keep it on topic since parts of this thread are developers jabber jabber.

Fixed.

I misread, I thought it said 1.4. I'd forgotten 1.3 even existed.

No is the short answer.

The problem with the userlist page, as you may have already worked out, is twofold.  First, all other paginated pages have breadcrumbs; second, the pagination placement is inconsistent with all the other pages.  The only effective way to make it work consistently is to add a breadcrumb and move the pagination to the top left as with all other paginated pages.

I hadn't noticed there was a release date.  Somebody also needs to revert userlist to how it was before.

I would have thought jQuery was the obvious choice as it seems to be becoming the defacto standard.