I have been having a great time with Movable Type recently, and so I plan to migrate the Docunext blog to MTOS very soon. I still have a lot to learn with ikiwiki, so for now I’m sticking with MediaWiki.
Archive for the 'Docunext' Category
Looks like the new version of sitecopy in Squeeze is having problems. I get this error:
sitecopy: Error: Could not connect to server...
I did a quick search and someone else is having the same problem. Doh!
I downgraded to the one from Etch, which requires libneon26, and that works.
Hmmm, I think whatever is wrong here might be due to libneon27, as I’m not able to use svn either!
This might be the problem: Debian Bug report logs - #531338 :: svn: OPTIONS of ‘http://…’: could not connect to server (http://…)
Yup, needed to update libneon27 and libneon27-gnutls from sid.
I setup a cronjob for:
/usr/share/movabletype/tools/run-periodic-tasks
to be run as www-data.
I also symlinked /etc/movabletype-opensource/mt-config.cgi to that directory.
What’s more, I have hacked up a few things which should really be configurable. For example, the template for pop-up windows of image thumbnails is in /usr/share/perl5/MT/Asset/Image.pm (on Debian). I changed it to use thickbox:
< q|%s|, < MT::Util::encode_html( $asset->url ), — > q|%s|, > MT::Util::encode_html( $popup->url ), > MT::Util::encode_html( $popup->url ), > $asset->image_width, > $asset->image_height,
Then I was trying to get my Multiblog MT install to publish its static resources to a central repository, similarly with uploaded assets. This has proved practically impossible, unfortunately. There is a way I found to do it in a somewhat logical manner… the database stores the asset with a prefix of “%r” which is the blog path. Its possible to use “%s” as the static path, or “%a” for the archive path.
I want better control over the publishing paths for assets and such for caching as well as file distribution. It makes sense from time to time to serve large files like images differently than small html / javascript / css.
I do have to say that the assets functionality it pretty awesome. They’ve done some really impressive work on managing images - great work Six Apart!
Preparing to replace libxml-sax-perl 0.96+dfsg-1 (using libxml-sax-perl_0.96+dfsg-1_all.deb) ... Unpacking replacement libxml-sax-perl ... Setting up libxml-sax-perl (0.96+dfsg-1) ... update-perl-sax-parsers: Registering Perl SAX parser XML::SAX::PurePerl with priority 10... Fatal: cannot call XML::SAX->save_parsers_debian(). You probably have a locally installed XML::SAX module. See /usr/share/doc/libxml-sax-perl/README.Debian.gz . dpkg: error processing libxml-sax-perl (--install): subprocess post-installation script returned error exit status 1 Processing triggers for man-db ... Errors were encountered while processing: libxml-sax-perl
I was able to work around this using:
cd /usr/local/share/perl/5.10.0/XML/ mkdir dnu mv SAX* dnu/ apt-get install libxml-libxml-perl