Nabble - MKDoc

Problem with photo creation dates

2007-04-02T09:13:18Z

Hi,

I've found what I consider to be a flaw with the creation date field on photo
components.

I am currently creating a page on our website which uses a number of old
photographs. The year they were taken is known, but not the actual month and
day. Annoyingly, I have to know all three...

However, this is not the main problem - I'm just putting anything for the final
two parts! - what IS a problem is that I am being told that 1950 and 1948 are
NOT valid dates. Of course, they ARE valid dates, but I'm guessing MKDoc must
have a list of years that don't go back as far as the invention of photography.
Or even the first of the last century!

I think this is something that should be fixed, OR the creation date should be
made truly optional, and NOT be replaced by today's date if you try and leave
it blank!

Jamie
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Adding sitemap in templates

2007-02-07T10:16:25Z

Hi,

I've had an idea for a template that I'm currently calling 'Default Sitemap
Bottom', but I'm not sure how to create it and make it work, and would
appreciate some help.

Basically, it's a bit like the child listing template, but it also shows
grandchildren, great grandchildren etc... just like the sitemap! But doesn't
list the page you're currently on, and only lists sub pages of the section you
are in - nothing above.

I see the listing being more like the old static sitemap, albeit with
descriptions as well. Maybe later have a go at doing a 'dynamic sitemap bottom'
template!

I suspect this can be done as a template, as the functionality for the sitemap
exists - I'm just not sure how to incorporate.

Is it doo-able do you think?

Jamie
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: Newsletter 'reply-to' address

2007-01-18T03:19:59Z

Hi

On Thu 18-Jan-2007 at 10:53:09AM +0000, Jamie Marriott wrote:
>
> <From petal:content="string:${root_user/real_name}
> <${root_user/email}>">MKDoc <newsletter@...></From>
>
> Is it a simple matter of just replacing this with:
>
> <From>enquiries@...</From>

Yes, that's it :-)

Chris

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Newsletter 'reply-to' address

2007-01-18T02:53:09Z

Hi,

When a user signs up for email updates, the 'reply-to' email address of
their newsletters is the one used by the Admin user. I might want to
change this to use a general email address, but without changing the
admin account email.

I think the place to do this is in the newsletter en.xml file, and I
suspect involves modifying the following code:

<From petal:content="string:${root_user/real_name}
<${root_user/email}>">MKDoc <newsletter@...></From>

Is it a simple matter of just replacing this with:

<From>enquiries@...</From>

Or is there there more to it than this

Jamie
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: Formatting in descriptions

2006-12-14T05:30:32Z

Hi

On Thu 14-Dec-2006 at 01:07:22PM +0000, Jamie Marriott wrote:
>
> As both sites run on the same server, and presumably run off the same
> MKDoc installation, I'm assuming this is somehow related to information
> somewhere in the templates - I'm just not sure where to find it!

I think this thread explains it:

http://comments.gmane.org/gmane.comp.cms.mkdoc.devel/297

Chris

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Formatting in descriptions

2006-12-14T05:07:22Z

Hi,

On our new Burngreave Messenger MKDoc website, I've noticed that text
in descriptions can be formatted in the same way as text in a text
component (with bulleted lists etc.).

However, this is not the case on the older BNDfC site. Here the
formatting just doesn't work.

As both sites run on the same server, and presumably run off the same
MKDoc installation, I'm assuming this is somehow related to information
somewhere in the templates - I'm just not sure where to find it!

Could you let me know if I'm right in thinking this? If not, what would
be the way to 'upgrade' an older site to do this, or is it not possible?

Jamie

_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

patch to add option to automatically link to sibling documents

2006-08-17T06:10:56Z

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

--
Bruno

Index: flo/Editor.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/Editor.pm,v
retrieving revision 1.12.2.50
diff -r1.12.2.50 Editor.pm
223a224,236

