Archive for the 'Phorum' Category

The next steps for Phorum

Now that Phorum-5.2 has finally gone stable there will be hopefully some better modules as the possibilities have been vastly increased. One of the new modules for 5.2 which show quite some of the abilities is the rewritten user-avatar module for 5.2.
With modules you can use now (not everything is new in 5.2!!!):

  • use a supported API for files, users, custom profile fields and similar stuff
  • ability to hook the module-css into the css loaded by phorum for valid (x)html pages and not loading it separately (saving requests)
  • ability to hook the module-javascript into the javascript loaded by phorum for … see above ;)
    (both can use raw files, templates, functions for including it)
  • can do database calls without writing database dependent code (could still be because of the queries themselves)
  • use module-templates which are included in the module itself, no need to copy them to the template folder(s)
  • language files in the modules themselfes
  • adding controlcenter panels without copying files around

Also our module list for 5.2 is now auto-generated from the modules posted into the 5.2-modules forum in the right format.
Make sure to add categories too as listed in the docs!

So, now that we (could) have better modules, whats next?

Dan Langille has been working on a postgresql-layer for 5.2/5.3 which will probably be included in one of the later 5.2 release as a beta of this layer.
The next big release will be Phorum-5.3. Our plan for Phorum-5.3 is “just” to add even more APIs, changing large parts of the backend without touching much of the frontend code.
Therefore templates from 5.2 should work without a hitch with 5.3. Maybe there will be added features missing in the old template but otherwise it will continue to work as before.
I know we made it hard for some admins with the switch from 5.0 to 5.1 and 5.1 to 5.2 but all these changes were done for flexibility in the templates and making them far more consistent and therefore easier to implement.
Some of the APIs will be about forum handling and similar stuff so that you can build a new admin or an admin in another page far easier than before.
As usual you can see the tickets on the table for 5.3 in our ticket-list (from the 5.3-milestone).

And further in the future?
There is lots and lots of stuff in the ever growing Ideas-milestone.
We’ll see if any of this will see the light in 5.3 already or in a later release but we surely won’t get bored ;-).
I’m pretty sure that lots of stuff will be done at the MySQL Conference 2008 like last year where we’ve been coding and presenting there with lots of feature tickets closed for 5.2. You can help us to get there with donating to phorum.org!

laws and the use of logging IPs

in the light of recent court-decisions in germany ( german article ) which essentially disallows logging of IPs I’m wondering what one would really need it for?

I’m using IP-logging/-tracking in multiple ways:
1. statistics about visits and recurring users
2. storing it with forum-posts to allow law enforcement in case some user really goes over the line
3. tracking requests in a given time by IP to automatically block potential attacks

So what of that could be avoided?

For 1. , one could just ignore logging the ip but trying to count visits and recurring users would be impossible with that. What now? Maybe logging a md5/shaX of the ip to have some unique key per IP? Wouldn’t that still fall under the rule from the court as you could find out which was the actual IP?
Counting visits is an important tool for getting advertisers to advertise at a page (In my opinion). Any ideas?

For 2. , guess one could disable that but would I be responsible then for each and every forum-post because the real poster can’t be retrieved? (Yeah, laws in german are bad for the one offering the forum after all :( )
On the other hand there is the upcoming data retention ( german news collection about this topic ) which is planned for keeping all records for 6 months (!!!). So for now I should remove all tracking of ip-addresses just to be forced to store it for 6 months a while later?

For 3. , this behaviour gives me another problem too. Trying to load-balance over multiple webservers usually goes through a reverse proxy in front of the webservers which would always give the REMOTE_ADDR of the reverse-proxy to the apps. So the reverse-proxy would need to add this security layer. But I really failed to find one doing this up to know.
But is that really needed and I’m just oversensitive in this area? Do I need to accept any number of requests/s from any user?

Are there other use-cases for logging IPs?

How are other users handling this?

The editor of choice …

… yeah, everyone got his own idea of which editor he should or would use - thats the freedom of choice ;).
Brian loves his jedit, Maurice uses his VI (and can’t live wout vi-bindings and -code-folding) and I, I’m just going with the masses ;).
Currently I’m using Eclipse/PDT, coming right from the Zend IDE/Studio.
There were quite too many bugs in the current Zend Studio which I couldn’t live with (no, I don’t want to restart the IDE every half hour just because it forgets to show the content of the files) and PDT was just on its way to get to a final 1.0 so I used it.
Coming from Zend Studio its easy to use and for missing features in the IDE you can simply install some eclipse-extension - thats the power of using a generic IDE.
One thing I’m missing in PDT in relation to the Zend Studio is the line wrapping. There simply is NONE in Eclipse. Guess it was to teach coders to write 80cols code ;).
But for now I HAVE code which is far longer than 80 or even 160 cols and I don’t want to scroll around or reformat if I’m looking at a longish condition.

