LnBlog 0.6.5 "No need for config.php"

Well, I've finally done my lst-minute cleanup and my highly irresponsible testing, resulting in LnBlog 0.6.5 now being available for download. You can grab the ZIP archive here, or get the documentation, checksums, and all that good stuff from the download page.

Before I list the changes, I'd like to thank MoonMind for providing lots of feedback and bug reports.. Thanks also to Ben Schorr for the bug reports. Improving software is always easier when you get helpful feedback.

There are a number of noteworthy changes in this release. First, it is important to note that the config.php file format has changed. This means that you must upgrade your blogs immediately after uploading the new version. To do this, login to your LnBlog administration page, enter the path of the blog (the same one you gave when you created it) in the "upgrade to current version" box, and click the upgrade button. You must do this for each blog you have.

The reason for this change is to facilitate changing the LnBlog installation path/URL and the blog URL. In older versions, these paths and URLs were stored in the config.php file in each directory. However, since these paths were computed automatically, there was no easy way to change them. Now, the config.php files simply include a pathconfig.php file which is located in the blog root. The blog root is calculated at run-time based on the type of directory, i.e. how far it is from the blog root. This allows you to more easily adjust these paths and URLs. Of course, most users won't need to do this, but for those who do, it is now easy. There's even a graphical interface for it. You can find the link on the weblog settings page.

The other noticable changes have to do with plugins. The new version of DisableComments is standard in this release. This version includes a feature to automatically disable comments and trackbacks on posts more than a certain number of days old.

I've also added two new plugins. The first, which is disabled by default, is the PrivateBlog plugin. When loaded, this allows you to set a list of users who are allowed to read the blog. Any user who is not on this list (and can't post to the blog) will simply be redirected to the blog login page. Not an idea solution, but it's more of a proof of concept than anything else.