> # plus we want to hyperlink all the siblings
> if (MKDoc::Config->LINK_SIBLINGS) {
> foreach my $sibling ($document->siblings_showable)
> {
> push @links, {
> class => "mkdoc-name-". $sibling->name,
> href => $sibling->uri,
> desc => $sibling->description,
> expr => $sibling->title,
> lang => $sibling->lang,
> }
> }
> }

Index: MKDoc/Config.pm

===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Config.pm,v
retrieving revision 1.8.2.49
diff -r1.8.2.49 Config.pm
177a178,184
> sub LINK_SIBLINGS
> {
> my $class = shift;
> return get_env ('MKD__LINK_SIBLINGS') || undef;
> }
>
>
Index: MKDoc/Site/ConfigWriter/Httpd_Conf.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Site/ConfigWriter/Httpd_Conf.pm,v
retrieving revision 1.1.2.46
diff -r1.1.2.46 Httpd_Conf.pm
228a229,231
> # uncomment this if you want to automatically link to sibling documents
> # SetEnv MKD__LINK_SIBLINGS TRUE
>
Index: flo/Record/Document.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/Record/Document.pm,v
retrieving revision 1.25.2.73
diff -r1.25.2.73 Document.pm
1664a1665,1721

> ##
> # $self->siblings;
> # ----------------
> # Returns a list of all sibling documents of this document
> ##
> sub siblings
> {
> my $self = shift;
> my $args = { @_ };
>
> $self->{'.siblings'} ||= do {
> my $parent = $self->parent();
> if ($parent)
> {
> my @siblings;
> for my $sibling ($parent->children())
> {
> push @siblings, $sibling unless $self->equals ($sibling);
> }
> \@siblings;
> }
> else
> {
> [];
> }
> };
>
> my @res = @{$self->{'.siblings'}};
>
> my $with = $args->{'with'};
> $with and do { @res = map { @{$_->components ($with) } ? $_ : () } @res };
>
> my $without = $args->{'without'};
> $without and do { @res = map { @{$_->components ($without) } ? () : $_ } @res };
>
> return wantarray ? @res : \@res;
> }
>
> ##
> # $self->siblings_showable();
> # ---------------------------
> # Same as siblings(), except returns only showable documents.
> ##
> sub siblings_showable
> {
> my $self = shift;
> my @res;
> if (flo::Standard::current_user && flo::Standard::current_user->is_editor)
> {
> @res = map { $_->is_showable_to_editor() ? $_ : () } $self->siblings;
> }
> else
> {
> @res = map { $_->is_showable() ? $_ : () } $self->siblings;
> }
> return wantarray ? @res : \@res;
> }

_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

updated patch to remove lib::sql from MKDoc-1.6

2006-08-17T06:10:37Z

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.

--
Bruno

