LnBlog 0.6.4 released

Time for yet another maintenance release. LnBlog 0.6.4 is now available. This release includes a critical security fix for users who have AUTH_USE_SESSION set to false. If that's you, consider this a required upgrade. Users who are using the default authentication configuration are not affected by this bug.

In other news, this release also fixes several minor bugs and annoyances. For starters, the broken "back to plugin list" links in the plugin configuration now works. I've also removed the broken default code when the pageheader plugin is disabled and fixed the trailing newline bug in LBCode that's been annoying me for some time.

By way of small "features," I added a warning when trying to create a blog in your LnBlog installation directory, because that just won't work. I also added a little feature to the LBCode URL auto-translation to allow absolutizing to the blog root. Previously, any URL given in a url or img tag that didn't contain slashes had the URL of the entry it was stored in prepended to it, so that it would display correctly on the front page or in RSS feeds. Now, however, you give links relative to the blog root by including a slash in them and links relative to the root of your site by starting them with a slash. So, for example, when I post a link to the LnBlog download page in this blog, I can give content/download/, whereas if I want to link to my computing blog, I can give /linlog/. Just a little extra convenience.

As usual, you can grab the new archive here or go to the download page itself and grab the signature, checksums, and documentation. If you find any problems or have any questions, you can e-mail me or post a comment.

You can send TrackBack pings to this URL. This entry accepts Pingbacks from other blogs. You can follow comments on this entry by subscribing to the RSS feed.

Comments #

    Upgraded again

    Link problems have been fixed, it's working now (that was to be expected). I forgot to save some of the plugins I had customized before the upgrade, so the customizations were lost - no big deal, but perhaps worth a hint in the documentation; since the XHTML is part of the scripts, this might happen to other people, too. The customized theme itself was saved thanks to the separate folder it's in.

    That themes are broken down in that many files is a bit questionable if it comes to creating a new one. However, on the template side of things, I'd keep it that way. But it might be a good idea to put the CSS in one single .css file and structure and comment that one extensively. That way, the need for external documenation is reduced (maybe even annihilated), and theming means editing one file on the CSS level instead of 10. But I guess that'd mean considerable changes... I like the way it's done in PunBB (http://www.punbb.org/): They have three CSS files, but in order to change most aspects of the appearance, you only need to edit one file in most cases, one is hardly ever touched, and if you don't want to change fonts and margins, you only touch the one with the colors, borders, links etc.

    • Comment posted on Thursday 14 Dec 2006 at 5:32pm
    • By MoonMind

    Thanks for the ideas

    Sorry about the plugins. I'll definitely add that to the documentation. The possibility of people modifying them actually hadn't occurred to me.

    I've also been thinking that the themes are a little too broken up, though mostly with regard to the templates. I haven't changed them because I simply can't think of a better way to structure the templates that won't involve duplicating code.

    As for the CSS files, I hadn't really thought about that, but I do see your point. The original intent of using so many files was that not every stylesheet is needed on every page, so only the ones that are used could be loaded. On the other hand, while you can create a new theme with only three or four template files, to modify the appearance in any significant way, you end up editing 8 out of 10 style sheets. I don't konw if I'd do it as a single style sheet, but it wouldn't be hard to condense it down to less than five. It wouldn't even take many changes on the back-end to do it. It's just a matter of going through the stylesheets and reworking them, which is time consuming for me because I'm more of a programmer than a web designer.

    Show stopper?

    Hello

    I'm sorry I'm back with another issue, but I discovered that one only after checking on my LnBlog install from the outside (not from localhost): Somehow and somewhere, paths do get written absolutely while installing. This meant root path gets set to "localhost" in my case; that way, templates and CSS didn't work since "localhost" would serve them, and neither did administration. Locally, everything went smooth and well after the last update, and the style I created worked as well. I'll recheck on the whole thing starting from an external web server some time in the future (but not until my new hosting is up, which'll be some time in May) because I really like the software, but meanwhile (and since I'm not able to fix this myself), I had to take the blog down. I did some looking through files, but I'm no good when it comes to PHP, so I didn't investigate too much.

    I'd love to see this corrected, though - I'm planning to use LnBlog for my personal website instead of the small CMS I'm using now. Interactivity is just so much more pleasant (in spite of the spam problem...).

    • Comment posted on Thursday 14 Dec 2006 at 5:32pm
    • By MoonMind

    Here's the quick fix

    Sorry about that. The quick fix for this is to log in through the external URL of your site, *not* localhost, and run an upgrade on your blog. To do that, just go to the administration page and put the path to your blog (the same one you gave when you created it) into the "upgrade blog to current version" box and hit the upgrade button. This will regenerate the wrapper scripts for that blog.

    The problem is that the URLs of the LnBlog installation and the blog itself are calculated when the blog is created. They are stored in the config.php file in the blog directory, from which they are also propagated to the config.php file for each entry and article. If you don't have any actual data in a blog, you can always edit the file by hand, but this gets cumbersome if you already have a lot of entries to deal with.

    That was one of those "it seemed like a good idea at the time" decisions. In retrospect, that setup is a pain to maintain and is much too limiting. For one thing, if you happen to want to put different blogs on different subdomains, it doesn't really work. As you discovered, it also doesn't work if you want to do setup locally. What I need to do is change the setup so that you can manually set the URLs. I also need to remove all the paths and URLs from the config files for individual entries, because it's just too hard to maintain. I'll try to do that and put up a new release in the next week or two.

    Thanks for the quick reply and fix

    Okay, I'll try that - sounds good! Anyhow, I will be setting this up on a hosting service, so it should work there. Trouble is, my actual web space provider has managed to mix up his setup thoroughly, so while the site is still up, new installations can be really troublesome... But I'll try it all the same. Since LnBlog doesn't need a database, it might work all the same, but if it doesn't, my means to check why are very limited at the moment. That's why I tried it locally... I hope I'll be back with a better report soon!

    Besides, if one could just set the root path to "/" (as one can do with SiteMap links), the problem would be solved... But maybe I'm missing something here.

    • Comment posted on Thursday 14 Dec 2006 at 5:32pm
    • By MoonMind

    Not quite

    Using a non-absolute install root URL is certainly one way to do it. In fact, the next version will let you customize the install root and blog root URLs on a per-blog basis. That's really just a side effect, though. The real problem is telling the wrapper scripts in each blog the local path to the LnBlog installation. The corresponding URL just happened to be thrown in there to save calculating it every time.

    At any rate, I've already changed the way paths are handled for the next version. There will be a new pathconfig.php file in the root of each blog. This will contain the LnBlog path, LnBlog URL, and blog URL, and will be editable via a link on the weblog settings page. Basically, you'll just be able to change all the paths in one file rather than having to modify the config.php files in *every* directory in the blog.

    Very good

    I'm looking forward to testing the new release. For my personal purpose, LnBlog would be even better than some very well established projects like WordPress (I'm using that on my site for the time being, it's okay, but LnBlog was a lot easier to customise - and since I already did a theme, I'd very much like to use that...)

    • Comment posted on Thursday 14 Dec 2006 at 5:32pm
    • By MoonMind