I also tried jEdit, Kommodo or the likes. I for one really want that project handling with function lists for the project, the possibility to just select a function and jump to its definition, having the comment of the function shown in a tooltip when using/typing it. Thats what I expect from an IDE.
Yeah, I know. These huge java apps can get slow sometimes but at least we got something to use our CPU’s for, eh? ;)

finally it has arrived: Phorum-5.2.0-alpha

It took quite some time but finally we made it and released phorum-5.2.0-alpha.
Brian already posted most of the new features in his blog .

One of the new things that don’t show up in the phorum-code itself are the revamped docs.
These are written in docbook-xml and are available (rebuild from trunk every hour) on phorum.org
as html-docs
and pdf: admin.pdf , developer.pdf , faq.pdf and the still empty user.pdf .
Therefore I renew my plea for help in this area.
It would be really great if you could help us to improve the docs. Every little thing helps.
Send us questions (and answers) for faq-items, texts for the user-manual and so on. Just send it in as plain text, we will convert it to docbook if you don’t want to mess with it.
Email-address for all docs-stuff is documentation@phorum.org (which will reply you at your first mail with a confirmation required).
If you want to play directly with the docs-source just checkout the trunk-tree as described in the wiki and look at docs/docbook in there.

Oh and before I forget: remember its alpha-quality. Don’t use it in production yet!

Thats one PHP-5.2.x feature for Phorum-5.2 I’d like to use …

Its the httpOnly Cookies support in the setcookie-call.
Now that Firefox 2.0.0.5 supports it too (as mentioned here and here)
the main browsers are supporting it.
Internet Explorer seems to have been the first one supporting it, with Firefox now and Opera meant to support it in 9.5.

Therefore it makes sense to use it now. Even browsers not supporting it are just ignoring the additional flag.
In PHP that flag was introduced in PHP-5.2 - another cause for going php-5.2 and up only ;).

The new db-layer in Phorum-5.2 kicks ass

Thanks for maurice’s pulling me into the db-layer I added my “own” mysql-mysnip-layer which handles the queries done.
The change from 5.1 to 5.2 brought up a split db-layer with one file containing all the queries for mysql and calling a function for actually running the query and (optionally)
returning the rows.
And that second part is simply extension specific like for mysql and mysqli extensions. I think it would be simple to add another for pdo but thats a different topic.
For now I added another “extension”-specific part for mysnip which looks into the queries to check if they need rewriting for the partitions used.
The partition-specific tables have some marker in there which tells where the partition number should be and that marker is replaced with the partition-id on querying.
If the partition-id is not yet available in for the current forum-id its retrieved from the database.

That functionality allows me finally to run through all the upgrades as we’ve added a flag to the queries which need to be run for each partition.
We stumbled about it when I was wondering how real-name upgrades are handled now as these have to run through all partitions where that user could have been posting to.
The upgrades from my early version to current 5.2 take a while but overall they are running fine.
Another nice thing is that I don’t have to hack the actual layer which contains the queries and can take that part from the distributed code, only the “extension-specific” code changed and is in a separate file. No more relying on a module to run and rewrite the table-names which would only run once on a page-view.

To cut a long story short: its great and should allow you all kinds of changes to the db-layers without touching the queries. It should even be much easier to write a layer for another database-system (anyone volunteering? ;)).

Tough to get “documentors”

