Comments on Version 0.4.0 is finally up

  1. A trouble with adding new posts

    Hello :)

    I've experienced a difficulty with adding new posts, the topic of which contained Cyrillic characters.

    The error message was "Error updating blog entry"

  2. Re: A trouble with adding new posts

    Boy, you aren't having much luck, are you? ;)

    Can you give me some more information? I can't duplicate this problem based on what you've posted. I tried copying some Cyrillic text into the subject and body of a new entry and it worked fine. Is it just Cyrillic text or do you have the same problem with Latin text, e.g. 7-bit ASCII characters? Did you get any PHP error messages?

    That error means the entry insert function returned false, which means one of three things:
    1) There was an error creating the entry files and/or directories. This is usually accompanied by PHP error messages and often indicates a file permissions problem.
    2) The logged in user doesn't have permission to add entries. However, if you aren't logged in properly, you should get redirected to the login page.
    3) The entry directory already exists. This usually means that you tried to post two entries to the same blog in less than a minute. I should probably adjust the code to account for this, but haven't gotten to it yet.

  3. Now everything's clear

    Item 3 of your list indicates exactly what has happenned.

    Because when I tried to make new posts much later, it was added.

    > Boy, you aren't having much luck, are you? ;)
    No, like many Russians, I have a talent of challenging the reliability of virtually anything, down to titanium balls for ball-bearing. :D There's even a funny story about that. And that's also why AK has been designed to be that reliable.

  4. LBCode markup and Auto-markup

    I'd also like to mention, that the problem with ampersands, described before, still exists, when I choose LBCode markup or Auto-markup.

    That is, ampersand in escape-sequence, like &#XXXX; is converted to & As the result, the initial sequence is stored in XML as &#XXXX;. Then this resulting sequence is put out without any transformation, and in HTML-source we have &#XXXX;, in the browser we see &#XXXX;, but not the symbol, encoded by that #XXXX.

    When I choose HTML markup, everything's OK.

  5. "Remember me" small bug (feature?)

    I mean the checkbox "Remember me" in the form for adding comments.

    It remembers me only after second comment posted. Well, the sequence of my actions is as follows. I launch my browser and go to this site; click any "View readers comments" link; write a comment, generally speaking fill in the form; I never entered my e-mail, and always left that checkbox checked. The system never remembered me after the first comment, only after the second one.

    Is it meant to be so, or?

  6. No Subject

    I mean I had to write one more comment, and fill in the form. And only after this the system remembered me

  7. Re: LBCode markup and Auto-markup

    I just tried it on a Windows/IIS sever and noticed the same thing. For some reason, I didn't see it under Linux/Apache.

    Anyway, there is a new UNICODE_ESCAPE_HACK configuration constant that you can change that should fix this. It worked for me, at least. The default setting is "false", which uses the PHP stripslashes() function to sanitize input. Setting it to "true" will switch to using htmlentities() followed by a substitution of HTML-escaped ampersands with actual ampersands, which should make the Unicode come out right.

    The constant is located in the blogconfig.php file, but I recommend using the new userconfig.php file to set it. This file is intended for over-riding settings in blogconfig.php and does not exist by default. All you should need to do is create a file named "userconfig.php" in your "userdata" directory and add the following text to it:
    <?php
    define("UNICODE_ESCAPE_HACK", true);
    ?>

    Note that you must not include any blank lines outside the PHP tags.

  8. Re: "Remember me" small bug (feature?)

    Yes, I see what you mean. That's definitely a bug, not a feature. Unless, of course, you like to refer to your bugs as "undocumented features." :)

    Anyway, thanks for pointing that out. I'll look at that and fix that for the next maintenance release.

  9. No Subject

    I'm using Win2000 + Apache 2.0.53.

    Yes, with UNICODE_HACK_DATA it works fine. :)

    >Anyway, thanks for pointing that out.
    You're always welcome.

  10. Some suggestions

    It would be great, if after processing file upload the system were generating it's URL and showing it in response somewhere near the message

    'File foo.bar successfully uploaded'.

    I think so, because a user usually selects file name from dialog, not types it in by hand... Or even pastes in the full path... That is, in most cases the input for this field is generated automatically. Thus a user can avoid typos.

    And automatically generated URL would be great in turn for copying it and pasting it in... well, in the right place. And user once again can avoid typos.

    Thanks for attention

  11. Re: Some suggestions

    Sounds like a good idea to me. I'll put something like that in the next release, either a new line or maybe change the filename to a link.

    Now that you mention it, some better file upload management would be a good addition. I'll have to think about that for a future release.

  12. Is something wrong with LBCode markup implementation?

    In the text of current blog post there's a line

    [numlist]

    So, it's clear, that this is LBCode 'tag'. How did it leak into HTML output?

  13. Re: LBCode

    > So, it's clear, that this is LBCode 'tag'.
    > How did it leak into HTML output?

    Oops! Thanks for pointing that out. That showed up because I forgot to add the closing [/numlist] tag when I was typing the post. In other words, user error. ;)

  14. Localization conflict

    Here are some lines from HTML-source of output

    This line in addition specifies the character encoding of HTML document

    <meta http-equiv="Content-type" content="text/html; charset=iso-8859-1" />

    And these two lines are generated automatically for each blog post and comment:

    <li class="blogdate">Posted 2005-10-27 15:44 &#1043;&#1088;&#1077;&#1094;&#1080;&#1103;, &#1058;&#1091;&#1088;&#1094;&#1080;&#1103; (&#1083;&#1077;&#1090;&#1086;)</li>
    <li class="bloguser">By administrator</li>

    As far as I understand, the string for "blogdate" is generated by some function, which relies on localization options of the machine, on which the whole system runs. Speaking about my machine, which runs W2000, that string has CP1251 character encoding. Because of the fact, that document character encoding and the string character encoding do not coincide, I see in my browser the characters, which are quite not Cyrillic (different accented Latin letters).

    It would be great, if Unicode was in use everywhere in the blog engine. Just EVERYWHERE.

    You know, there are at least 4 Cyrillic character codings in use (CP1261, CP866, KOI8-R, Mac; there are also Cyrillic character codings, specific to other languages, using that alphabet - Bulgarian, Serbian, etc...) And we've got some kind of tired with converting texts from one charset to another. So, as for me, Unicode would be the best choice.

    Thanks for attention

  15. Mmmm. A comment on the previous comment

    There were Cyrillic letters instead of escape-sequences in the previous comment

    In HTML-source, that I've been viewing, there were just Cyrillic letters, not escape-sequences.

  16. Re: Localization conflict

    I agree, there are definitely some i18n issues to work out. For instance, there is still an awful lot of hard-coded English text. I'm working on it, but it will take some time. After all, this is currently a one-man project and I don't have a lot of internationalization experience.

    Regarding the previous comment, I changed the config on my server to use the UNICODE_ESCAPE_HACK, so now it IS Cyrillic text. I guess I'll have to work on that some more, because something strange is happening. When I post Unicode text in HTML mode and look at the raw data file, it shows HTML escape sequences, even though LnBlog leaves the input alone in HTML mode. I'm guessing it's some server setting, because it doesn't happen on my Kubuntu system.

    The META tag for content type is set by the Page class. To be honest, I got lazy and just hard-coded the default character set to iso-8859-1 because that's what I used for all the templates. The next release will have a configuration constant to control this. I'll actually try to make it pick up the charset from the PHP configuration.

    You are correct about the post date. It is generated by strftime(), which uses your locale setting. From what you're telling me, I guess this includes the character set, although the strftime() documentation make no mention of character encoding. The username is taken directly from the passwd.php file and the HTML and the words "Posted" and "By" are all part of the default templates. Since the templates are all encoded to ISO-8859-1, I'm not sure how that will interact with the Windows localized time zone. You might be able to change the PHP configuration to set the character set, but I don't know if that setting applies to this situation. I understand what you are saying though - mixing character sets is definitely a problem, especially when you consider that Windows uses a two-byte character set.

    Eventually, I plan to move all the literal text out of the code and into templates and/or a separate file that can be easily translated. I just haven't gotten to designing and implementing that yet.

  17. No Subject

    >Eventually, I plan to move all the literal text out of
    >the code and into templates and/or a separate file that
    >can be easily translated. I just haven't gotten to
    >designing and implementing that yet.

    I usualy create a simple XML file with strings, like this

    ...
    <StringName1>bla bla bla</StringName1>
    ...

    And access the strings using DOM or Delphi XML to DataSet transformation facilites.

    And I keep several such files, translated in different languages (English, German, Russian, Ukrainian).

  18. Re: No Subject

    > I usualy create a simple XML file with strings

    That's pretty much what I was thinking, although I'll probably just do it in a PHP file rather than bothering with XML. An associative array would give the same effect, plus it would be easier to implement and not add the overhead of an XML parser. What would be really nice is to do a GNU gettext kind of thing, where strings are enclosed like this:
    _("A string")
    That way, the English strings themselves are used as keys for the translated strings. However, I'm not sure how well something like that would perform in PHP.

    The main thing I'm unsure about is what to do with templates. On the one hand, it would be easier to maintain if the templates themselves didn't contain any natural language text. On the other hand, that would make them considerably harder for non-programmers to modify.

Add your comments #

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