Comments on LnBlog 0.7.2 is up

  1. Upgrade successful...

    Okay, I'm back already - thanks for the fast upgrade, things work really well with the upgraded scripts.

    However, there are still a few things that could be addressed in a future maintenance (or major? ;)) release:

    1) The "Upgrade Blog" script still gives a full error: "Upgrade Status: Error: Upgrade exited with status 0." I know you didn't work on that now, but it's somewhat discomforting. Things work (as predicted by you) without problems, though. I started playing around with permissions to check if the problem was caused by the "Fix Perms" script - that seems to work (it claims to do so, anyway), but it doesn't change anything...

    2) When using the editor, the special symbols are always shown. I'm not sure if this is the case by default, but try as I might, I can't change (back?) that state - and I really don't need those symbols on a regular basis. I'd like to regain some screen real estate if possible. If there's an easy fix for that - no worries. But why not make it configurable?

    M.

  2. Issues

    I agree, the upgrade error messages need to be fixed. The upgrade code is extremely old (well, for LnBlog, at least) and wasn't designed to properly propogate specific errors up to the calling page. Basically, it was written so that the admin page calls the upgrade function and it returns a value that indicates whether or not there was an error, but not what it was or where it occurred. However, it's probably not going to be fixed for a little while because 1) it's an infrequently used function, 2) I'm trying to move away from requiring blog upgrades anyway, and 3) "improving error messages" is never at the top of a programmer's to-do list because it's not fun or interesting. However, I promise I will try to fix it eventually.

    As for the special symbols, they actually are configurable. There's just no GUI for the configuration. The default state should be that, if you're not using one of the rich text editor plugins, the special symbols box is collapsed by default and can be shown with the JavaScript link. You can completely disable the box by adding the following line to your LnBlog/userdata/userconfig.cfg file:
    EDITOR_SHOW_SYMBOLS=false
    Note that this file doesn't exist by default, so you'll have to create it. This is just a plain text configuration file with comments startins with a # character - nothing special, in other words.

    As a side note, most of the configuration constants in the blogconfig.php file can be over-ridden using the userconfig.cfg file. Pretty much any line that starts with an @ symbol, actually. I recommend that you override those variables in userconfig.cfg rather than actually editing blogconfig.php because that saves you from having to worry about conflicting versions or re-editing the blogconfig.php file with each upgrade.

  3. Very good!

    Okay, I understand and agree fully! In my opinion, I'd rather LnBlog move away from actually needing the "Upgrade Blog" function than that one display "richer" output, in fact - so if you can save time by not "enhancing" a deprecated functionalty, do it.

    userconfig.cfg is very good news indeed. I'll experiment with that asap.

    M.

  4. userconfig.cfg: Good Thing!

    userconfig.cfg works very satisfyingly - it's easy to set up and use, and blogconfig.php is well documented, so putting one together is really easy! I've now also discovered the documentation entry for it - meaning I could have found out things myself... However, wouldn't it be helpful if there was a link in the README to "Customize your LnBlog installation", pointing to the Natural Docs site? And there's a tiny flaw in the README: The techdoc link's dead... (I found that when I tried to make sure that I hadn't overlooked the link to the doc site somehow).

    M.

  5. Readme

    Sorry about that. I didn't think to up the documentation for this release.

    The Readme.html file is way out of date. Don't rely on it. I was keeping it around mainly because it had the LBCode documentation in it. However, that has been migrated over to the NaturalDocs version now, so I'll remove the Readme.html from the next release and replace it with a text file pointing to the REAL documentation.

  6. No worries...

    No problem at all - the Readme was still helpful in many ways, but the replacement's just as well, of course. I like Natural Docs - in fact we might use it for one of our own projects soon.

    M.

  7. Caught on!

    Okay, 0.7.2 proves to be stable and functional enough for me to migrate my site - it'll serve as main publishing tool as soon as migration's finished :) I've got two suggestions for future development:

    1) Templating is too hard compared to the overall flexibility of this amazing application. While there's no immediate need for that, I'd suggest developing a theming tool or mode one can handle from the admin level without having to edit files by hand. Compared to other site/blog tools like WordPress or Textpattern, this is the only real drawback.

    My idea would be to use a two-level facility: The first and very simple level would allow users to edit basic attributes like fonts (family, size, weight, decoration) and colors (background and foreground) within a given template. That could be done with a very simple interface: short descriptions, inputs for values, save and reset buttons, period (FYI: that's how it is done in phpBB and MyBB; and PunBB [which I also use] has its own templating tool called SpinkBB for that - that's nice, too, while it's not even integrated with the BB, but you get to download the necessary files in the end! WordPress and Textpattern need full CSS editing - not very catchy for average users, but of course very powerful in the hands of saisoned admins...). That'd make it easy to change things quickly. The second level would allow for the generation of a XHTML page template, using custom LnBlog tags to integrate plugins; rearranging the elements would cause a different screen display. Doing the second level could wait, really, but if you integrated something of this kind, you could easily beat the big players in terms of usability (editing a blog post is a breeze with LnBlog - I always catch myself working within the [now] test environment with LnBlog instead of my major site, since it's so much easier and thus, more fun). The exceptionally compact interface makes for a very pleasant blogging experience - templating would make generating output even more worthwhile.

    2) While comments are a convenient way to communicate publicly, it'd be nice if there was a - however simple - means of integrating a contact form - maybe as a plugin? The catch is to enable people to contact the blog owner without having to use e-mail, thus enhancing privacy. I don't think this is urgent in any similar way to what I said about templating (which isn't urgent either, you could just add a busload of value to your already great product with it!).

  8. Oops...

    I misspelled "seasoned" above ;) But I also forgot another hint: For the "second level" templating, I think looking at CMSimple might be an idea. It's very similar in usability, but even simpler (and thus, less flexible and less easily adaptable) than LnBlog, and it offers CSS and HTML editing of templates (however, the license obliges you to publish any work of that kind - they appear very strick about that, making it somewhat troublesome to simply experiment...). Since CMSimple is extremely compact, there must be a bearable way (workload-wise) of implementing such a solution. But beware - CMSimple is renowned for its obfuscated code (if this is done to prevent unwanted copying, I can't say - it's possible, I'm afraid; I think as long as credits are given, Peter Harteg isn't as tough as he might appear sometimes. However, he can't object to having a look at things...).

    M.

  9. Good suggestions

    Thanks for the ideas.

    Addressing the last point first, a simple contact form would be very easy to implement as a plugin. Properly integrating it into the user profile stuff would take a little time, but a simple "contact the author" link in the sidebar is maybe an hour's work. I have a maintenance release to make anyway, so I might be able to put together such a plugin before that.

    As for the theme system, I know it needs work. It's on the list. I do like your idea of a two-level approach to reforming it, though. The first level you describes sounds more or less like a user-friendly stylesheet editor. That seems like a really good idea and probably wouldn't be too hard to implement, as most of the page elements already have their own style sheets. I'll look at setting up something like that for version 0.8.0.

    The second level you describe would take some work. I like the idea of providing some more granular way to determine the layout of plugins. I don't know about custom tags, but perhaps some simple function to tell a plugin to put its interface elements in a particular place. I'll have to think about that one.

  10. If it helps...

    Peter,

    You're absolutely right about what the first templating level would mean - that's it.

    If you need any kind of insight I can set up some of the systems I mentioned for you to explore - phpBB is no problem to install, and CMSimple and even CMS Made Simple (another efficient CMS that implements custom tags called "html blobs") are a breeze to set up, too. I can give you admin access to those installations and provide downloads or links. Tell me if you need any kind of support of that sort.

    M.

  11. Thanks for the offer

    Thanks for the offer, but I don't think that will be necessary. I did a little looking and it turns out all three of those packages include an online demo, so I think I get the idea.

    For the first level, the phpBB style editor is basically the same kind of thing I was thinking. It could bascially create an additional style sheet to override the theme defaults. Or something like that.

    For the templates, I see what you mean with CMS Made Simple and the custom tags. I'm sure they're very handy, but I'd prefer to stick to PHP templates, because that way I don't have to write a parser or rely on a third-party template library. I'm also not entirely convinced that a custom template system is significantly easier for users than some simple PHP conventions to justify the extra effort. I'm thinking I lean toward something more like the CMSimple template, where the various key page elements are encapsulated in PHP functions.

    Incidentally, I put up a simple initial contact form. Not much - just a sidebar link that takes you to a page to e-mail the blog owner. I'll expand on that and add some integration with user profiles later. This is only the second stand-alone page plugin I've done, so the first version was mostly refining the design.

  12. Great!

    I'll implement the ContactForm plugin asap (it'll have to wait till Sunday, I think - June's not my friend as far as spare time is concerned).

    As for the other decisions, they're fine with me - I recommended C.M.S. because I'm familiar with it, but that doesn't mean that there aren't better solutions (or solutions better suited for LnBlog). If it's comparable to CMSimple, I'm happy. C.M.S.'s system has it's drawbacks (from a developer's point of view, in any case) because you need to modul-ise everything, even plugins (so that the template and the style sheet can be handled seperately from any content or information). I've been in touch with some modules' providers, and they were having hard times implementing their ideas. For users who want to control every aspect of the presentation solely by using XHTML and CSS, the approach is helpful, though. But then, if the system that's used is transparent and consistent, there's nothing to worry about. And your idea seems to work that way, so I don't see any reason to object.

    M.

  13. No hurry

    I'll be putting up a new release of LnBlog this weekend, so don't knock yourself out installing anything. I'm also going to upload a couple of new plugins tonight - a recent comments list and a new version of the private blog plugin (which I'll probably remove from base distribution in the next release ).

  14. Already seen the output...

    I've seen the output of the "recent comments" list already on your site - nice feature. I'm looking forward to getting around to upgrading.

    P.S. and hardly unrelated: That's what I'm seeing on top of my browser window:

    "Warning: loadplugins(plugins/sidebar_recentcomments.php): failed to open stream: No such file or directory in /home/httpd/vhosts/skepticats.com/httpdocs/LnBlog/lib/pluginmanager.php on line 173

    Warning: loadplugins(plugins/sidebar_recentcomments.php): failed to open stream: No such file or directory in /home/httpd/vhosts/skepticats.com/httpdocs/LnBlog/lib/pluginmanager.php on line 173

    Warning: loadplugins(): Failed opening 'plugins/sidebar_recentcomments.php' for inclusion (include_path='/home/httpd/vhosts/skepticats.com/httpdocs/lnblog:/home/httpd/vhosts/skepticats.com/httpdocs/LnBlog/userdata:/home/httpd/vhosts/skepticats.com/httpdocs/LnBlog') in /home/httpd/vhosts/skepticats.com/httpdocs/LnBlog/lib/pluginmanager.php on line 173

    Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/httpd/vhosts/skepticats.com/httpdocs/LnBlog/lib/pluginmanager.php:173) in /home/httpd/vhosts/skepticats.com/httpdocs/LnBlog/pages/showcomments.php on line 28"

  15. That's my fault

    I was just trying to add a quick feature (optionally show the commenter name next to the link) and was having trouble, so I deleted the plugin. However, I'd already moved it up the load list so it wan't at the bottom of the sidebar. The plugin manager tried to load it, but it wasn't there, and hence the error messages. I'll fix that for the next release.

Add your comments #

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