LnBlog 0.6.0 - No Need for passwd.php

LnBlog 0.6.0, "No Need for passwd.php," is now available. You can just grab the archive here or get it from the download page along with checksums and signature. The current documentation is available online or for download. The upgrade procedure is simply the usual process of uploading the new version and copying your existing userdata directory into it.

This release includes a number of new features as well as some file format changes. I'll start with the new features, since they're the point of interest for most people. For the full list of changes, please consult the change log.

The most obvious change is the addition of a native search plugin in the sidebar. The old search plugin (which is still included, but disabled by default) just ran your query through Google, which obviously didn't work if your site hadn't been indexed by Google. The new search utility will simply scan all blog entries for the strings in the search box. You can simply separate all your search terms by spaces and it will return a list of all entries that contain all the terms. Alternatively, you can search using a regular expression by enclosing the expression in slashes (e.g. /micro.*/ would find references to Microsoft.). Note that all searches are case-insensitive.

The next big user-visible change is that the JavaScript post editor has been reworked. First, the controls are smaller and look nicer, plus you can click the (+) and (-) links to hide them. Second, the dual text and attribute boxes for entering the markup are now gone. When you click an editor button, a JavaScript popup will prompt you for the text, just as in most other JavaScript editors. (Anybody who actually liked the text box approach can re-enable it by adding EDITOR_SHOW_INLINE_BOXES=1 in your userconfig.cfg file.) Also, if you select some text and then click an editor button, it will simply apply the markup to that text, e.g. select a word and click the bold button to apply bold tags. Last, you'll notice a section, hidden by default, which contains buttons that add HTML entities for various mathematical symbols. I added these because I wanted them, so feel free to ignore them. You can even turn them off by adding EDITOR_SHOW_SYMBOLS=0 in your userconfig.cfg file.

The last big new feature is the addition of user profiles. When you click on the name of a post owner, it will now take you to that person's user profile. This is just a page that displays the person's name, e-mail address, homepage, etc. You can also upload files to your profile and add custom HTML markup to the end of it. All this is done through the "Edit user information" page linked in the sidebar.

In addition to the basic profile information mentioned above, you also have the ability to add custom fields to be displayed in profiles. This is done by creating a profile.ini file, which has the format:
[profile fields]
fieldname=Description of the field
secondfield=Another field description

You can put this either in your userdata folder, in which case the custom fields will apply to all users, or in a single user profile directory, which will make them apply to only that user.

Note that the addition of user profiles also means a change in the files used to store user information. In other words, the LnBlog/userdata/passwd.php file is no longer needed. New account information will be stored under the user's profile directory. The password information will be in a passwd.php file and the other profile information in a user.ini file. Note that reading the old passwd.php file is still supported, so there is no need to run any kind of update utility. When you edit a user's profile, it will be automatically converted to the new format.

There is also another file format change. The blog data is now stored in a blogdata.ini file. This probably seems pretty pointless, but the general idea here is to try to gradually move away from the plethora of ad hoc file formats that I started with. As with the user information, reading the old blogdata.txt file is still supported, so there's no need to do anything special. The next time you edit your blog settings, the file will be automatically converted to the new format.

Before I forget, I should probably mention the other noticeable changes in this version. First, there's now a blog setting for the default markup mode (auto, LBCode, or HTML) to use for entries. Second, there are now separate options for turning off comments and trackbacks on individual entries. Third, the setting to turn on comments and trackbacks for articles now actually works. Forth, the articles sidebar plugin has a few new options, including the ability to add custom links. The edit link is in the articles section of the sidebar and it uses the same type of format as the sitemap, i.e. a list of hyperlinks separated by newlines.