For Phorum-5.2 we (or better Maurice ;)) are trying to get some more documentation for Phorum.
Maurice does a damned good job in providing developer docs together with starting it all in docbook-format
but, as usual, most developers aren’t good documentation writers and therefore the documentation is lacking a lot of content.
We were also trying to get at least for the user-documentation some users to write but got exactly 0 replies about it.
Why is it so hard to get someone to write docs which he could use for his users to explain how to use the Phorum and would help others with the same task?
How are other projects handling this? All documentation written by the developers?
I’m pretty sure that there are some admins out there who have written docs for their users but unfortunately no one is interested in contributing them :(.

Blue screens and US-networks

So finally Maurice (who would see a link here if he had a blog ;-)) reminded be to talk about it … .

Finally we had our first Phorum-Developers meeting when we went to the MySQL-Conference last April.
Which was a great experience and I have to thank MySQL AB for the invitation to the DotOrg Pavilion.

But all the time there I have been hit by Blue Screens on my ThinkPad (yeah I know, bad to have Windows running but I think its still better with Windows on Laptops than Linux).
There must be something bad about US-WLAN-networks as I never had this problem before and only got it there when connecting to the Conference-WLAN.
Do they use some different channels or frequencies? I really don’t know as I just want to have a working connection.
Unfortunately it didn’t fix itself when coming back to Germany. I still had occasional crashes with the infamous blue-screen.
Only a full reinstall of the OS and all the precious applications helped.

So much about US-Wireless-networks :(.

The DateTime object is “the next big thing”?

We’ve (the folks from Phorum) been talking in the last days about using the new DateTime object in PHP for Phorum as it has a nice way to use timezones including their DST setting.
Up to now we have just a setting where the user select if DST is current active or not as there isn’t really an easy way for use to enable/disable DST automatically.
Using that object would allow us to let the user select its timezone (with the timezone-select generated from that DateTime Object) and have DST automatically adjusted or better, we would not have to care about DST once a timezone is selected as its done automatically.

But unfortunately there is no localization of the date/time formats names in that new object.
Derick tells that “It’s intentional for PHP 5.2, not for PHP 6.0.” which is not really satisfying in my opinion.
In Phorum we are using strftime which formats time and date by the locale settings which are done through our language-files too.
So we can’t really get this behaviour through the new DateTime stuff and therefore I can’t really agree with Brian that its the feature we want in Phorum and that would require PHP-5.2.
It would only work half-way, too bad. A good idea which wasn’t completely finished.

Charset hell (and mysql-upgrades)

Oh yeah, some people will remember me talking about charset hell when it wasn’t really that bad (yet).
But in the near future I will surely have to solve some charset problems for MySnip.de.
It is still running MySQL-4.0.x which didn’t support charsets like MySQL-4.1 did and even more MySQL-5 is doing now.
But as MySQL-4.0 support has run out I really need to upgrade soon and then I’ll probably find myself in a lot of charset troubles ;).
First one will start with the upgrade itself. How will it look like after the upgrade? Default charset will probably be latin1 so it *should* be fine. But will it?
Beside that this upgrade is already some trouble as I will need to dump/restore the whole databases which are quite some GB’s and I hate to take the services down for some hours.

For now I’m finding enough excuses like I need to wait for Phorum-5.2 until I can upgrade but in the end I can’t do it all at once.
I still hope that Phorum-5.2 will still run on MySQL4 so that I can upgrade Phorum first and then convert to MySQL5 (for now I see no problems with that).
But Brian has announced that he doesn’t care about PHP4 and MySQL4 either as we are all developing on MySQL5 and PHP5.2 (which is correct, my development environment is like that too) - we’ll see what I can do about it ;).

Seems like I’m running a really explosive mixture with PHP4.4.x, MySQL4.0.x on my production boxes and doing development mostly on PHP-5.2.x and MySQL5.0.x.
Fortunately it seems like Phorum itself is not as vulnerable to changes in PHP itself as other apps because of its NON-OO-code and up to now we had always MySQL4 in mind as it was the requirement for Phorum-5.1 which is the current stable version.

Somewhen I’ll run into walls, thats for sure …