LnBlog 0.7.3

Well, I finally got around to finishing up LnBlog 0.7.3. You can grab the archive here or get it from the download page.

This release contains mainly minor bug fixes. You can find the details in the change log. It also adds support for per-category RSS feeds to the standard RSS plugins and MetaWeblog API. Note that these are statically generated, just as the regular RSS feeds. Also, I've moved the Archive and GoogleSearch out of the main distribution and onto the plugins page.

That's about it for now. I'll be putting up a couple new plugins up in the next day or two, so stay tuned. In the mean time, please leave a comment or e-mail me if you have any problems, bugs, or suggestions.

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

Comments #


    Looks good. I have just one thing to suggest: You could advice people not to upload the ./userdata folder when upgrading directly - or to put it even more frankly: Considering the fact that things work fine most of the time, your recipe for upgrading in the documentation could be amended with a "quick'n dirty" method: "If it's not a major upgrade, just upload everything but the ./userdata folder to your LnBlog directory, login, enjoy (maybe pull a backup first?)." ;)

    No, seriously, it's been a breeze to upgrade, and things work fine. One more reason to love LnBlog - and flat files...


    As a side note

    The only thing that persistently refuses to work is upgrading the actual blog - not that it hurts or doesn't work right because of that, but I figure I might run into issues when doing a major upgrade. I know working out the error messages is a pain in the behind, but in order to reassure people trying to use LnBlog to its fullest potential, I think it should be tackled eventually. In other words: I could be more helpful if I knew what went wrong when and where...



    I agree on both counts. I'll try to clean up the documentation before the next release. I still haven't regenerated the new docs for this release, so I might as well polish up the upgrade instructions first.

    As for the upgrade errors - well, it's just a matter of finding the time to do it. I'll try for the next major release on that, but I don't know how that will work out. I want to have pingback support implemented for 0.8.0, so I'll see what I can fit in.

    Cookie troubles

    I'm running into issues with my blog - I can't seem to connect because of some cookie related issue; this may or may not be related to Firefox and extensive usage, but also with the fact that not logging out (closing a browser tab and reopening the blog later in another one, thus still being logged in) isn't possible.

    I'll clean my cookie cache, but I guess this isn't the behaviour that's intended. What I'd like would be the following: Log out, be logged out, OR Don't log out, stay logged in, no matter how long one is absent (or auto logout after some days [not only hours] of inactivity).



    What FF sees as cookie problem is really an issue with the new version of PrivateBlog - as soon as I disabled it, things worked as expected again. I can't say much more about it, though, since testing in depth is out of the question right now (work...). Anyhow, I'm glad I "solved" it for now...


    It's a configure issue

    Well, the entire point of the PrivateBlog plugin is to keep people from accessing a blog, so I guess it's working! ;)

    Seriously, though, I've also been having issues with persisting logins - Opera periodically expires my login cookie and never logs me back in when I restart the browser.

    It turns out the problem is that I set the default login parameters a little *too* paranoid. The two parameters in question, which can be changed in userconfig.cfg, are AUTH_USE_SESSION and LOGIN_EXPIRE_TIME. To enable persistent logins, you want to set the following in userconfig.cfg:
    AUTH_USE_SESSION = false
    LOGIN_EXPIRE_TIME = 2592000
    This will save a login cookie between browser sessions that expires after 30 days.

    The default value for AUTH_USE_SESSION is true, which makes LnBlog check the login cookie against a session variable on the server to prevent account stealing by reading client-side cookies. It's more secure, but less user-friendly. The default LOGIN_EXPIRE_TIME is set to false, which expires the login cookie when the session ends. Again, more secure but less friendly. To make it last longer, set this to the number of seconds after login that the cookie should expire.

    Thanks for thorough information

    Okay, I'm being stupid :) The only thing I know is that I never consciously *enabled* PrivateBlog - but I may be mistaken about that (I did install it, after all...). Thank you for the rest of the information - I think the settings are quite sensible as they are, but working with a software like LnBlog on a regular basis means having it handy any time I want it - having to log in is something like a show stopper (albeit only for some seconds ;)). But your explanation leads me to the conclusion that I want the AUTH_USE_SESSION to be as it is (namely, true). Would setting LOGIN_EXPIRE_TIME still enable me to come back as long as I keep my browser running and revive the session from within another tab/window? I'll try that out. If you have any clues for me about that matter, tell me.


    PLugin enabling

    Well, that's the point - all installed plugins are enabled unless you specifically *disable* them. To install a plugin, just drop it in an appropriate directory and it starts working. It's that way by design. In the case of the PrivateBlog plugin, probably shouldn't install that at all unless you really want one or more blogs to actually be private.

    I haven't tried it out, but my first thought is that setting LOGIN_EXPIRE_TIME will *not* have any effect as long as AUTH_USE_SESSION is true. That's because AUTH_USE_SESSION depends on session variables stored on the server and, generally, your PHP session cookie expires at the end of the HTTP session, i.e. when you close the browser. LOGIN_EXPIRE_TIME only controls the cookie set by LnBlog, not the ones set by PHP, so it doesn't control the same thing.

    That said, AUTH_USE_SESSION is a fairly paranoid setting. It's true that, if you turn it off, there is a chance that a malicious script could steal your authentication cookie. However, it's not a particularly big chance. User comments and trackbacks are already sanitized of all HTML code, so you should be protected against XSS attacks. That only leaves logging in on insecure systems, which shouldn't be a problem if you just remember to log out when you're done so that the cookie is destroyed.

    In fact, I forgot that I had left those two settings as they are. I was intending to set them to something more user-friendly in version 0.7.0, but I guess I just forgot about it. I'll probably do that in a future release, although they will remain configurable for the truly paranoid.