I think that pretty much covers it for this release. If you have any questions, comments, or find any bugs, please feel free to e-mail me or leave a comment. On the off chance that anyone is interested, I also welcome contributions of code, themes, plugins, or pretty much anything else.

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 #

    The 0.6.0 package came out with /userdata full of files from your development installation

    It took some time to understand why the installation process didn't succeed as the doc said. /userdata must be wiped out after unzipping...

    Crud...

    Why do I always do that? Oh, well. It's fixed now. Thanks for letting me know.

    Possible bug?

    After that, I started testing LnBlog, which seems quite a neat project. I'm stuck, anyway, on a strange behavior. After creating a blog, I placed my first entry on it. Comments do work well, but it seems that backtrack and other advanced features (delete, upload and so on) are getting a malformed link, looking like this.
    http://machinename/blogpath/2006/03/ENTRYNAME.phpfunction.php
    If I can understand what you were doing, I believe it should have been like this:
    http://machinename/blogpath/2006/03/ENTRY_ID/function.php
    as each entry seems having its own directory with function files within it.
    At this time, I'm pretty unsure about the cause. At a quick glance, it would seem that lib/blogentry.php's uri function might be malfunctioning or not properly called where needed; unless I have a configuration error of my own somewhere, obviously. Could you give me a hint? Thank you.

    OOPS!

    While reporting the URLs I forgot /entries before /2005/03. Sorry. You know, here it's 12.30AM...

    Yeah, I know

    Thanks for the feedback. I really appreciate all the help I get on this project.

    I actually already know about the URI problems and have implemented a fix. I've just been busy and haven't gotten around to uploading it. However, a new version is now available from the download page. Thanks for the prod! ;)

    OK, keep up with the good job

    Upgraded to 0.6.1. Didn't know you were already aware of that, sorry for bothering. LnBlog is running even too smoothly for its version number, anyway. ;-) Will keep walking up & down to get familiar with the other features. Although a lot smaller than other "blog with database, warp engines and coffeemaker" projects, LnBlog is bigger than it may seem. The only useful thing it may lack (if I didn't miss some of its features) is IMHO the capability to set up a "private" blog, readable only by enabled users. But if it wasn't within the original scope of the project, it doesn't actually matter. I'll probably spend some time on 0.6.1 to understand the mechanism for languages support, too.

    Meanwhile, thank you for everything you're already doing.

    Thanks

    Like I said, I appreciate all the feedback I get, even if it's something I already know. It's just good to know there are people other than me who are actually using it.

    Private blogs was not something I ever really considered adding because it's not a feature I would use. However, it's certainly worth thinking about. I was planning to revamp the user security system to include groups anyway, which would integrate nicely with that. In fact, now that I think about it, it's probably already possible to implement private blogs as a plug-in. I'm not sure how well it would work, but in theory it would certainly be possible to block access to the content of posts from all but a given list of logged-in users.

    If you're interested in the internationalization support, I should probably mention that I can use all the help I can get on that. It's essentially untested, owing largely to the fact that I'm the only developer and I speak only English. I'm sure there are still many issues with it, especially when it comes to character encoding.

    Thank you for your kind words. Feel free to drop me a line if there's anything else I can help you with.

    Unofficial quick+dirty fix for malformed URIs

    Works in /lib/blogentry.php within 0.6.1; it might elsewhere, too. It took a bit of time to follow the code and see that themes always referred to PERMALINK in order to activate commands.

    // $tmp->set("PERMALINK", $this->permalink() );
    $tmp->set("PERMALINK", $this->uri("") );

    Actually, that's another problem

    Thanks for pointing that out. Using the non-pretty permalinks will certainly fix the immediate problem. However, the underlying problem is that the themes should NOT be using $PERMALINK for commands anymore. Do you remember which themes and/or files you had problems with?

    Theme using PERMALINK is Terminal

    Yep; see above. I had even forked out a couple of my own versions with different colours (it's so minimal I liked it a lot). If it was just that, then I'll drop it at the next release, restarting from scratch and going on staging with other themes. I do not have LnBlog currently "in production", keeping a blog is just an idea at this time; so, testing is not a problem.
    Meanwhile, I found myself partially rewriting a function in /lib/nativefs.php, in order to have entry deletion working properly.

    function rmdir($dir) {
    exec("rm -rf $dir");
    return true;
    // return rmdir($dir);
    }

    It seems that PHP's rmdir() was called while expecting the directory to be empty, which was not; thus giving back an error. This patch is probably done only in order to match my own modification of the links: in fact, it seems that blog entries stay in the blog/entries/YYYY/MM folder after deletion. They don't work properly, anyway, without their own directory. I've surely forgot to remove the main file, too. :)

    Thanks again

    Boy, how did I miss that one? It turns out that the rmdir() error was actually in rmdir_rec(). Somehow I managed to type != instead of == on the check for . and .. entries, so it was ignoring everything EXCEPT . and .., which is exactly the opposite of what I intended. The same bug existed in ftpfs. It probably happened when I switched from calling scan_directory() to opendir(). Well anyway, it'll be fixed in the next release. Thanks for cluing me in on that one.

    And thanks for reminding me to adjust the entry deletion code to remove the pretty-permalink wrapper scripts. That never really occurred to me before.

    As for the terminal theme, I'll fix that in the next release. It only has the one template that needs to be updated.

    Thanks again for all the help!

Add your comments #

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