Index: MKDoc.pm
===================================================================
RCS file: /var/spool/cvs/mkd/Attic/MKDoc.pm,v
retrieving revision 1.15.2.36
diff -r1.15.2.36 MKDoc.pm
37,38c37
< use lib::sql::DBH;
< use lib::sql::Table;
---
> use MKDoc::SQL;
Index: MKDoc/Handler/GroupAuthz.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Handler/Attic/GroupAuthz.pm,v
retrieving revision 1.1.2.2
diff -r1.1.2.2 GroupAuthz.pm
28a29
> use MKDoc::SQL;
99c100
< my $con = lib::sql::Condition->new(Editor_ID => $user->id);
---
> my $con = MKDoc::SQL::Condition->new(Editor_ID => $user->id);
128c129
< where => lib::sql::Condition->new(Document_ID => $doc->id)
---
> where => MKDoc::SQL::Condition->new(Document_ID => $doc->id)
Index: MKDoc/Handler/Initialize.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Handler/Initialize.pm,v
retrieving revision 1.1.2.20
diff -r1.1.2.20 Initialize.pm
31,32c31
< use lib::sql::DBH;
< use lib::sql::Table;
---
> use MKDoc::SQL;
Index: MKDoc/Site/Deploy/DB/Driver.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Site/Deploy/DB/Driver.pm,v
retrieving revision 1.1.2.6
diff -r1.1.2.6 Driver.pm
197,204c197
< use lib::sql::Category;
< use lib::sql::Table;
< use lib::sql::type::Char;
< use lib::sql::type::DateTime;
< use lib::sql::type::Int;
< use lib::sql::type::Text;
< use lib::sql::type::LongText;
< use lib::sql::DBH;
---
> use MKDoc::SQL;
Index: MKDoc/Site/Deploy/DB/Schema.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Site/Deploy/DB/Schema.pm,v
retrieving revision 1.1.2.7
diff -r1.1.2.7 Schema.pm
37,44c37
< use lib::sql::Table;
< use lib::sql::Category;
<
< use lib::sql::type::Char;
< use lib::sql::type::DateTime;
< use lib::sql::type::Int;
< use lib::sql::type::Text;
< use lib::sql::type::LongText;
---
> use MKDoc::SQL;
Index: MKDoc/Util/LinkParser.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Util/Attic/LinkParser.pm,v
retrieving revision 1.1.2.7
diff -r1.1.2.7 LinkParser.pm
135c135
< use lib::sql::DBH;
---
> use MKDoc::SQL;
Index: flo/Standard.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/Standard.pm,v
retrieving revision 1.12.2.14
diff -r1.12.2.14 Standard.pm
37c37
< use lib::sql::Table;
---
> use MKDoc::SQL;
Index: flo/Record/Ticket.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/Record/Ticket.pm,v
retrieving revision 1.16.2.7
diff -r1.16.2.7 Ticket.pm
75c75,76
< use lib::sql::Condition;
---
> use MKDoc::SQL::Condition;
> use MKDoc::SQL;
330c331
< # note: using NOW() doesn't work (it's quoted by lib::sql::Condition) so
---
> # note: using NOW() doesn't work (it's quoted by MKDoc::SQL::Condition) so
332c333
< my $cond = new lib::sql::Condition;
---
> my $cond = new MKDoc::SQL::Condition;
Index: flo/editor/Headlines.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/editor/Headlines.pm,v
retrieving revision 1.4.2.34
diff -r1.4.2.34 Headlines.pm
485,486c485,486
< use lib::sql::Condition;
< my $cond = new lib::sql::Condition;
---
> use MKDoc::SQL::Condition;
> my $cond = new MKDoc::SQL::Condition;
Index: flo/plugin/Headlines.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Headlines.pm,v
retrieving revision 1.1.2.11
diff -r1.1.2.11 Headlines.pm
97,98c97,98
< use lib::sql::Condition;
< my $cond = new lib::sql::Condition;
---
> use MKDoc::SQL::Condition;
> my $cond = new MKDoc::SQL::Condition;
Index: flo/plugin/Sitemap.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Sitemap.pm,v
retrieving revision 1.7.2.15
diff -r1.7.2.15 Sitemap.pm
50c50
< use lib::sql::Condition;
---
> use MKDoc::SQL;
Index: flo/plugin/Account/Reminder.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Account/Attic/Reminder.pm,v
retrieving revision 1.14.2.9
diff -r1.14.2.9 Reminder.pm
81c81
< my $condition = new lib::sql::Condition();
---
> my $condition = new MKDoc::SQL::Condition();
Index: flo/plugin/Admin/Move.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Admin/Move.pm,v
retrieving revision 1.1.2.8
diff -r1.1.2.8 Move.pm
163c163
< use lib::sql::Condition;
---
> use MKDoc::SQL::Condition;
166c166
< my $condition = new lib::sql::Condition();
---
> my $condition = new MKDoc::SQL::Condition();
Index: flo/plugin/Admin/UserModify.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Admin/UserModify.pm,v
retrieving revision 1.1.2.6
diff -r1.1.2.6 UserModify.pm
152c152
< where => lib::sql::Condition->new(Grp_ID => $id,
---
> where => MKDoc::SQL::Condition->new(Grp_ID => $id,
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);
---
> my $con = MKDoc::SQL::Condition->new(Editor_ID => $user->id);
249c249
< where => lib::sql::Condition->new(Document_ID => $doc->id)
---
> where => MKDoc::SQL::Condition->new(Document_ID => $doc->id)
411c411
< my $query = new lib::sql::Query
---
> my $query = new MKDoc::SQL::Query

_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: Perl 5.8.8 Encode problem, was: Re: FC5 i386 RPMS for MKDoc

2006-07-03T03:53:48Z

Hi

On Tue 20-Jun-2006 at 10:54:35AM +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.

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

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

[SPAM] [MKDoc-users] [SPAM] FINAL AWARD WINNING NOTIFICATION!!!!!!

2006-06-20T05:59:46Z

CONTINENTAL EMAIL LOTTERY PROGRAM
AVENIDA DE LA CRUZ 1 PISO 6G 28923
MADRID ESPAÑA.
DATE: JUNE 20TH, 2006.
FROM:
THE DESK OF THE VICE PRESIDENT
INTERNATIONAL PROMOTIONS/PRIZE
AWARD...
BATCH: EGGS-304-082-444
REFERENCE:12/13/MGM

AWARD NOTIFICATION.
This is to inform you on the release of the CONTINENTAL E-MAIL LOTTERY held on the 7th of June 2006.
The results was released on the 9th of June 2006. Your email address was attached to ticket number 686-055-075-435 with serial number 111-947-214 which drew lucky numbers 17-87-45-82-66 and won the lottery in the 1st category.
You have therefore been awarded a lump of 550,000.00(FIVE HUNDRED AND FIFTY THOUSAND EURO ONLY) cash credited to file with REF: N EGS/227/858/333 This is from 5,500,000 (FIVE MILLION FIVE HUNDRED THOUSAND EURO) in cash among the 100 participants finalist playing 100 full tickets in which 10 winners were selected.
CONGRATULATIONS!!!
Your fund is now deposited with Wincor Nixdorf Service and Consultancy and insured in your email address , we only have your e-mail address in our custody and also due to mix up of some numbers and e-mail addresses, we ask that you keep this award from public notice until your claims has been processed and claimed by you. We assure you that your full winning prize will be given to you NOTE: no individual or organisation has the legal right to deduct or add to you award otherwise legal actions will be taken .You must receive your full award of five hundred and fifty thousand euros as processed by your security company.
This is part of our security protocol to avoid problems from participants as it has happened in the past.
All participants were selected through a computer ballot system drawn from 25,000 names and screened to 100 e-mails which participated in final lottery from Asia, Australia, New Zealand, Europe, North and South America, Middle East and Africa .
This programme is sponsored by INTERNET EXPLORER / WORLD INTERNATIONAL LOTTERY ORGANISATION TO PROMOTE and ENHANCE the use of SOFT WARE IN THE GOBAL WORLD. We hope your lucky e-mail address will draw a bigger cash prize in the subsequent programs. To begin your lottery claims, please contact your claims agent,
DR Robert Dawin
continent@...
Telephone number: 0034-600-790-196 ,
Contintent Nixdorf Service and Consultancy
You are required to present your information of identity to show you are the user of this email address and whom to claim this award, either your country passport, drivers license or any other valid identity is required please contact your security company in charge for full procedures on how to claim your award
.
Remember, all winnings must be processed not later than two weeks from the day you receive this notification.
Any requirement not met before this date,funds will be returned to the MINISTRY OF FINANCE Also be informed that 10% of your lottery winning belongs to the security company because they are the company assigned by the Continental Email Lottery Board to process your winnings to you.From your winnings, 10% you must remit after you have received your winning prize because the money is insured in your e-mail address and can not be removed.
Remember to quote your reference and batch numbers ( BATCH:EGGS-304-082-444 REFERENCE: 12/13/MGM) in every of your response to your claim agent. Further more, should there be any change of address, inform your claim agent as soon as possible.A copy of your lucky winning ticket and all other informations will be sent to you by your claim agent when your award has been processed and transferred , Your claims agent is DR Robert Dawin.
Once again from all members of our staff CONGRATULATIONS for being a part of our International promotions program.
NOTE:winners below eighteen years ( -18yrs ) are disqualified from this programme.
We wish you good fortunes.
Sincerely,
MRS,JUAN PAOLO,

From forum: MKDoc - Users

Re: Perl 5.8.8 Encode problem, was: Re: FC5 i386 RPMS for MKDoc

2006-06-20T03:54:35Z

Hi

On Mon 19-Jun-2006 at 05:40:47PM +0100, Chris Croome wrote:
>
> On Mon 19-Jun-2006 at 03:12:43PM +0100, Chris Croome wrote:
> >
> > http://www.mkdoc.org/bugs/stable/normal/perl-588/

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

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: Perl 5.8.8 Encode problem, was: Re: FC5 i386 RPMS for MKDoc

2006-06-19T10:40:47Z

Hi

On Mon 19-Jun-2006 at 03:12:43PM +0100, Chris Croome wrote:
>
> 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...

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

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Perl 5.8.8 Encode problem, was: Re: FC5 i386 RPMS for MKDoc

2006-06-19T08:12:43Z

Hi

On Wed 05-Apr-2006 at 12:46:39PM +0100, Chris Croome wrote:
>
> Instructions for installing these RPMS are here:
>
> http://rpms.mkdoc.com/#fc5

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

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: [BUG] CheckUser.pm usage results in MKDoc sites being blackholed

2006-06-13T07:45:40Z

Hi

On Mon 05-Jun-2006 at 02:06:28PM +0100, Chris Croome wrote:

>
> 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
>
> All that is needed now is for Subscribe.pm to be fixed so that it uses
> the MKdoc public domain for the helo and the admin email address for the
> check.

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

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

input

2006-06-06T07:51:45Z

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 within
the meaning of Section 27A of the Securities Act of 1933 and Section 21B
of the SEC Act of 1934. Statements that involve discussions with respect
to projections of future events are not statements of historical fact and
may be forward looking statements. Don't rely on them to make a decision.
Past performance is never indicative of future results. We received four
hundred thousand free trading shares in the past for our services.
All those shares have been sold. We have received an additional one million
free trading shares now. We intend to sell all one million shares now,
which could cause the stock to go down, resulting in losses for you.
The four hundred thousand shares and one million shares were received from
two different third parties, not officers, directors or affiliate
shareholders. This company has: an accumulated deficit, a negative net
worth, a reliance on loans from officers directors and affiliates to pay
expenses, and a nominal cash position. These factors raise substantial
doubt about its ability to continue as a going concern. The company and
its president are a defendant in a lawsuit. The publicly available float
of stock is currently increasing. URGENT: Read the company's SEC filing
before you invest. This report shall not be construed as any kind of
investment advice or solicitation. WARNING: You can lose all your money
by investing in this stock.

_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

[BUG] CheckUser.pm usage results in MKDoc sites being blackholed

2006-06-05T07:06:28Z

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@..." 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@<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@... so I think this solves this mystery...

All that is needed now is for Subscribe.pm to be fixed so that it uses
the MKdoc public domain for the helo and the admin email address for the
check.

Chris

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

[bug] 1.6 linked images

2006-04-18T08:32:03Z

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

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

[SOLVED] MKDoc requires CGI.pm 3.11 or earlier, was: Re: [1.6] Redirect bugs?

2006-04-11T05:47:37Z

Hi

On Thu 06-Apr-2006 at 10:56:23AM +0100, Chris Croome wrote:
>
> What is odd is that I'm only getting this with a brand new install on
> a new FC5 server -- old installs don't seem to have this problem. I
> have looked at the environment settings and there doesn't seem to be
> anything wrong but the env or perhaps one of the perl modules that
> MKDoc depends on might be causing this problem...?

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 case of a ScriptAlias directive
that adds additional path information to the end of the
translated URI.

http://search.cpan.org/src/LDS/CGI.pm-3.17/Changes

And after installing a old version of CGI.pm (3.10) everything starts to
work again :-)