The second new plugin is ContentBan. This plugin allows you to create files which contain lists of regular expressions to ban. You simply specify the regular expressions, one per line and complete with delimiters and options (using PHP's PCRE syntax), and any comment or trackback that matches one of those expressions in any of its fields will be refused. Of course, you should use this with care, as it is easy to be overzealous in your banning. Also, an ill-formed regular expression can cause errors that prevent anyone from posting.

Lastly, there's also a small interface change. I thought the administration sidebar panel was getting crowded, so I created a new event for sidebar plugins to capture. There is now a separate sidebar panel for plugin configuration and configuration links generated by plugins. Hopefully, that will make things slightly cleaner.

That's pretty much it for the interesting changes. The rest are mostly small bug fixes and expanded documentation. See the change log for full details. As usual, if you find any problems, please e-mail me or leave a comment.

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

Comments #

    Good idea, but some issues...

    I'm back with more testing - not as much as I would wish for, but I'm busy with some other projects, so I have to keep my activities in check.

    I like the new concept, and pathconfig.php is really a good way to go. However, when I tried it out, it failed, giving the following error message:
    "Warning: fopen(BLOG_ROOT/pathconfig.php): failed to open stream: No such file or directory in /var/www/blog/lib/nativefs.php on line 105"
    This might well be due to a permission problem, but I can't figure out which one (I don't want to chmod 777 everything just in case...). I'm not using safe_mode on my box, so this can't possibly be the reason. If I could solve this, my outside tests will succeed, I'm quite convinced.

    As for other ideas, I've found some sidebar plugins that produce very similar output to be done slightly different; after I had done my own template, this led to some ugly results. It's easy to correct that by editing the markup part of the plugins themselves, but I don't think may people will do that gladly. Notably, the RSS buttons and the "Powered by" button look very similar, but are placed differently and behave differently on mouseover. In the default template, this isn't visible, but if you change colors, it becomes very obvious.

    As for theming in general, it'd be nice to have a single CSS file somewhere. It could/should be heavily commented to reflect what does what (I'd help with that as much as time allows); at some time in the distant future, you could even make it editable from within LnBlog configuration - possibly even via a nice little front end; to illustrate what I'm thinking about, take a look at SpinkBB, the theme generator for PunBB, here: http://www.jsand.net/spinkbb/?lang=en

    I wouldn't say that this whole theme business is extremely important, though. But for people like me who have existing websites and need (or want) a consistent look overall, it could prove very helpful, because working through several plugins' files AND having to do that again after each update isn't a good thing. That goes for markup changes and CSS (CSS isn't too bad already - I had but one single change to redo after the latest update).


    Regarding the pathconfig.php problem, did you already run an upgrade on your blog first? That has to be done first to clear all the old junk out of the config.php files. As for permissions, the blog root directory needs to be 777, but that should be it. That's assuming, of course, that it's not an ownership issue.

    For the plugins, I think I see what you mean about the images. The "powered by" link is just using stupid markup and needs to be fixed. For the RSS links, I get your point about the inconsistency, but I guess I'm not sure why the markup needs to be changed. As I recall, the only difference between that and the other lists is the the class on the list items. The purpose of that was to get rid of the color change on mouse-over, because I thought it looked strange. If you remove the style for that class, then the difference should go away. I'm not a CSS expert, so maybe there's a better way to handle that.

    My rational behind the theme system was to make it easy to override small parts of a theme without having to make large numbers of changes. So, for example, you can just create a BLOG_ROOT/themes/banner.css file to do a custom banner. Likewise, you can override the RSS feed icons by creating a new BLOG_ROOT/images/rss2_button.png file. The idea was to give the user the flexibility to change small aspects of a theme without having to worry about maintaining the rest of it.

    Whether that's a good idea or not is certainly up for debate. I go back and forth on whether a more understandable theme system would be better or if it's better to focus on flexibility. Frankly, I don't know what the best answer is. However, I do know that I won't be making any big changes to it any time soon. The theme system may have its problems, but it at least works. There are lots of other things I want to do, and I have relatively little time to devote to this program, so the theme system is a fairly low priority right now.

    Problems not yet solved

    Thank you for the detailed reply.

    I did a complete reinstall (I'm still testing LnBlog, it's not in productive use up to now, so there's no trouble), so that's not the problem. However, chmod 777 -R myblog (on the blog's root, that is) didn't help. Neither did chmod 777 blog (the LnBlog root). Maybe I'm not choosing the right format for the changes? We'll have to investigate that further (at least, I will). However, I'm out of town for a few days, so we'll have to postpone that a bit.

    As for theming: It's not a big issue in my eyes: It works, and the themes that come with the standard installation are usable. I just meant to indicate that there are other ways, maybe even ones that serve both purposes (modularity AND structural integrity). I'll

    I'll look into that CSS change you indicated - maybe my idea of solving things was wrong.


    Well, I'll be out of town from Friday to Monday, so a guess a postponement is good.

    Just to check, I'm not sure I was entirely clear when I said "upgrade". I was talking about doing an upgrade on the wrapper scripts in your blog, not the LnBlog files. Unless you're modifying the classes in the LnBlog/lib directory, a clean install of LnBlog should have nothing to do with it. I mean you go to your LnBlog admin page, put myblog (or whatever the document-root-relative path to the blog is) in the "upgrade blog to current version" box, and click the "upgrade" button. This will overwrite all the old config.php scripts and create pathconfig.php in the process. If that's what you did, then I apologize for sounding like a bad technical support line. I just want to double check.

    Incidentally, there are another couple of things to note on upgrades. First, running multiple upgrades on a blog won't hurt anything. A blog upgrade just refreshes all the wrapper scripts to what the currently installed version of LnBlog is expecting. Second, for some LnBlog versions, an upgrade of all blogs is *required* before anything will work. The 0.6.4 -> 0.6.5 upgrade is such a case. If you try to access the blog before running an upgrade, you *will* get errors.

    By the way, I know the whole upgrading wrapper scripts thing is a huge pain, and I'm currently working on making it optional. In the 0.7.x series (which will be a development series), I'll be working on allowing the use of either the old wrapper scripts or query strings made pretty with Apache mod_rewrite rules.

    Getting back to the point, if running a blog upgrade doesn't fix the problem, then here are a few questions I would like to know the answer to:
    1) On which page, exactly, did you see this error? This isn't while you're running an upgrade, is it?
    2) When you posted the error message, did the screen actually say "BLOG_ROOT/pathconfig.php", or did you substitute BLOG_ROOT for the path it actually displayed?
    3) If you create a new test blog, do you still have the same problem?
    At this point, I'm just trying to get a little more information and determine if this is a bug in LnBlog or a server issue. Half the point of LnBlog is to keep the server requirements to a minimum, so there souldn't be anything special you need to do. But, of course, you never know.

    Lastly, regarding the themes, I agree with you that there are probably better ways to do it. I don't claim to be an expert on the subject. Someday I would like to improve the theme system, but right now I'm the sole developer and I just don't have the time. If anybody out there wanted to get involved with development, though, that would probably be a good place to start.

    Upgrade worked, but still no joy

    No, I hadn't done the upgrade to the blog (myblog) on purpose - however, pathconfig.php was there, so maybe I did after all... I did the upgrade step now (or again?), but it didn't help.

    I can reinstall at any given time if that helps, but since I'm rather busy at the moment, I'd like to have your go-ahead on that (if you think it might help, of course).

    Here are the answers to your questions:

    1) I logged into my blog (not LnBlog, the blog itself); then I clicked my way "Edit weblog settings" -> "Edit paths for blog", then deleted the "http://localhost" part of the "Blog root URL" and the "LnBlog installation URL" (I'm not sure if the second is needed or not, but since "localhost" seemed to cause problems, I tried it all the same; besides, only changing the root URL didn't work, either). When submitting these changes (I tried various times with and without leading "/"), the abovementioned error message appeared.

    Now, if I need to change the URL to my server's URL, I won't be able to administer (or even read) the blog from home - and I don't see any other possibility. IP? But wouldn't that mess with redirects? I'm stuck on this issue. I guess it's my fault because I simply don't know how to update the paths correctly...

    2) The error message appeared exactly the way I pasted it here.

    3) Yes, I had exactly the same problems, even after an upgrade.

    As for the themes: I can't code PHP, so I can't help much; moreover, my time's too limited at the moment to even consider helping out. But I'll contact you as soon as I see a way in which I could be helpful. For now, things work in that respect, so don't worry, I'd say. I'm much more interested in getting LnBlog to work on my personal server (I guess pathconfig.php makes it possible to do so on my hoster's server with FTP, but I'd love to have it right here, too!).

    Must be missing something

    OK, I must be missing something here, because this should be easy. At this point, I'd say the easiest thing to do would be start fresh.

    From your previous posts, it sounds like you're using native file writing on a UNIX or Linux system running Apache and that you have root access. If that's the case, then try the following. I'll give step-by-step instructions, just to be clear.
    1) Make backup copies of your old LnBlog folder and blog folders.
    2) Start with a fresh installation of LnBlog 0.6.5. Copy over the user profile directories under userdata from the old installation, but nothing else yet.
    2) Run:
    chmod -R 777 /path/to/LnBlog/userdata
    3) Go through the initial file writing setup and choose nativefs. At this point you should have a working LnBlog installation.
    4) Create a new directory under your document root named test1 and set the permissions to 777.
    5) Log in to the LnBlog admin page and create a new blog. Give test1 as the path and just fill in the other fields with junk.
    6) Now go to the test1 blog in your browser and try to edit the blog paths like before. If it works, then the software is working as expected and you should go on to the next step. If not, then something is very, very wrong and I would like to see the exact error messages and the contents of the test1/pathconfig.php file.
    7) Make a copy of the old blog you've been having trouble with and put it in the document root. I'll refer to the blog folder as myblog.
    8) Run the following command on the myblog folder:
    find /path/to/myblog -name '*.php' -exec rm {} \;
    That will delete all the wrapper scripts from the copy of myblog. This will allow us to keep the data, by start completely fresh on the configuration.
    9) Now log in to the LnBlog admin page and run an upgrade on the myblog folder, as we discussed previously. This will recreate all the wrapper scripts and will also create a fresh pathconfig.php file.
    10) Now log in to myblog and try to edit the path. If this fails, please let me know the error messages and the contents of myblog/pathconfig.php. If it works, then we can go from there.

    Reinstall required

    I've already prepared everything for a reinstall, so working on the nonfunctional installation isn't an option, but I'll do exactly as you say in the reinstall - it'll have to wait till Friday or Saturday, though. I'll be back with any result as soon as I find enough time.

    Just to let you know

    I'll change my provider this month. After that, I'm a lot more flexible; I'll do a reinstall of LnBlog on the new server and follow your tutorial by the letter - sorry for the delay, but I think it's more reasonable to test in the intended environment.

    No problem

    Take as long as you like. I'm in no hurry. Just let me know how it goes.

Add your comments #

A comment body is required. No HTML code allowed. URLs starting with http:// or ftp:// will be automatically converted to hyperlinks.