22 Feb 2003 amars   » (Journeyer)

From the PostnUKE API reference...

2.1. Users

This area covers everything related to users. Confirming that a user is logged in, getting a user-specific configuration parameter, or logging a user into the PostNuke system are examples of functions that fall into this area.

Yeah, real fucking useful... if you aren't going to bother saying anything about the topic, why include it at all?

Needless to say, i'm not impressed in the least bit with PostnUKE at all...

Going through the "module" code, because i've been given the task of developing a postnuke module for a client. What good does a templating "engine" do when you have stuff like, OpenTable(); followed by echo "more html"; inside of modules, outside of the realm of templating... is not the goal of templating to separate logic from presentation? Even still, within a module a programmer has to include header.php and footer.php. In 30K+ lines of code/bloat, you'd think that kind of stuff would be handled in a much more elegant manner.

Also, in the Template module, which is supposed to be used as a guide to build new moduels from, there exists a index.html instead of index.php... nowhere is it mentioned in any of the documentation that modules.php looks for *.php. Putting together an empty template to build up from nullifies it's utility when A) documentation is left out and B) you have to do a code walk-through to figure out why the web interface says everything works and was installed properly but modules.php gives a 404 error. Which brings up another issue, why mix terminology? modules.php exists, yet error.php is called and produces a 404 HTTP error.

Another rather disturbing occurence is the fact that the database user/host/passsword is stored in $GLOBALS, accessible to any module, thus overriding the extensive code bloat added to implement variable access permissions. Why is this not seen as a security threat? Someone could easily create and disstribute a module that exposes that information and even exploit it or someone with CVS access could hide such funcionality in the code somewhere... I shouldn't have to worry about trusting the PostnUKE developers protecting such data.

If one more person talks about how great PostnUKE is, i think i'm going to puke... and this is only the beginning.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!