Comments on LnBlog 0.7.0 Released

  1. Back after first tests...

    Hello, Peter.

    I'm afraid to say I haven't got good news: I tried to install LnBlog on my new server space - but I think it warps up because of the virtual server configuration (it's a shared server) - I couldn't get it configured; paths get always reset to bogus values. I haven't tried using URLs instead of local paths - would that be an option?

    M.

    • Comment posted on Thursday 14 Dec 2006 at 5:33pm
    • By MoonMind

  2. LnBlog virtual server config

    M,

    I am using LnBlog in virtual servers (Apache, Debian stable) and UK2.net (don't know what they use but it is a shared server) with no problems. Can you give an example of the bogus paths you get? When do the paths reset - how far into setting up LnBlog do you get?

    Neal.

    • Comment posted on Thursday 14 Dec 2006 at 5:33pm
    • By Neal Harrington

  3. Still no luck?

    Boy, I guess the gods of PHP don't like you.

    First, are you trying to move old data to the new server, or are you starting fresh? If you're starting with a completely fresh installation of LnBlog 0.7.0, then everything should just work. Shared hosting shouldn't be a problem - I use shared hosting myself, so the software is designed to work with it.

    If you're trying to copy old data to the new server, then you will need to delete the LnBlog/userdata/fsconfig.php file and recreating by going to the admin page. You will also need to delete the pathconfig.php file from each blog directory and run an upgrade on each blog to recreate it.

    As for URLs instead of local paths, there's a small chance it might work if PHP has URL wrappers installed, but I wouldn't count on it. I certainly haven't tested it and didn't write the code with that possibility in mind.

    Either way, some error messages would be helpful. If you know the paths are wrong, it might be helpful if you could say what the path is supposed to be in addition to the path in the error message.

  4. Sorry for the delay...

    I'll be back with more news soon - there have been problems with paths caused by the server's setup, so it may (again!) have nothing to do with LnBlog after all. But I'm getting a little frustrated - I'd really like to use the software and I see the potential... I'm completely occupied by job related issues for the time being, but I'll give it another shot as soon as the work load lightens...

    • Comment posted on Thursday 14 Dec 2006 at 5:33pm
    • By MoonMind

  5. No rush

    I wish I could be more helpful here. It's just hard for me to get a handle on exactly what's going wrong.

    LnBlog shouldn't need anything special in terms of server paths. It needs to know the document root of the web server and the FTP root if you're using FTPFS. Those are both set when the file writing is configured and, in most cases, should be correctly auto-detected. The only other paths that should matter in version 0.7.0 or the LnBlog installation path, which is auto-detected when the blog is created and added to the pathconfig.php, and the blog root, which is now auto-detected based on the current directory, and so isn't actually hard-coded anywhere.

    In terms of file security (I'll use UNIX octal permissions, for NativeFS, the LnBlog/userdata directory and each blog directory, including all files and subdirectories, need to be set to 777. For FTPFS, you just need read/write access for whatever user account you're using for FTP.

    If you're having problems with one file writing method, you might test out the other. Just start with a fresh user userdata directory and create the blogs in a fresh directory. Also, note that if you use NativeFS, you'll want the directory you create blogs in to be owned by your user account (e.g. create it by hand through FTP), because otherwise you might have problems deleting them.

  6. A little hint

    What happened was this: Auto-detection worked (correctly!), but the server handled virtual paths inconsistently - there's (was?) a folder called "virtual" where all our user folders reside in, and this one got picked up by the installer first, but then wasn't saved with the rest of the path, thus, this folder was missing in the path, and try as I might, I couldn't change that in a satisfying manner - probably because the server rejects internal (or at least certain types of) requests for the folder. I hope they have solved that problem by now, so I'll retest soon. Now DNS and everything else runs smoothly - it might work now. But I'll have to wait until I see some spare time again...

    • Comment posted on Thursday 14 Dec 2006 at 5:33pm
    • By MoonMind

Add your comments #

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