It is also OK with 3.11, with 3.12 it breaks as described earlier in this
thread and the extra "?" is appended to URLs.

It is also broken with all later versions.

So -- MKDoc requires CGI.pm 3.11 or earlier.

Chris

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: [1.6] Redirect bugs?

2006-04-06T03:56:23Z

Hi

On Wed 05-Apr-2006 at 05:52:23PM +0100, Chris Croome wrote:
>
> This could be an issue caused by using Apache 1.3.34

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
-- this is the code that generates the link on the front page of the
site:

<a href="#" title="Photo Title"
petal:attributes="href self/uri_html; title self/title" >

But this is the generated HTML:

<a href="http://www.fc5.webarchitects.co.uk:8080//photo.jpg,html"
title="Photo">

So perhaps the way that self/uri_html is generated has changed?

Another odd thing is the link to the home page on the /photo.jpg,html
page -- this is the generated HTML:

<a hreflang="en" xml:lang="en" dir="ltr"
href="http://www.fc5.webarchitects.co.uk:8080/photo.jpg%2Chtml/"
lang="en">Root document</a>

Which is clearly wrong. This code is generated from the same breadcrumb
trail MKDoc template as is used everwhere... and there is the same
problem on the sitemap page -- this is the breadcrumb trail link to the
front page:

