A new test release

Well, I've been slowly plugging along at LnBlog 0.4.0 for a while now, and I have a test release for anyone who cares. Feel free to grab the 0.4.0 alpha 1 release and give it a spin. Note that this requires upgrading you blogs. Since this isn't a stable release, you might consider making backup copies of your blog files and you old LnBlog installation. Also note that the passwd.php, fsconfig.php, and sitemap.htm files have moved from the LnBlog installation root to the userdata subdirectory.

There's still a lot of polishing work to be done and not many visible changes, so don't get too excited. I've added a few small usability enhancements, such as smarter redirects and form field highlighting, but the big change is the addition of a plugin system. It's an event-driven plugin system, if that means anything to you, which allows plugins to be added or over-riddenon both a system wide and per-blog basis. In fact, as of today, the banner, menu bar, and side bar are all created using plugins.

Don't look for a stable release any earlier than a few weeks from now. There's still lots of coding and testing to do, plus I'm way behind on documentation. I'm working on some technical documentation (e.g. for plugin authors) as well as adding some comments in the code for auto-documentation using Natural Docs.

I think I'm done adding features for the 0.4.0 release, but I'm already thinking about 0.5.0. One thing I'd like to do is add some plugins or conditional features to take advantage of Apache's .htaccess files. In particular, I'd like to try to use mod_rewrite to get rid of the need to upgrade the PHP wrapper scripts in each blog data directory. Another cool thing would be to add alternate implementations of the back-end classes so that data could be stored in a MySQL database. The idea is that you could simply set a single configuration variable to switch between file and database storage. I've already tightened the encapsulation of the back-end classes in preparation for something like that, but it's still a long way off.

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 #

    Concerning v0.3.4

    Hello,
    How do I login as a user, different from administrator?

    update to the previous

    I've figured out, that I've just got to add 'login.php' to web address I'm going to, and then respectively the login page will be shown.

    Well, that's OK, but I think that some obvious way to reach the subject should exist, like for example adding a link 'Login' or something to the sidemenu.

    Thanks for attention

    Bug with unicode symbols

    Hello,
    that's me again :)

    The very first attempt to post messages containing cyrillic symbols has ended up into text, consisting of ampersands followed by symbol codes.

    After viewing the posting HTML-source, the problem has been detected. The blog engine doesn't seem to convert "& a m p ;" escape sequences back to ampersands before returning the posting text to user.

    Here's an excerpt therefrom:

    <div class="blogentrybody">
    <p>&amp;#1055;&amp;#1088;&amp;#1080;&amp;#1082;&amp;#1088;&amp;#1091;&amp;#1090;&amp;#1080;&amp;#1083;. &amp;#1059;&amp;#1089;&amp;#1090;&amp;#1072;&amp;#1085;&amp;#1086;&amp;#1074;&amp;#1080;&amp;#1083;. &amp;#1047;&amp;#1072;&amp;#1087;&amp;#1091;&amp;#1089;&amp;#1090;&amp;#1080;&amp;#1083;. &amp;#1056;&amp;#1072;&amp;#1073;&amp;#1086;&amp;#1090;&amp;#1072;&amp;#1077;&amp;#1090;.</p></div>
    <div class="blogentryfooter">

    Thanks in advance

    About login

    Sorry for being unattentive. There IS a link :|

    Sorry, again.

    About Unicode

    My expedient solution was to add these lines to "entry.php":

    function bbcodeToHTML(...)

    ...
    $patterns[19] = "/&amp;/Usi";
    ...
    $replacements[19] = '&';

    And everything worked just fine.

    On Unicode

    WGM,

    Thanks for all your feedback! The translation of ampersands in Unicode HTML entities is not a bug - it works that way by design. Posting in LBCode mode isn't *supposed* to allow HTML entities because the entire point of LBCode is to give non-technical users a simpler markup language. The idea is that the user can type in pretty much any text he wants and it will be displayed as he typed it. This includes typing in HTML code and having it displayed as the code.

    If you need to use HTML code in your post, then try using the "allow HTML markup" mode for your post. This "raw HTML" mode will leave your code completely untouched, so Unicode won't be a problem. Of course, you'll have to enter line breaks and paragraphs manually, and there are still some issues with the preview mode, so it's not a perfect compromise. Although, if you're writing entire posts in Unicode, I'm assuming you use an HTML editor rather than type all the escape sequences manually, so that probably isn't an issue. (That reminds me - I've had the "new post from uploaded file" feature on the TODO list for a while now. Maybe that would be a good compromise.

    Once again about Unicode

    >Although, if you're writing entire posts in Unicode,
    >I'm assuming you use an HTML editor rather than type
    >all the escape sequences manually

    In fact, I just switch into Cyrillic keyboard layout and type message text. And the effect is, as follows. A far as I can figure out, the engine converts cyrillic symbols into escape-sequences. Then the ampersands in escape-sequences are in turn also converted into escape-sequences. And then the stuff is stored in XML-file. When in goes to rendering the posting, the engine just takes the raw contents of the appropriate field in XML-file and places it into HTML-output, and example of which has been shown before in my posting at 2005-10-09 23:58 CDT.

    I'll type now some text in Russian for you to show the effect, before I've applied that expedient solution.

    "&#1055;&#1088;&#1086;&#1073;&#1072; &#1088;&#1091;&#1089;&#1089;&#1082;&#1086;&#1075;&#1086;", &#1095;&#1090;&#1086; &#1087;&#1086;-&#1072;&#1085;&#1075;&#1083;&#1080;&#1081;&#1089;&#1082;&#1080; &#1079;&#1085;&#1072;&#1095;&#1080;&#1090; "Probe of Russian"

    No Subject

    > Posting in LBCode mode isn't *supposed* to allow HTML
    > entities because the entire point of LBCode is to give
    > non-technical users a simpler markup language.

    That's why I was saying my solution was expedient. For I don't know the whole inside of your software.

    No Subject

    s/expedient/crude/ - after one year without practice of English it has become a little rusty. Sorry.

    Interesting...

    Well, that's very interesting. I'll definitely have to figure out a way of handling this, but I really don't know how I'll do it just yet.

    I'm not set up to type Cyrillic characters, but I was able to copy and paste some into a form field. It appears that PHP's htmlentities() is trying to convert the raw Unicode characters into escape sequences and doing a pretty bad job of it. However, there also seems to be an issue with how the text is encoded when it is sent to the server, as Opera and Konqueror are giving me different encoding when I view the source. Konqueror is showing all numeric encodings, like you posted, but Opera is showing my symbolic encodings, like &ETH;&Ntilde;&ETH;&frac34;. If you don't mind my asking, what browser and character encoding are you using?

    It looks like this will especially be an issue with comments. For blog posts, the author can simply revert to HTML mode, as previously noted. However, for comments, I don't think it's a good idea to allow raw HTML code in them, but I'm not sure of another good way to sanitize user input without htmlentities(). I think this one is going to take some time, meaning I can't promise it will be fixed in version 0.4.0, although I may include a work-around of some kind.

    No Subject

    Mozilla, ISO-8859-1 (default for pages, generated by your blog engine) which means that Cyrillic characters will be treated as Unicode characters.

    Concerning blog posts (not comments) you were right

    Everythings works fine, when I choose option "Allow HTML markup". In other cases the problem persists.

    Concerning encodings. Before entering a text of blog post or comment I tried to switch browser to different Cyrillic character codings. And in all cases Cyrillic characters were treated as if they were Unicode characters. The results varied from encoding to encoding (because character codes do not coincide in different encodings). The common thing was that in case of every encoding the characters were converted to escape-sequences; and unlike the case of "HTML markup" in the cases of "BB markup" or "auto markup" these escape-sequences were stored in XML-file with ampersands converted into escape-sequences (&amp;), too.

    I'd say, that I wouldn't concentrate too much on correct handling of encodings, but I'd pay the main attention to the fact, that in cases of "BB markup" and "Auto markup" the ampersands in escape-sequences standing for some character (for example, the escape-sequence &#1072;) are being in turn converted to &amp; before they are stored in XML-file.

    In case of "HTML markup" the ampersand is kept untouched.

    No Subject

    s/BB markup/LBCode markup/g

    Ad hoc fix

    I've made an optional ad hoc fix to the code to account for this. I've added a configuration constant, UNICODE_ESCAPE_HACK, to control it.

    By default, LnBlog will now use htmlspecialchars() for escaping user entered text in LBCode and auto-markup modes. This translates only a very limited subset of possible HTML entities and does not include Unicode characters. When the above mentioned constant is enabled, it will revert to htmlentities() with a regular expression that unescapes the ampersand in numeric entieies.

    This fix will be in version 0.4.0. It's not perfect, but at this point, I think it's better than nothing.

Add your comments #

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