Flux CMS DevBlog

I played a little bit with yslow and tried to improve the end user experience a little bit (not that it was bad before .) ). The simplest way is to add some apache directives, which fixes some issues with compression and caching. Here's an example (the html pages itself are usually compressed by flux cms, so we don't need to use mod_deflate on them)

ExpiresActive On
ExpiresByType text/css "access plus 2 days"
ExpiresByType application/x-javascript "access plus 2 days"
ExpiresByType image/gif "access plus 2 days"
ExpiresByType image/jpeg "access plus 2 days"
ExpiresByType image/png "access plus 2 days" 

<Location /themes>
SetOutputFilter DEFLATE
FileETag none
</Location>

<Location /webinc>
SetOutputFilter DEFLATE
FileETag none
</Location>

<Location /files>
SetOutputFilter DEFLATE
FileETag none
</Location>

SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png|pdf)$ no-gzip dont-vary

That's the easy stuff, issues like versioning of scripts/css/images via URL (so you can set the Expire time as high as you want), putting the JS onto the end of the page and easy possibility to spread requests across multiple domains, need a little bit more work, but should find their way into Flux CMS soon.

PS. It's not done on this blog here yet, but eg. on http://blog.liip.ch/

I just committed an authentication module, which authenticates against a Confluence server via the SOAP interface instead of just the internal database. This allows us to enable access to a Flux CMS installation for everyone at Liip without having to actually create all those 20+ accounts (and everyone can use the same password on Jira, Confluence and those CMS installations)

The module still uses the internal database, if the authentication via Confluence fails. Therefore you can have additional users in the local database, which do not have a confluence account. Additionally, the module creates a local CMS user account, if someone with a Confluence account first logs in and saves all the needed CMS information there, so that Confluence is really only used for authentication, later needed additional CMS information is still maintained and saved locally.

To use this module, just check out the latest 1.5-dev or HEAD version of the CMS and change/add the following to your config.xml

<permm type="permm">
  <authModule>
    <type>confluence</type>
      <wsdlurl>http://your.wiki.com/rpc/soap-axis/confluenceservice-v1?wsdl</wsdlurl>
      <allowedGroup>internal-developers</allowedGroup>
      <!-- all the other options from the standard authModule -->

The allowedGroup option tells the plugin in which group a Confluence account has to be for getting access to the CMS

This plugin can also serve as a template, if you want to authenticate against a similar service but still use the default one as a fallback

Addition: The SOAP extension has to be enabled for this to work.

Update: In at least Confluence 2.4, the allowedGroup check does not work for non-admin confluence users, therefore I added a new option to config.xml

<allowedSpace>INTERN</allowedSpace>

This option checks, if the current user can see that particular space. As you can give rights on a per space base, this is basically the same as the allowedGroup option, just configured differently on the confluence side.

All you have todo is adding the following in the config.xml of your collection:

<?xml version="1.0"?>
<bxcms xmlns="http://bitflux.org/config">

    <plugins>
        <parameter name="xslt" type="pipeline" value="tagcloud.xsl"/>
        <plugin type="navitree">
        </plugin>
        <plugin type="tagcloud">
            <parameter name="locations" value="/blog/"/>
            <parameter name="maxfontsize" value="56"/>
            <parameter name="minfontsize" value="20"/>
        </plugin>
    </plugins>
</bxcms>

and a little xsl to display the data:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:blog="http://bitflux.org/doctypes/blog" xmlns:bxf="http://bitflux.org/functions" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns="http://www.w3.org/1999/xhtml" xmlns:php="http://php.net/xsl" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rss="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" exclude-result-prefixes="xhtml">
    <xsl:import href="master.xsl"/>
    <xsl:import href="../standard/common.xsl"/>
    
    <xsl:output encoding="utf-8" method="xml" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"/>
    
    <xsl:template name="content">
        <p id="tagcloud">
        <xsl:for-each select="/bx/plugin[@name='tagcloud']/tagcloud/tag">
            <a href="{$webrootW}{path}archive/tag/{name}" style="font-size:{size}px;">
                <xsl:value-of select="name"/>
            </a>&#160;
        </xsl:for-each>
        </p>
    </xsl:template>
    
</xsl:stylesheet> 

have fun :)

... actually, that feature existed since last June, but we never publicly announced it :)

So, here it is:

If you want to make certain blog posts only available to some people you can now do that without giving them access to the admin, even on freeflux.net. For that do the following:

- Create a user in your admin (Top right under "Bookmarks" -> "Users") and give him/her the "Group ID" 2. Users with Group ID 2 can't login into the admin, but they can see your private posts.
- Make a blog post and set the Status to "Private" (can be found under "More options")
- To make the login easy for the users, drag'n'drop the login "portlet" into your sidebar (Can be found in the "Sidebar" Tab in the blog admin), if it's not already there.

Now you see a "Login" link on your blog, if you click on it, a little login opens and your users can login there and then see the private posts, as well

Hope that helps and if you have any questions, just ask them here

We finally replaced our aging bugzilla installation with a shiny new jira installation for keeping track of our bugs.

So, if you find any bugs in Flux CMS, go to bugs.bitflux.ch and file them there, we will then take care of it

(You need an account to actually file bugs, but that's easily and quickly done here)

While the new firebug beta looks and actually is great and worth checking out, it somehow breaks the navitree in the Flux CMS. It just doesn't load anything under the home collection. I have to investigate further, but the only solution right now is to disable firebug (or not upgrading right now to the 1.0 beta)

Update: I could fix it on our side. Somehow XMLHttpRequest.readyState stayed at 0, even though it usually directly goes to 1 after calling .send(). I put now a little check in there, so that it simply reloads the navi tree frame and all should be fine now (it works after a simple page refresh, mysteriously...).

I committed it to trunk and the 1.5-dev, but the patch can be applied to older versions, as well.

So, go and get the firebug 1.0 beta, it's really cool (besides that little annoyance :))

Due to some abuses on Freeflux.net, we disabled the possibility to download some file types like zip and exe (like it was with .html for quite some time due to spammers)

Sorry for the inconveniences, but the whole thing got out of hand...

And if you try to circumvent this, we reserve the right to disable your account without any further notice.

Just great. If you use ZoneAlarm and its Cookie and Ad-Blocker, it will insert <script> elements into the Xhtml file loaded by BXE... The main issue with this is, that the Xhtml document isn't well formed afterwards and Firefox can't parse it anymore. I added now fallback code, so that if BXE can't parse the file, it removes all script tags and tries to reparse the document. If that still doesn't work, you get an error, otherwise you should be able to edit your document as usual. The only drawback here is, that if you had script tags in your original XHTML document, they also will be removed. But this only happens, if you use ZoneAlarm (or similar software) and usually, one doesn't have script element in a Xhtml document anyway :)

If you encounter this problem, upgrade BXE and editing with BXE should be ok again.

We're currently "playing" with the trunk (for introducing some kind of staging), therefore we highly recommend not switch to trunk right now. Especially not from an older version. But it should be ok, if you start from scratch.

Update: Should be safe again, but do backup, if you upgrade from 1.5 branch or less :)

Via Svizzer Blog, I learned that Technorati recommends a rel="bookmark" attribute for the permalinks. So I added that to the blog plugin for hopefully better indexing (maybe not only by Technorati).

Complete explanation.