<a hreflang="en" xml:lang="en" dir="ltr"
href="http://www.fc5.webarchitects.co.uk:8080/.sitemap.html/"
lang="en">Root document</a>

What is odd is that I'm only getting this with a brand new install on a
new FC5 server -- old installs don't seem to have this problem. I have
looked at the environment settings and there doesn't seem to be anything
wrong but the env or perhaps one of the perl modules that MKDoc depends
on might be causing this problem...?

Chris

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

[1.6] Redirect bugs?

2006-04-05T10:52:23Z

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 further...

Chris

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

FC5 i386 RPMS for MKDoc

2006-04-05T05:46:39Z

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 mkdoc 86 k
perl-Petal-Mail noarch 0.31-8 mkdoc 14 k
perl-Text-Unidecode noarch 0.04-1.fc5 extras 116 k
perl-Time-modules noarch 2003.1126-3.fc5 extras 35 k
perl-URI-Find noarch 0.16-8 mkdoc 17 k
perl-XML-Parser i386 2.34-6.1.2.2 core 211 k
perl-XML-RSS noarch 1.10-1.fc5.rf dries 29 k
perl-libwww-perl noarch 5.805-1.1 core 379 k

perl-Crypt-PassGen will probably be able to be deleted from the MKDoc
repo if Dries fixes a bug in his RPM.

