MKDoc Developers

MKDoc-dev is the main list for MKDoc developent.

Latest posts on MKDoc-dev

patch to add option to automatically link to siblingdocuments: Currently MKDoc automatically links to child dcouments, this patch adds the option to link to sibling documents too. By default it is disabled, it can be enabled by adding this to the httpd-env.conf file: SetEnv MKD__LINK_SIBLINGS TRUE It also adds two more methods available to template writers: document/siblings document/siblings_showable Both return lists of siblings of the current document. They are different from these methods which also include the current document in the list: document/parent/children document/parent/children_showable
updated patch to remove lib::sql from MKDoc-1.6: I've been running several sites for months with this patch applied. It allows the complete removal of the lib/ directory from the MKDoc-1.6 sources, though it does require the MKDoc::SQL module from CPAN.
Re: Perl 5.8.8 Encode problem,was: Re: FC5 i386 RPMS for MKDoc: Hi On Tue 20-Jun-2006 at 10:54:35AM +0100, Chris Croome wrote: It turned out that the fix resulted in only US-ASCII working so I have reverted the update -- the latest MKDoc in CVS now requires Encode 0.09 or earlier, the bug page has been updated: http://www.mkdoc.org/bugs/stable/normal/perl-588/ Chris
Re: Perl 5.8.8 Encode problem,was: Re: FC5 i386 RPMS for MKDoc: Hi On Mon 19-Jun-2006 at 05:40:47PM +0100, Chris Croome wrote: This bug is now fixed in CVS, if you don't want to run the CVS version then be sure to have Encode 0.09 or less. Chris
Re: Perl 5.8.8 Encode problem,was: Re: FC5 i386 RPMS for MKDoc: Hi On Mon 19-Jun-2006 at 03:12:43PM +0100, Chris Croome wrote: Actually you can do a --force install of a perl-Encode RPM and this works, I have just built RPMS of all versions of Encode back to 0.08 and tested them and 0.09 is the last working version. I have added this RPM to the repo: http://rpms.mkdoc.com/pub/apt/fedora/linux/5/i386/RPMS.mkdoc/perl-Encode-2.09-8.i386.rpm Install it like this: rpm -Uvh --force perl-Encode-2.09-8.i386.rpm Chris
Perl 5.8.8 Encode problem,was: Re: FC5 i386 RPMS for MKDoc: Hi On Wed 05-Apr-2006 at 12:46:39PM +0100, Chris Croome wrote: However it has now been discovered that the version of Encode that comes with Perl with FC5 doesn't work properly with MKDoc: http://www.mkdoc.org/bugs/stable/normal/perl-588/ So, for the moment, if you want to run MKDoc on FC5 best install perl manually in /usr/local/ or use an older distro like CentOS 4... Chris
Re: [BUG] CheckUser.pm usage results in MKDoc sites beingblackholed: Hi On Mon 05-Jun-2006 at 02:06:28PM +0100, Chris Croome wrote: This was fixed yesterday in CVS, it was just a matter of setting two variables in Subscribe.pm so if you are not using the CVS version it's easy enough to fix, details here: http://www.mkdoc.org/bugs/stable/resolved/helo/ Chris
input: Trade Date: Tuesday, June 6th, 2006 Company: BioElectronics Corporation Symbol: BIEL Price: $0.025 IS MOMENTUM BUILDING FOR THIS STOCK? CAN YOU MAKE SOME FAST MONEY ON IT? RADAR BIEL FOR TUESDAY'S OPEN RIGHT NOW!! THE ALERT IS ON!!! RECENT NEWS HEADLINE: (GO READ ALL THE NEWS ON BIEL RIGHT NOW!) BioElectronics Corporation Announces New 510(k) Market Clearance Application Filed With FDA!! About BioElectronics Corporation (Source: News 5/18/2006) BioElectronics currently manufactures and sells ActiPatch(TM), a drug-free anti-inflammatory patch with an embedded battery operated microchip that delivers weeks of continuous pulsed therapy for less than a dollar a day. The unique ActiPatch delivery system, using patented technology, provides a cost-effective, patient friendly method to reduce soft tissue pain and swelling. GO READ ALL THE NEWS ON THIS ONE!! DO YOUR DUE DILIGENCE!! RADAR IT FOR TUESDAY'S OPEN NOW! ______________ Information within this report contains forward looking statements
[BUG] CheckUser.pm usage results in MKDoc sites beingblackholed: Hi One MKDoc server keeps getting listed on the CBL email spam list: http://cbl.abuseat.org/ And I think I have tracked this down to the use of Mail::CheckUser in flo/plugin/Account/Subscribe.pm -- this is what the CBL says: The Perl CheckUser module defaults to improper "HELO" and "MAIL FROM" strings: "localhost.localdomain" and "check-ASQrhD/3864< at >public.gmane.org" respectively. The former is illegal, the latter impersonates user.com - they probably don't like that. [Besides, by not using your own domain, some spam filters will lie to your RCPT TO.] You will need to change $Helo_Domain = to be "<DNS name of your server>" and change $Sender_Addr to be something in _your_ domain (eg: "check< at ><mydomain>") http://cbl.abuseat.org/linuxnonserver.html And if you run ethereal and capture the helo MKDoc does indeed use the default of localhost.localdomain and the default email address of check-ASQrhD/3864< at >public.gmane.org so I think this solves this mystery... All that is needed now is for
[bug] 1.6 linked images: Hi Images that have titles that match the title of a link component have a bug in the way their links are constructed. For example, on a site with http://www.example.org/ for the public and http://users.example.org/ for admin: - Upload a image titled "example" - Add the text "example" to a text component - Create a /about/example/ document - Add a link component with the title set to "example" and the uri to "/about/example/" Then in the public interface everything should be fine, the text "example" and the image example both link to http://www.example.org/about/example/ But when in admin the text links to http://users.example.org/about/example/ but the image links to http://www.example.org/about/example/ -- ie the public interface not the users interface. There is nothing in the template that contains the domain name so this bug must be in the code. Chris
[SOLVED] MKDoc requires CGI.pm 3.11 or earlier,was: Re: [1.6] Redirect bugs?: Hi On Thu 06-Apr-2006 at 10:56:23AM +0100, Chris Croome wrote: I thought it might be down to CGI.pm, these changes seem like they could have perhaps broken MKDoc: Version 3.13 1. Removed extraneous empty "?" from end of self_url(). Version 3.12 7. The url() and self_url() methods now work better in the context of Apache mod_rewrite. Be advised that path_info() may give you confusing results when mod_rewrite is active because Apache calculates the path info *after* rewriting. This is mostly worked around in url() and self_url(), but you may notice some anomalies. Version 3.11 3. Workaround for a bug that appears in Apache2 versions through 2.0.54 in which SCRIPT_NAME and PATH_INFO are incorrect if the additional path_info contains a double slash. This workaround will handle the common case of http://mysite.com/cgi-bin/log.cgi/http://www.some.other.site/args, but will not handle the uncommon cas
Re: [1.6] Redirect bugs?: Hi On Wed 05-Apr-2006 at 05:52:23PM +0100, Chris Croome wrote: Doesn't appear to be -- I have switched to 1.3.33 and there is still this odd behavior, for example: lynx -head -dump "http://www.fc5.webarchitects.co.uk:8080//photo.jpg,html" HTTP/1.1 302 Moved Date: Thu, 06 Apr 2006 10:23:18 GMT Server: Apache/1.3.33 (Unix) mod_perl/1.29 Location: http://www.fc5.webarchitects.co.uk:8080/photo.jpg%2Chtml Connection: close Content-Type: text/plain The server is redirecting to a page with an escaped "," -- this isn't a client issue. But note the // in the request address above, if the request is made without out it then the "," isn't escaped: lynx -head -dump "http://www.fc5.webarchitects.co.uk:8080/photo.jpg,html" HTTP/1.1 200 OK Date: Thu, 06 Apr 2006 10:26:14 GMT Server: Apache/1.3.33 (Unix) mod_perl/1.29 Connection: close Content-Type: text/html; charset=UTF-8 So this appears to be a template bug, but the templates haven't changed
[1.6] Redirect bugs?: Hi There seem to be a odd redirect bug with the latest CVS version of MKDoc 1.6, for example if you add a photo attachment to the front page of a site, and then go to view the scaled version then you get a redirect loop and an address like this (this is truncated): /photo.jpg%2Chtml/photo.jpg%2Cscaled/photo.jpg-html/photo.jpg-scaled/photo.jpg-html/ Another way to trigger the bug is to edit the front page and then save it, you get redirected to a 404: /.admin.content/ It appears that something is adding an extra / onto URLs? This could be an issue caused by using Apache 1.3.34 -- but there is nothing in the list of changes from version 1.3.33 that appears to be behind this... Or perhaps the latest Mozilla / Firefox browsers are munging the URLs -- they seem to be escaping "," to "%2C" which they didn't do before (this is on Fedora Core 5) but IE 6 also seems to escape "," so perhaps it's apache doing this rather than the clients... I'll try to do some debugging to see if I can track this down fur
FC5 i386 RPMS for MKDoc: Hi I have created some RPMS for i368 FC5 for MKDoc dependancies, there are less than ever (7) since most modules are now available from elsewhere, these are the ones needed on a FC5 web server / software developer install: ================================================================================= Package Arch Version Repository Size ================================================================================= perl-Lingua-31337 noarch 0.02-8 mkdoc 7.0 k perl-Locale-Maketext-Gettext noarch 1.17-8 mkdoc 39 k perl-MKDoc-Text-Structured noarch 0.83-8 mkdoc 26 k perl-MKDoc-XML noarch 0.75-1.2.fc5.rf dries 67 k perl-Mail-CheckUser noarch 1.21-8 mkdoc 23 k perl-Mail-IMAPClient noarch 2.2.9-1.2.fc5.rf dries 152 k perl-Petal noarch 2.18-8
Re: Patch to remove lib::sql module from MKDoc-1.6: [removal of lib::sql and replacement with MKDoc::SQL] This patch needs to be applied in addition to the previous patch. Index: tools/cron/020..newsletter.pl =================================================================== RCS file: /var/spool/cvs/mkd/tools/cron/020..newsletter.pl,v retrieving revision 1.1.2.18 diff -r1.1.2.18 020..newsletter.pl 225c225 < my $con = lib::sql::Condition->new(Editor_ID => $user->id); --- 249c249 < where => lib::sql::Condition->new(Document_ID => $doc->id) --- 411c411 < my $query = new lib::sql::Query ---
Fwd: [berend-KOTWUV+Y4CI< at >public.gmane.org: [rest-discuss] Cookie-less HTTPauthentication how-to available]: Hi We need to study this -- Berend has found some bugs and fixes for HTTP authentication and Apache 2.2 and mod_perl :-) Chris ----- Forwarded message from Berend de Boer <berend-KOTWUV+Y4CI< at >public.gmane.org> ----- From: "Berend de Boer" <berend-KOTWUV+Y4CI< at >public.gmane.org> Date: Wed, 15 Mar 2006 21:35:41 -0000 To: rest-discuss-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org List-Id: <rest-discuss.yahoogroups.com> Subject: [rest-discuss] Cookie-less HTTP authentication how-to available Hello All, There has been a lot of discussion in the past about how to do pure HTTP authentication without cookies. I've seen one solution posted to this list, by Jean-Michel Hiver, however it is outdated as his code doesn't work with the latest Apache + mod_perl, and he doesn't clearly indicate the limitations against all modern browsers. And I prefer to use Digest authentication instead of Basic. As I had a need for this myself, I've taken the plunge and done a really exhaustive examination of doing authentication without c
Re: [1.6 bug] Using self/parent/parent for detectingwhere one is in the document hierarchy: Re-read my email. If an object or document possibly doesn't exist, you have to test for its existence before trying to access methods. This assumes that self/parent exists: <div petal:condition="true: self/parent/parent; false: self/parent/parent/parent;" > This code makes no assumptions: <div petal:condition="true: self/parent; true: self/parent/parent; false: self/parent/parent/parent;" >
Re: [1.6 bug] Using self/parent/parent for detectingwhere one is in the document hierarchy: Hi On Fri 24-Feb-2006 at 12:48:23PM +0000, Bruno Postle wrote: I know this should work but it doesn't seem to -- for example try this code in a document:   <div petal:condition="false: self/parent;" > This document has no parent therefore it must be the front page. </div>  <div petal:condition="true: self/parent; false: self/parent/parent;" > This document has a parent but no grand parent, therfore it must be a child of the front page document. </div>  <div petal:condition="true: self/parent/parent; false: self/parent/parent/parent;" > This document has a parent and a grand parent, therfore it must be a grandchild of the front page document. </div>  <div petal
Re: [1.6 bug] Using self/parent/parent for detectingwhere one is in the document hierarchy: If self/parent doesn't return a document, then calling a method on this non-object can't possibly work. Test for the existence of self/parent first: <h1 petal:condition="self/parent"> This document has a parent called <span petal:replace="self/parent/title">Mavis</span> </h1> <h1 petal:condition="self/parent; self/parent/parent"> This document has a grandparent called <span petal:replace="self/parent/parent/title">Betty</span> </h1> <h1 petal:condition="false: self/parent"> This document doesn't have a parent :-( </h1> <h1 petal:condition="self/parent; false: self/parent/parent"> This document doesn't have a grandparent :-( </h1>
DC Metadata RDF files listing hidden documents: Hi I just noticed that the .meta.rdf files list hidden child documents, I have fixed this in CVS: https://lists.webarch.co.uk/pipermail/mkdoc-commit/2006-February/001097.html Chris
[1.6 bug] Using self/parent/parent for detecting whereone is in the document hierarchy: Hi If some functionality is needed based on where one is in the document hierarchy then using things like this mostly works: petal:condition="true: self/parent/parent; true: self/parent/parent/children" Or: petal:condition="false: self/parent/parent/equals ancestor;" But if a document doesn't exist when testing for a parent/parent (for example when a template designed for grandchild pages is used for child pages) then there is an internal server error rather than Petal returning false and things like this are written to the apache logs: [PETAL ERROR] Cannot find value for 'equals' at '/self/parent/parent': equals cannot be retrieved (current value was undef, near self/parent/parent/equals ancestor) at /usr/lib/perl5/site_perl/5.8.6/Petal/Hash/Var.pm line 125 Which is rather inconvient... Chris

Links

Sign Up

MKDoc Developers

Archives

Latest posts on MKDoc-dev