Reduce duplicate traffic, raise performance

[Traumflug]

Not sure wether Phorum is still in development, over at reprap.org we use it very successfully. Here's a tidbit on how one of our geniuses raised snappiness noticeable. It should be a easy to change that for the distribution:

I've edited the forum file at /.../forums/htdocs/include/phorum_get_url.php to set it so the javascript.php requests don't have the forum id added.

before:
GET /javascript.php?225
after:
GET /javascript.php

The javascript doesn't vary by forum, so having that forum-id on the request was causing the file to be re-requested when a user switched between forums, rather than just using the javascript file it'd already downloaded.

This should remove some unnecessary traffic, both on the server and for the user.

A spot-check of yesterdays access_log shows that it transfered 3121 megs of javascript.php, but it'd be 1387 megs if there were no duplicate javascript.php traffic.

I'll look into doing the same for css.php, too.

If you think it's worthwhile, I'll happily make a diff.

[mysnip]

It was a conscious decision to add the forum id.
You can have different styles per forum (e.g. different template selected per forum) and also different javascript as it can be modified by modules and that way per forum ;).

So, best would be to have a setting to change that behaviour, depending on your use case. I'd prefer a patch.

[Traumflug]

I see. The file in question isn't part of the template, though, but at the root level of the Phorum installation. To me it looks like a proper patch would be to move the file into templates, then add a template-ID instead of a forum-ID.

Stepping through the changes this guy did this week, it looks like the patch is as simple as this:

diff -ur old/include/phorum_get_url.php new/include/phorum_get_url.php
--- old/include/phorum_get_url.php  2012-08-24 06:20:02.000000000 -0700
+++ new/include/phorum_get_url.php  2014-07-17 16:13:28.000000000 -0700
@@ -24,7 +24,7 @@
     PHORUM_CONTROLCENTER_ACTION_URL => array("control",    PHORUM_URL_NO_FORUM_ID,   false),
     PHORUM_CONTROLCENTER_URL        => array("control",    PHORUM_URL_ADD_FORUM_ID,  true),
     PHORUM_CSS_URL                  => array("css",        PHORUM_URL_ADD_FORUM_ID,  true),
-    PHORUM_JAVASCRIPT_URL           => array("javascript", PHORUM_URL_ADD_FORUM_ID,  true),
+    PHORUM_JAVASCRIPT_URL           => array("javascript", PHORUM_URL_NO_FORUM_ID,  true),
     PHORUM_FEED_URL                 => array("feed",       PHORUM_URL_NO_FORUM_ID,   true),
     PHORUM_FOLLOW_ACTION_URL        => array("follow",     PHORUM_URL_NO_FORUM_ID,   false),
     PHORUM_FOLLOW_URL               => array("follow",     PHORUM_URL_ADD_FORUM_ID,  true),

[mysnip]

But thats not configurable ;-).

template id is also wrong, you can also have forum specific template variables overridden used in the css.

[Traumflug]

scratching head OK, I admit I'm not deep enough into this software to really judge what's the right thing to do. It's quite possible this patch should be kept as a local optimisation.

Regarding per-forum templates we found it somewhat confuses people to see different designs in different parts of what we call "our forum". When we had the standard template on the front page, but Emerald in all the sections, people occasionally talked about the front page to be "broken". But that's a design decision, of course, so you likely get 10 different opinions if you ask 10 people.