I did try creating a perl-Bundle-MKDoc rpm but although it seemed to
work it didn't pull in all the other modules so I guess I must be doing
something wrong...

Instructions for installing these RPMS are here:

http://rpms.mkdoc.com/#fc5

Chris

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: Patch to remove lib::sql module from MKDoc-1.6

2006-03-27T03:47:34Z

[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);
---
> my $con = MKDoc::SQL::Condition->new(Editor_ID => $user->id);
249c249
< where => lib::sql::Condition->new(Document_ID => $doc->id)
---
> where => MKDoc::SQL::Condition->new(Document_ID => $doc->id)
411c411
< my $query = new lib::sql::Query
---
> my $query = new MKDoc::SQL::Query

_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Fwd: [berend@xsol.com: [rest-discuss] Cookie-less HTTP authentication how-to available]

2006-03-16T00:14:56Z

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@...> -----

From: "Berend de Boer" <berend@...>
Date: Wed, 15 Mar 2006 21:35:41 -0000
To: rest-discuss@...
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
cookies. Including being able to do the following:

1. Optional authentication or personalisation: provide extra
features for authentication users, but also show the url to
non-authenticated users.

2. Users can log off (that's the hard bit).

3. Customizable login screens.

4. Discussion of a possible implementation of being logged out after
a certain period.

The long discussion starts here:

http://www.pobox.com/~berend/rest/authentication.html

Sample website is here:

http://www.pobox.com/~berend/rest/site/

I really appreciate any comments. It is extra-ordinary easy to make a
mistake here and think something works where it actually doesn't. I
tried to be very lucid and give samples that don't require any perl or
mod_perl skills, so hopefully they are portable to other web servers
than Apache as well.

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/rest-discuss/

<*> To unsubscribe from this group, send an email to:
rest-discuss-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

----- End forwarded message -----

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: [1.6 bug] Using self/parent/parent for detecting where one is in the document hierarchy

2006-02-28T05:36:13Z

Chris Croome wrote:
>
> I know this should work but it doesn't seem to -- for example try this
> code in a document:

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;"
>

--
Bruno
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: [1.6 bug] Using self/parent/parent for detecting where one is in the document hierarchy

2006-02-28T05:03:20Z

Hi

On Fri 24-Feb-2006 at 12:48:23PM +0000, Bruno Postle wrote:

>
> 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>

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:condition="true: self/parent/parent/parent;
false: self/parent/parent/parent/parent;"
>
This document has a parent and a grand parent and a great
grandparent, therefore it must be a great grandchild of
the front page document.
</div>

<div
petal:condition="true: self/parent/parent/parent/parent;
false: self/parent/parent/parent/parent/parent;"
>
This document has a parent and a grand parent and a great
grandparent and a great great grandperent, therefore it must
be a great great grandchild of the front page document.
</div>

I get a internal server error and this error in the logs when this is
added to a template that is a child of the front page:

[PETAL ERROR] Cannot find value for 'parent' at '/self/parent/parent': parent cannot be retrieved

Chris

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Re: [1.6 bug] Using self/parent/parent for detecting where one is in the document hierarchy

2006-02-24T04:48:23Z

> [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

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>

--
Bruno
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

DC Metadata RDF files listing hidden documents

2006-02-23T07:51:15Z

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

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

[1.6 bug] Using self/parent/parent for detecting where one is in the document hierarchy

2006-02-23T06:56:39Z

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

--
Chris Croome <chris@...>
web design http://www.webarchitects.co.uk/
web content management http://mkdoc.com/
_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev

Patch to remove lib::sql module from MKDoc-1.6

2006-02-10T08:38:12Z

For historical reasons there is a generic SQL database abstraction
layer in the MKDoc-1.6 source called lib::sql.

This code was removed from the 1.8 development version and replaced
with the MKDoc::SQL CPAN module. This patch does much the same for
1.6 though internally it still uses the lib::sql naming scheme to be
backwards compatible with existing database configurations.

--
Bruno

Index: MKDoc.pm
===================================================================
RCS file: /var/spool/cvs/mkd/Attic/MKDoc.pm,v
retrieving revision 1.15.2.36
diff -r1.15.2.36 MKDoc.pm
37,38c37
< use lib::sql::DBH;
< use lib::sql::Table;
---
> use MKDoc::SQL;
Index: MKDoc/Handler/GroupAuthz.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Handler/Attic/GroupAuthz.pm,v
retrieving revision 1.1.2.2
diff -r1.1.2.2 GroupAuthz.pm
28a29
> use MKDoc::SQL;
99c100
< my $con = lib::sql::Condition->new(Editor_ID => $user->id);
---
> my $con = MKDoc::SQL::Condition->new(Editor_ID => $user->id);
128c129
< where => lib::sql::Condition->new(Document_ID => $doc->id)
---
> where => MKDoc::SQL::Condition->new(Document_ID => $doc->id)
Index: MKDoc/Handler/Initialize.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Handler/Initialize.pm,v
retrieving revision 1.1.2.20
diff -r1.1.2.20 Initialize.pm
31,32c31
< use lib::sql::DBH;
< use lib::sql::Table;
---
> use MKDoc::SQL;
Index: MKDoc/Site/Deploy/DB/Driver.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Site/Deploy/DB/Driver.pm,v
retrieving revision 1.1.2.6
diff -r1.1.2.6 Driver.pm
197,204c197
< use lib::sql::Category;
< use lib::sql::Table;
< use lib::sql::type::Char;
< use lib::sql::type::DateTime;
< use lib::sql::type::Int;
< use lib::sql::type::Text;
< use lib::sql::type::LongText;
< use lib::sql::DBH;
---
> use MKDoc::SQL;
Index: MKDoc/Site/Deploy/DB/Schema.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Site/Deploy/DB/Schema.pm,v
retrieving revision 1.1.2.7
diff -r1.1.2.7 Schema.pm
37,44c37
< use lib::sql::Table;
< use lib::sql::Category;
<
< use lib::sql::type::Char;
< use lib::sql::type::DateTime;
< use lib::sql::type::Int;
< use lib::sql::type::Text;
< use lib::sql::type::LongText;
---
> use MKDoc::SQL;
Index: MKDoc/Util/LinkParser.pm
===================================================================
RCS file: /var/spool/cvs/mkd/MKDoc/Util/Attic/LinkParser.pm,v
retrieving revision 1.1.2.7
diff -r1.1.2.7 LinkParser.pm
135c135
< use lib::sql::DBH;
---
> use MKDoc::SQL;
Index: flo/Standard.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/Standard.pm,v
retrieving revision 1.12.2.14
diff -r1.12.2.14 Standard.pm
37c37
< use lib::sql::Table;
---
> use MKDoc::SQL;
Index: flo/Record/Ticket.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/Record/Ticket.pm,v
retrieving revision 1.16.2.7
diff -r1.16.2.7 Ticket.pm
75c75,76
< use lib::sql::Condition;
---
> use MKDoc::SQL::Condition;
> use MKDoc::SQL;
330c331
< # note: using NOW() doesn't work (it's quoted by lib::sql::Condition) so
---
> # note: using NOW() doesn't work (it's quoted by MKDoc::SQL::Condition) so
332c333
< my $cond = new lib::sql::Condition;
---
> my $cond = new MKDoc::SQL::Condition;
Index: flo/editor/Headlines.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/editor/Headlines.pm,v
retrieving revision 1.4.2.34
diff -r1.4.2.34 Headlines.pm
485,486c485,486
< use lib::sql::Condition;
< my $cond = new lib::sql::Condition;
---
> use MKDoc::SQL::Condition;
> my $cond = new MKDoc::SQL::Condition;
Index: flo/plugin/Headlines.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Headlines.pm,v
retrieving revision 1.1.2.11
diff -r1.1.2.11 Headlines.pm
97,98c97,98
< use lib::sql::Condition;
< my $cond = new lib::sql::Condition;
---
> use MKDoc::SQL::Condition;
> my $cond = new MKDoc::SQL::Condition;
Index: flo/plugin/Sitemap.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Sitemap.pm,v
retrieving revision 1.7.2.15
diff -r1.7.2.15 Sitemap.pm
50c50
< use lib::sql::Condition;
---
> use MKDoc::SQL;
Index: flo/plugin/Account/Reminder.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Account/Attic/Reminder.pm,v
retrieving revision 1.14.2.9
diff -r1.14.2.9 Reminder.pm
81c81
< my $condition = new lib::sql::Condition();
---
> my $condition = new MKDoc::SQL::Condition();
Index: flo/plugin/Admin/Move.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Admin/Move.pm,v
retrieving revision 1.1.2.8
diff -r1.1.2.8 Move.pm
163c163
< use lib::sql::Condition;
---
> use MKDoc::SQL::Condition;
166c166
< my $condition = new lib::sql::Condition();
---
> my $condition = new MKDoc::SQL::Condition();
Index: flo/plugin/Admin/UserModify.pm
===================================================================
RCS file: /var/spool/cvs/mkd/flo/plugin/Admin/UserModify.pm,v
retrieving revision 1.1.2.6
diff -r1.1.2.6 UserModify.pm
152c152
< where => lib::sql::Condition->new(Grp_ID => $id,
---
> where => MKDoc::SQL::Condition->new(Grp_ID => $id,

_______________________________________________
MKDoc-dev mailing list
MKDoc-dev@...
https://lists.webarch.co.uk/mailman/listinfo/mkdoc-dev

From forum: MKDoc - Dev