Temporary Handler?
Hi All, Is it possible to install a request phase handler (via push_handler() or some other method) during a request that will only execute in that request, and be removed as a handler after the request completes? Many TIA, David
Re: Releasing an independent Apache::SizeLimit to CPAN?
On Jun 20, 2006, at 09:06, Geoffrey Young wrote: o whether Apache::SizeLimit should support both mp1 and mp2 Yes. o whether future releases of mp1 and mp2 will include Apache::SizeLimit Don't care. o whether the mod_perl project should continue to have oversight via svn (for example, make Apache-SizeLimit a separate repository and granting dave karma) or whether we're handing the code off completely (to be hosted going forward in dave's realm) I think keeping it in the mod_perl project svn is a good idea. Just my $0.02 (not worth what it used to be, given the poor value of the dollar). Best, David
SDBM Conflict with mod_ssl
Hi All, I'm running into a conflict between Perl's SDBM_File and mod_ssl's use of sdbm as I try to build Apache + mod_perl + mod_ssl on Red Hat Enterprise Linux ES release 4 (Nahant Update 3) on a 64-bit box: gcc -DLINUX=22 -DHAVE_SET_DUMPABLE -DNO_DBM_REWRITEMAP - DMOD_SSL=208127 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -pipe - Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DEAPI -DEAPI_MM -fPIC `./apaci` -L/usr/local/src/openssl-0.9.8b -L./../../mm-1.4.0/.libs -rdynamic \ -o httpd buildmark.o modules.o modules/standard/libstandard.a modules/ssl/libssl.a modules/perl/libperl.a main/libmain.a ./os/unix/ libos.a ap/libap.a regex/libregex.a -lm -lcrypt -lssl -lcrypto - L/usr/local/lib /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ DynaLoader/DynaLoader.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ B/B.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ByteLoader/ ByteLoader.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Cwd/Cwd.a / usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Data/Dumper/Dumper.a /usr/ local/lib/perl5/5.8.8/x86_64-linux/auto/Devel/DProf/DProf.a /usr/ local/lib/perl5/5.8.8/x86_64-linux/auto/Devel/PPPort/PPPort.a /usr/ local/lib/perl5/5.8.8/x86_64-linux/auto/Devel/Peek/Peek.a /usr/local/ lib/perl5/5.8.8/x86_64-linux/auto/Digest/MD5/MD5.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/Encode.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/Byte/Byte.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/CN/CN.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/EBCDIC/EBCDIC.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/JP/JP.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/KR/KR.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/Symbol/Symbol.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/TW/TW.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Encode/Unicode/Unicode.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Fcntl/Fcntl.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/File/Glob/Glob.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/Filter/Util/Call/Call.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/I18N/Langinfo/Langinfo.a /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/IO/IO.a /usr/local/lib/perl5/5.8.8/ x86_64-linux/auto/IPC/SysV/SysV.a /usr/local/lib/perl5/5.8.8/x86_64- linux/auto/List/Util/Util.a /usr/local/lib/perl5/5.8.8/x86_64-linux/ auto/MIME/Base64/Base64.a /usr/local/lib/perl5/5.8.8/x86_64-linux/ auto/Opcode/Opcode.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ POSIX/POSIX.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/PerlIO/ encoding/encoding.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ PerlIO/scalar/scalar.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ PerlIO/via/via.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ SDBM_File/SDBM_File.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ Socket/Socket.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Storable/ Storable.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Sys/Hostname/ Hostname.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Sys/Syslog/ Syslog.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Time/HiRes/ HiRes.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Unicode/ Normalize/Normalize.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ attrs/attrs.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/re/re.a / usr/local/lib/perl5/5.8.8/x86_64-linux/auto/threads/threads.a /usr/ local/lib/perl5/5.8.8/x86_64-linux/auto/threads/shared/shared.a -L/ usr/local/lib/perl5/5.8.8/x86_64-linux/CORE -lperl -lm -lmm -ldl /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/SDBM_File/SDBM_File.a (sdbm.o)(.rodata+0x0): multiple definition of `nullitem' modules/ssl/libssl.a(ssl_util_sdbm.o)(.bss+0x0): first defined here /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/SDBM_File/SDBM_File.a (sdbm.o)(.text+0x0): In function `sdbm_prep': : multiple definition of `sdbm_prep' modules/ssl/libssl.a(ssl_util_sdbm.o)(.text+0xf3): first defined here /usr/bin/ld: Warning: size of symbol `sdbm_prep' changed from 530 in modules/ssl/libssl.a(ssl_util_sdbm.o) to 370 in /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/SDBM_File/SDBM_File.a(sdbm.o) /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/SDBM_File/SDBM_File.a (sdbm.o)(.text+0x180): In function `sdbm_open': : multiple definition of `sdbm_open' modules/ssl/libssl.a(ssl_util_sdbm.o)(.text+0x0): first defined here /usr/bin/ld: Warning: size of symbol `sdbm_open' changed from 243 in modules/ssl/libssl.a(ssl_util_sdbm.o) to 254 in /usr/local/lib/ perl5/5.8.8/x86_64-linux/auto/SDBM_File/SDBM_File.a(sdbm.o) /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/SDBM_File/SDBM_File.a (sdbm.o)(.text+0x280): In function `sdbm_close': : multiple definition of `sdbm_close' modules/ssl/libssl.a(ssl_util_sdbm.o)(.text+0x305): first defined here /usr/bin/ld: Warning: size of symbol `sdbm_close' changed from 66 in modules/ssl/libssl.a(ssl_util_sdbm.o) to 46 in
Re: Migrating from MySQL to PostGres -- Any mod_perl specific things I should be wary of?
On Mar 10, 2006, at 12:26, Jonathan Vanasco wrote: I'm not referring to SQL traits or DBI differences, but any little tricks or odd things that might happen when using the pg dbi under apache The only one I can think of (and my information might be severely out- of-date) is that you can open a MySQL connection before Apache forks and have it still work in the children, but the same is not true for PostgreSQL (or most other databases, for that matter). If you use Apache::DBI, there should be no problem. Otherwise, just be sure that you have no database connections open when apache forks. Close any that you open on startup, and only open them when you get the first request in each child. This is good practice for MySQL, too, FWIW. Otherwise, everything just works. Best, David
Re: Where is Your Apache2 Installed?
On Feb 7, 2006, at 3:13 AM, Tom Schindl wrote: I always thought that could be retrieved from Apache2::BuildConfig e.g. to get where you apx is located you could use: print Apache2::BuildConfig-new()-MP_APXS . \n; Doesn't seem to work for me: geertz% perl -MApache2::BuildConfig -le 'print Apache2::BuildConfig- new-MP_APXS, $/' geertz% perldoc Apache2::BuildConfig No documentation found for Apache2::BuildConfig. Besides, I need to detect Apache even if mod_perl isn't installed. Best, David
Re: Where is Your Apache2 Installed?
On Feb 7, 2006, at 08:38 , Tom Schindl wrote: Your line works like a charme ;-) -8- [EMAIL PROTECTED] ~]$ /opt/myperl/bin/perl -MApache2::BuildConfig -le 'print Apache2::BuildConfig-new-MP_APXS, $/' /opt/myapache/bin/apxs [EMAIL PROTECTED] ~]$ -8- Odd that it doesn't work for me. But I don't see it listed in the distribution, either: http://search.cpan.org/dist/mod_perl-2.0.2/ In my case the file is located in /opt/myperl/lib/site_perl/5.8.6/i686-linux/ In think that mp2bug is also using this Apache2::BuildConfig or rather ModPerl::Config which it self uses Apache2::BuildConfig. ModPerl::Config I got. The only idea if have is to ask the user for the Apache- Installation if none is found on the system :-) e.g. using a parameter passed to perl Makefile.PL. Yeah, I do that anyway. I just was putting together a list of common directories to search before prompting. Here's what I have (searching for 1.3 or 2.x): /usr/local/apache/bin /usr/local/apache2/bin /opt/apache/bin /opt/apache2/bin /usr/local/bin /usr/local/sbin /usr/bin /usr/sbin /bin /etc/httpd/bin /etc/apache/bin /etc/apache2/bin /home/httpd/bin /home/apache2/bin /home/apache/bin /sw/bin /sw/sbin /web/httpd Best, David
Re: Where is Your Apache2 Installed?
On Feb 7, 2006, at 09:03 , Geoffrey Young wrote: Apache-Test contains some code for digging out httpd when it's not in your path - see TestConfig.pm for some stuff you might be able to steal. Thanks Geoff, I'll do that. Best, David
Re: Where is Your Apache2 Installed?
On Feb 7, 2006, at 09:08 , Tom Schindl wrote:
and is it working and how? The first line reads in my case reads
like this:
-8-
package ModPerl::Config;
use strict;
use Apache2::Build ();
[...]
-8-
But that's not Apache2::BuildConfig, it's Apache2::Build.
It doesn't make sense in the distro because it only holds installation
specific things not known by the distro. That's why it should be
created
dynamically when you're running perl Makefile.PL ;-)
-8-
[EMAIL PROTECTED] mod_perl-2.0.2]$ find . -iname BuildConfig*
[EMAIL PROTECTED] mod_perl-2.0.2]$ /opt/myperl/bin/perl Makefile.PL
MP_APXS=/opt/myapache/bin/apxs
[EMAIL PROTECTED] mod_perl-2.0.2]$ find . -iname BuildConfig*
./lib/Apache2/BuildConfig.pm
-8-
I found it, I have it, it's just that perldoc couldn't find it
because it has no POD in it. But perldoc -m found it. Looking at the
code, I figured out what I needed; this works:
perl -MApache2::BuildConfig -wle 'print Apache2::BuildConfig-new-
{APXS_BINDIR}, $/
Best,
David
Re: Where is Your Apache2 Installed?
On Feb 7, 2006, at 10:14 , David Wheeler wrote:
Apache-Test contains some code for digging out httpd when it's not
in your
path - see TestConfig.pm for some stuff you might be able to steal.
Thanks Geoff, I'll do that.
Taking a quick look, I see this:
my $mp2_build = modperl_build_config();
# if mod_perl 2 was built against the httpd source it
# doesn't know where to find apxs/httpd, so in this case
# fall back to interactive config
unless ($mp2_build-{MP_APXS}) {
die mod_perl 2 was built against Apache sources, we
.
don't know where httpd/apxs executables are,
therefore .
skipping the test suite execution
}
# not sure what else could go wrong but we can't continue
die something is wrong, mod_perl 2.0 build should have .
supplied all the needed information to run the
tests. .
Please post lib/Apache/BuildConfig.pm along with
the .
bug report;
Uh, so, if it doesn't have MP_APXS it dies, and if it has it it dies.
Is that really how it should work?
Best,
David
Re: Where is Your Apache2 Installed?
On Feb 7, 2006, at 10:43 , Geoffrey Young wrote: that is part of the interactive config foo that I don't really understand, particular like, or use. I don't blame you, since it's clearly broken. :-) I guess what I had in mind was the custom which() subroutine and some stuff that looks for it - grep for 'choices' in TestConfig.pm to see what I mean. not that I know it will help you, I just thought it might. Yeah, which() looks very similar to what I have in App::Info. Thanks! David
Re: OT? ModPerl , OSX, XML::Parser
On Feb 7, 2006, at 12:06, Jonathan Vanasco wrote: I'm trying to get XML::Parser installed on my osx dev box. First of all, do you have XCode installed? You won't be able to install any XS modules unless you have a compiler, and gcc comes with XCode. Next, do you have libexpat installed? You can get it from fink, darwin ports, or compile it yourself. This might help: http://www.justatheory.com/computers/os/macosx/my_adventures.html It's a bit dated, but mostly holds true with recent releases of Mac OS X. Things have gotten easier, if anything. HTH, David
Re: Ocassionally POST data is missing
On Feb 6, 2006, at 4:06 PM, Peter Klump wrote: I'm having a problem with my perl scripts after I ported them into a new server environment. My server environment: Apache2 2.0.55 Perl 5.8.3 CGI 3.15 mod_perl 2.0.2 What is happening is that _occasionaly_ (maybe 1 out of 20 times) the POST data users send by their browser to my perl scripts is not arriving. Instead my parameters stay empty. Just out of curiosity, is this server behind a 2.0.55 reverse proxy over https? I found that 2.0.55 had a proxy POST bug that really made things behave very weirdly. The solution was to drop back to 2.0.54 or to apply the patch in this bug report: http://issues.apache.org/bugzilla/show_bug.cgi?id=37145 HTH, David
Where is Your Apache2 Installed?
Hi All, I want to create App::Info::HTTPD::Apache2 to complement App::Info::HTTPD::Apache. http://search.cpan.org/dist/App-Info/ The way it works is that it looks for an httpd executable. But I need to know where Apache2 is typically installed. So, please reply to me off list, if you have Apache 2 and you can, with the path to your Apache 2 installations. Specifically, I need to know the location of your httpd binary, and if it has a different name (like some installs of Apache 1 use names like apache and apache-perl). Thanks! David
ANN: Bricolage 1.10
It is with great pleasure that the Bricolage development team announces the release of Bricolage 1.10. The culmination of over 19 months of development, version 1.10 represents a significant advance for the celebrated open-source content management and publishing system. Here are some of the highlights: PHP Templating Bricolage is the first content management system to support three different Perl-based templating architectures (Mason, Template Toolkit, and HTML::Template) as well as one in a completely different programming language: PHP 5. Bricolage 1.10 adds PHP templating support, allowing template developers to use the popular Web programming language to formatting their documents for output. This functionality is thanks to a killer new technology, known as PHP::Interpreter, that loads the PHP 5 interpreter into a Perl 5 interpreter, and affords transparent access between PHP and Perl code. The upshot is that PHP templaters get full access to the entire Bricolage API, as well as the ability to use whatever other PHP or Perl libraries they wish. Our expect is that this development will push Bricolage into new environments where PHP developers can make use of the powerful content management and publishing system without having to learn a new programming language. Furthermore, we hope that PHP::Interpreter will act as a bridge between the Perl and PHP communities, such that there is a greater exchange of ideas and a greater ability to use each other's libraries. PHP::Interpreter was developed by OmniTI. PHP::Interpreter and the PHP templating support in Bricolage were sponsored by SAPO--Portugal Online. LDAP Authentication Bricolage 1.10 includes support for a pluggable authentication architecture, and in addition to its built-in authentication has added a module for authentication against an LDAP directory server. This new feature is sure to be welcome in busy enterprises that rely on a directory server, such as Windows Active Directory http://www.microsoft.com/windowsserver2003/technologies/ directory/activ edirectory/default.mspx, Novel eDirectory http://www.novell.com/products/edirectory/, or OpenLDAP http://www.openldap.org/. Authentication can be limited to members of a directory group, and supports LDAP v.3 and TLS connectivity. Contributed by Kineticode. Revamped Interface Bricolage 1.10 sports a completely revamped browser interface that is XHTML compliant and handles all styling via CSS. Yes, our 1999-era table-driven interface is officially a thing of the past. The upshot is that the interface is much more elegant, easier to skin with your own look (by overriding its CSS files), allows search results and editing fields to expand and contract with the browser window size, and delivers pages as much as 70% smaller than they were before. The new interface was Contributed by Marshall Roch. A second major new UI feature is the revamped Bulk Edit interface. Gone is the old Super Bulk Edit interface, with the Bulk Edit revisions overtaking its functionality. Now you can edit the entire contents of a story document, from the top-most element to the bottom-most field, in a single textarea field with no reloads. The secret to allowing the full-text editing of Bricolage's unique hierarchical element structures is Plain Old Documentation, or POD. Subelements are denoted by a new =begin POD tag, and end with a matching =end tag. The result is a much more natural editing interface. Even related stories and media are supported by new POD tags. We believe that this improvement will greatly facilitate the editing process, making Bricolage a much more enjoyable product for content editors to work with. The Bulk Edit revision is complemented by two new additions: diff support and a JavaScript-powered Find and Replace dialog box. Users can now see at a glance the changes between one version of a document and another. The changes are shown on a word-by-word basis, with additions in green with an underline and deletions in red with a strikeout. A similar interface is used to show the differences between versions of templates using the traditional unified diff format rather than word-by word. The JavaScript-powered Find and Replace dialog box can be used to search by strings or regular expressions in a Bulk Edit or Template editing environment. Found bits of text can also be replaced or even globally replaced. We believe that this powerful new feature, combined with the new Bulk Edit interface, makes Bricolage a compelling content editing environment. The Bulk Edit, diff, and Find and Replace features were contributed by Kineticode.
Re: Found it !!! Why is my apache parent process growing...
On Jan 3, 2006, at 10:29 AM, Philip M. Gollucci wrote: -Dusemymalloc=y is the default for lang/perl5.8 Also, the previous example had this same setting. I'll try a manual compile with it off at some point. FWIW, I found that turning off Perl's malloc() prevented segfaults in mod_perl 1 on Solaris. This was about 5 years ago. I guess I shouldn't be surprised that this is still an issue. I personally never use mymalloc for this reason. I thought that this was supposed to have been fixed by better-tuned makefiles in 5.8.x., though. Best, David
Re: Adding customs httpd.conf data in mod_perl 2.0
Hi all, However, what I need to be able to do is let someone have a running mod_perl 2 setup and dynamically pull in the above information from an external file or add that information via Perl (in other words, I don't want to touch the default httpd.conf file). How the heck do I do that? Since I'm the one who's asked Curtis to look into this, let me see if I can elaborate a little. What we have is a complex application that needs to do quite a bit of configuration (set up an access handler, a cleanup handler, a response handler, allow the default handler for images, etc., etc., ad nauseum). When users install it, we don't want them to have to add a tone of stuff to their httpd.conf just to get all of it going. What we'd rather have is something like this: Location /myapp SetHandler perl-script PerlPostConfigHandler MyApp::Apache2::config /Location The idea is that MyApp::Apache2::config() would figure out that it was in a Location context with a value of /myapp, and then configure its handlers relative to that location. The result would be the equivalent of: Location /myapp SetHandler perl-script PerlResponseHandler MyApp::Apache2 PerlAuthenHandler MyApp::Apache2::authen PerlCleanupHandler MyApp::Apache2::cleanup /Location # REST Location /myapp/rest SetHandler perl-script PerlResponseHandler MyApp::Apache2::rest /Location # Static files: Location /myapp/ui SetHandler default-handler /Location Only dynamically configured. The context could be either a Location directive for an existing host name, or a virtual host directive, so that the application would then run in that entire domain. Now, I've done something similar to this for mod_perl1 in Bricolage. There, the entirety of the httpd.conf configuration that the user has to do is this: PerlPassEnv BRICOLAGE_ROOT PerlModule Bric::App::ApacheConfig Yes, that's it. Bric::App::ApacheConfig pulls in virtual host information from its own configuration file, and then builds up all of the configuration it needs for that host by adding literal httpd.conf directives to $Apache::ReadConfig::PerlConfig. That works, but I'd like to do away with the requirement of a dedicated host, and I'd like to do it all in mod_perl2 at server startup time. Does that make things clearer? Is there an equivalent to $Apache::ReadConfig::PerlConfig in mod_perl2, perhaps? Or better yet, is there now an API for dynamically configuring Apache from mod_perl2? Thanks, David
ANN: Bricolage 1.8.5 Released
The Bricolage development team is pleased to announce the release of Bricolage 1.8.5. This maintenance release addresses a number of issues in Bricolage 1.8.3 and adds a number of improvements (there was no announcement for the short-lived 1.8.4 release). The SOAP server in particular sees improvements in this release, with improved character set support; better support for related stories and media using URIs in addition to IDs; and as support for top-level element relations. Issues with the ordering of story elements have also been corrected, as well as errors when attempting to revert a story or media document or template. Here are the other highlights of this release: Improvements * Added Linux startup script contrib/start_scripts/linux. [David] * Related story and media elements managed through the SOAP server can now use a combination of URI and site ID to identify related assets in addition to the existing approach of using story and media IDs. [David] * A list of subelements is now less likely to mysteriously become out of order and thus lead to strange action-at-a-distance errors. And even if they do become out of order, the error message will be more appropriate (Warning! State inconsistent instead of Can't call method 'get_name' on an undefined value). Reported by Curtis Poe. [David] * The SOAP media interface now supports creating relationships between the media documents elements and other story and media documents, just like the SOAP story interface does. [David] * The SOAP interface now supports Related stories and media on story type and media type elements just as in the UI. This involved the somewhat hackish necessity for including the related_story_id and related_media_id (or related_story_uri and related_media_uri) attributes in the elements XML element, but it does the trick. [David] Bug Fixes * Calls to publish documents via SOAP will no longer fail if the published_version attribute is not specified and the document to be published has never been published before. [David] * The Bricolage virtual FTP server will no longer fail to start if Template Toolkit is installed but its version number is less than 2.14. Reported by Adam Rinehart. [David] * Stories and Media created or updated via the SOAP interface will now associate contributors of the appropriate type, instead of All Contributors. [Scott David] * Deleting an element that has a template no longer causes an error. Thanks to Susan for the spot! [David] * Eliminated encoding errors when using the SOAP interface to output stories, media, or templates with wide characters. Reported by Scott Lanning. [David] * Reverting (stories, media, templates) no longer gives an error. Reported by Simon Wilcox, Rachel Murray, and others. [David] * Publishing a published version of a document that has a later version in workflow will no longer cause that later version to be mysteriously removed from workflow. This could be caused by passing a document looked up using the published_version to list() to $burner-publish_another in a template. [David] * The SOAP server story and media interfaces now support elements that contain both related stories and media, rather than one or the other. [David] * Attempting to preview a story or media document currently checked out to another user no longer causes an error. Reported by Paul Orrock. [David] * Custom fields with default values now have their values included when they are added to stories and media. Thanks to Clare Parkinson for the spot! [David] * The bric_queued script now requires a username and password and will authenticate the user. This user will then be used for logging events. All events logged when a job is run via the UI are now also logged by bric_queued. [Mark and David] * Preview redirections now use the protocol setting of the preview output channel if it's available, and falls back on using http://; when it's not, instead of using the hard-coded http://;. Thanks to Martin Bacovsky for the spot! [David] * The has_keyword() method in the Business class (from which the story and media classes inherit) now works. Thanks to Clare Parkinson for the spot! [David] * Clicking a link in the left-side navigation after the session has expired now causes the whole window to show the login form, rather than it showing inside the nav frame, which was useless. [Marshall] * The JavaScript that validates form contents once again works with htmlArea, provided htmlArea itself is patched. See
Re: ModPerl::MM
On Dec 28, 2004, at 2:36 PM, Stas Bekman wrote: Probably vice versa. It looks that Apache::TestMM does more than it should be doing. It should be handling only test/clean parts. Ah, and I just copied what was there to create Apache::TestMB. so you will be asking, right? Oh, okay, but not today. Tomorrow. I'm leaving for the rest of the day now. Bye! David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Slashdot | Help Test mod_perl 2 Release Candidates
On Dec 27, 2004, at 9:58 PM, Stas Bekman wrote: I think all you need to do is to write an equivalent of WriteMakefile (and some other bits). The rest of the stuff in it, is a painful exercise of overriding ExtUtils::MakeMaker MY:: methods. You make it sound so appealing. I can't wait! But seriously, if this is used only for installing mod_perl and not for anything else, does it need to be done before you're ready to convert to Module::Build for mod_perl's installer? Cheers, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::MM
On Dec 28, 2004, at 12:58 PM, Stas Bekman wrote: And if we do it the other way around, so you could take Apache-Filter-HTTPHeadersFixup (the latest is on cpan) add a plain Build.PL (as if there was no mp2) and then we can add the needed strings and design ModPerl::MB on the way? Yes, that should be pretty straight-forward, provided you're not practicing any voodoo in the Makefile.PL script that needs replicating. ;-) I've long ago planned to make my modules available under public svn, let me ping Robert if I we can setup an svn rep on svn.perl.org. Coo. Regards, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::MM
On Dec 28, 2004, at 1:26 PM, Stas Bekman wrote:
it can't be any simpler:
That wasn't the whole script, but I found it on search.cpan.org. Here's
how to get it working with Module::Build right now:
use strict;
use warnings FATAL = 'all';
use Apache2;
use Apache::TestMB;
# prerequisites
my %require = (
# the keepalive constants and the keepalives() method added in
1.9913
mod_perl = 1.9915,
Apache::Test = 1.10, # ipv6 fixes
'perl' = 6.006,
);
my $build_pkg = eval { require Apache::TestMB }
? 'Apache::TestMB'
: 'Module::Build';
my $build = $build_pkg-new(
module_name= 'Apache::Filter::HTTPHeadersFixup',
license= 'perl',
requires = \%require,
build_requires = { Apache::TestMB = 0 },
create_makefile_pl = 'passthrough',
craete_readme = 1,
);
$build-create_build_script;
After the release of Module::Build 0.27, you can just do this (no more
need to eval TestMB):
use strict;
use warnings FATAL = 'all';
use Apache2;
use Apache::TestMB;
# prerequisites
my %require = (
# the keepalive constants and the keepalives() method added in
1.9913
mod_perl = 1.9915,
Apache::Test = 1.10, # ipv6 fixes
'perl' = 6.006,
);
my $build = Module::Build-new(
module_name= 'Apache::Filter::HTTPHeadersFixup',
license= 'perl',
requires = \%require,
build_requires = { Apache::TestMB = 0 },
create_makefile_pl = 'passthrough',
craete_readme = 1,
build_class= 'Apache::TestMB',
);
$build-create_build_script;
Regards,
David
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::MM
On Dec 28, 2004, at 1:53 PM, Stas Bekman wrote: 'perl' = 6.006, perl 6? :) Oops. :-) why Apache::TestMB? It should be ModPerl::MB when it'll appear, right? Up to you. I used it as an example because I don't really understand how Apache::TestMM and ModPerl::MM interact. why the fallback for Module::Build? Shouldn't it just die then? No, because if you're installing from CPAN.pm, it should install Apache::Test. I think. The build_class parameter is actually a much better choice, since you won't have to worry about that at all. Again, that should be in 0.27 of M::B (not sure of a due date). what if none exists, should Module::Install be used to require Module::Build? No idea. I've never used Module::Install. You'll have to ask autrijus. when will that be released? I guess I need to require that version then. Ask Ken. So the only remaining part is to override Module::Build to place modules under Apache2/ if mp2 was built this way. Could you post an override that unconditionally overrides that and I'll adjust it to figure it out dynamically? Uhmight be tricky. There's been a lot of debate about install paths on the Module-Build list lately. I'd ask there. The install paths are set up by the _set_install_paths() method in Module::Build::Base. http://search.cpan.org/src/KWILLIAMS/Module-Build-0.2607/lib/Module/ Build/Base.pm On Dec 28, 2004, at 1:56 PM, Stas Bekman wrote: what if none exists, should Module::Install be used to require Module::Build? that's a tricky one. If ModPerl::MB is added, I suppose a Build.PL writer should still manually require Module::Build (version) and probably ensure that it's installed via Module::Install, correct? Then ModPerl::MB could check for a specific version of it. Again, I know nothing about Module::Install. Regards, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::MM
On Dec 28, 2004, at 2:17 PM, Stas Bekman wrote: David Wheeler wrote: why Apache::TestMB? It should be ModPerl::MB when it'll appear, right? Up to you. I used it as an example because I don't really understand how Apache::TestMM and ModPerl::MM interact. Apache::TestMM is only needed only to add 'make test' and adjust 'make clean' targets. Hrm. We'd have to take that into consideration when developing ModPerl::MB. I wonder if ModPerl::MM could simply inherit from Apache::TestMM (or vice versa)? Well, we talk about ModPerl::MB, which will already be there if the modperl2 (version, let's say it's added in 1.99_20) is satisfied. no problem then. Just do my $build = ModPerl::MB-new(...); So, are you sure we should even start on that effort then? If things are not stable, I'd rather wait till they are stabilized. They're stable; the debate was over another feature from EU::MM that wasn't ported (and won't be). But it's fresh in their minds, so it's a good time to ask. Regards, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Slashdot | Help Test mod_perl 2 Release Candidates
On Dec 27, 2004, at 7:36 AM, Geoffrey Young wrote: the only kink here would be third-party CPAN modules for only mp2 - those are _required_ to use ModPerl::MM::WriteMakefile (which knows to install into Apache2/ if that's where mp2 was installed) instead of ExtUtils::MakeMaker::WriteMakefile. while I've tried to do my best here with a bunch of modules and perl.com articles, perhaps this point hasn't been clear enough to the masses and that should be addressed. Crap, I don't think that Apache::TestMM knows about this. How do we make sure that those of us who use Module::Build can get our modules installed in the right place? well, perhaps. I can see how it would really affect users who rely heavily on the CPAN shell and perldoc, but I don't think it's as much of an issue for people used to using wget and the online docs. so, in other words, it probably affects the casual user more than the dedicated mod_perl application developer. but that's just my suspicion. in either case, something should be done to make things right. Will it not also affect us who build mod_perl applications and want an easy-to-use installer to just work for people who download our software? Frankly, I don't think that it should be fine for just the dedicated mod_perl developer. This is one place where PHP is kicking the crap out of us. Regards, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Slashdot | Help Test mod_perl 2 Release Candidates
On Dec 27, 2004, at 9:09 PM, Stas Bekman wrote: You mean Apache::TestMB. Yeah, that ole thing. :-) I know someone who's name is David who can easily write a patch for this. David, it should really be: ModPerl::MB and Apache::TestMB should use it. Of course ModPerl::MB doesn't exist yet. That bastard is too lazy to work on it. ;-) us == perl, once PAUSE is fixed, and CPAN clients are adjusted, it will just work. Okay then. On Dec 27, 2004, at 9:19 PM, Stas Bekman wrote: Wait, what this has to do with Apache-Test at all? It should be ModPerl::MB (like ModPerl::MM). Or did you mean that Apache::TestMB doesn't try to load Apache2.pm? I haven't even noticed ModPerl::MM. I guess that would be because I haven't played with mod_perl2 yet. Hrm...can you tell me what, exactly, it does? It doesn't seem to have any documentation. Thanks, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
ANNOUNCE: Bricolage 1.8.3
The Bricolage development team is pleased to announce the release of Bricolage 1.8.3. This maintenance release addresses quite a large number of issues in Bricolage 1.8.2. The most important changes were to enhance Unicode support in Bricolage. Bricolage now internally handles all text content as UTF-8 strings, thus enabling templates to better control the manipulation of multibyte characters. Other changes include better performance for searches using the ANY() operators and more intelligent transaction handling for distribution jobs. Here are the other highlights of this release: Improvements * Added contrib/thumbnails/precreate-thumbs.pl script to pre-create thumbnails from images. Useful for upgraders. [Scott] * Added contrib/bric_import_contribs to import contributors from a tab-delimited file. Development by Kineticode, sponsored by the RAND Corporation. [David] * Added the published_version parameter to the list() methods of the story, media, and template classes. This parameter forces the search to return the versions of the assets as they were last published, rather than the most recent version. This will be most useful to those looking up other documents in templates and publishing them, as a way of avoiding pulling documents out from other anyone who might have them checked out! [David] * All publishing and distribution jobs are now executed in their own transactions when they are triggered by the user interface. This is to reduce the chances of a deadlock between long-running publishing transactions. [David] * Optimized SQL queries for key names or that order by string values to use indexes in the list() and list_ids() methods of the story, media, and template classes. [David] * Added Russian localization. [Sergey Samoilenko]. * Changed the foreign keys in the story, media, and formatting (template) tables so that DELETEs do not cascade, but are restricted. This means that before deleting any source, element, site, workflow, or other related object that has a foreign key reference in an asset table, those rows must be deleted. Otherwise, PostgreSQL will throw an exception. Hopefully, this will put a stop to the mysterious but very rare disappearance of stories from Bricolage. [David] * A call to $burner-burn_another in a template that passes in a date/time string in the future now causes a publish job to be scheduled for that time, rather than immediate burning the document and then scheduling the distribution to take place in the future. Reported by Ashlee Caul. [David] * Changing the sort order of a list of items in a search interface now properly reverses the entire collection of object over the pages, rather than just the objects for the current page. Thanks to Marshall for the spot! [David] Bug Fixes * Publishing stories not in workflow via the SOAP server works again. [David] * * The Burner object's encoding attribute is now setable as well as readable. [David] * The category browser works again. [David] * Fixed Media Upload bug where the full local path was being used, by adding a 'winxp' key to Bric::Util::Trans::FS to account for an update to HTTP::BrowserDetect. [Mark Kennedy] * Instances of a required custom field in story elements is no longer required once it has been deleted from the element definition in the element manager. Reported by Rod Taylor. [David] * A false value passed to the checked_out parameter of the list() and list_ids() methods of the story, media, and template (formatting) classes now properly returns only objects or IDs for assets that are not checked out. [David] * The cover date select widget now works properly in the clone interface when a non-ISO style date preference is selected. Thanks to Susan G. for the spot! [David] * Sorting templates based on Asset Type (Element) no longer causes an error. [David] * Fixed a number of the callbacks in the story, media, and template profiles so that they didn't clear out the session before other callbacks were done with it. Most often seen as the error 'Can't call method get_tiles on an undefined value' in the media profile, especially with IE/Windows (for some unknown reason). Reported by Ed Stevenson. [David] * Fixed typo in clone page that caused all output channels to be listed rather than only those associated with the element itself. [Scott] * Fixed double listing of the All group in the group membership double list manager. [Christian Hauser] * Image buttons now correctly execute the onsubmit() method for forms
ANNOUNCE: Bricolage 1.8.2 Released
The Bricolage development team is pleased to announce the release of Bricolage 1.8.2. This maintenance release addresses quite a large number of issues in Bricolage 1.8.1. The most important changes were to enhance Unicode support in Bricolage. Bricolage now internally handles all text content as UTF-8 strings, thus enabling templates to better control the manipulation of multibyte characters. Other changes include better performance for searches using the ANY() operators and more intelligent transaction handling for distribution jobs. Here are the other highlights of this release: Improvements * Bricolage now runs under a DSO mod_perl as long as it uses a Perl compiled with -Uusemymalloc or -Ubincompat5005. See http://perl.apache.org/docs/1.0/guide/install.html#When_DSO_can_be_Us ed for details. * Alerts triggered to be sent to users who don't have the appropriate contact information will now be logged for those users so that they can see them and acknowledge them under My Alerts. * Added bric_media_dump script to contrib/. * The category association interface used in the story profile when the ENABLE_CATEGORY_BROWSER bricolage.conf directive is enabled now uses radio buttons instead of a link to select the primary category. * Existing jobs are now executed within their own transactions, as opposed to no transaction specification. This means that each job must succeed or fail independent of any other jobs. New jobs are executed before being inserted into the database so as to keep them atomic within their surrounding transaction (generally a UI request). All this means that transactionality is much more intelligent for jobs and will hopefully eliminate job table deadlocks. * All templates now execute with UTF-8 character strings enabled. This means that any templates that convert content to other character sets might need to change the way they do so. For example, templates that had used %filter blocks to convert content to another encoding using something like Encode::from_to($_, 'utf-8', $encoding) must now use something like $_ = Encode::encode($encoding, $_), instead. Bric::Util::CharTrans should continue to do the right thing. * Added encoding attribute to Bric::Util::Burner so that, if templates are outputting something other than Perl utf8 decoded data, they can specify what they're outputting, and the file opened for output from the templates will be set to the proper mode. Applies to Perl 5.8.0 and later only. * Added SFTP_HOME bricolage.conf directive to specify the home directory and location of SSH keys when SSH is enabled. Bug Fixes * make clone once again properly copies the lib/Makefile.PL and bin/Makefile.PL files from the source directory. * Added missing language-specifying HTML attributes so as to properly localize story titles and the like. * The list of output channels to add to an element in the element profile now contains the name of the site that each is associated with, since different sites can have output channels with the same names. * The Advanced Search interface once again works for searching for related story and media documents. * Bricolage no longer attempts to email alerts to an empty list of recipients. This will make your SMTP server happier. * The version numbering issues of Bricolage modules have all been worked out after the confusion in 1.8.1. This incidentally allows the HTML::Template and Template Toolkit burners to be available again. * Misspelling the name of a key name tag or including a non-repeatable field more than once in Super Bulk Edit no longer causes all of the changes in that screen to be lost. * When a user overrides the global Date/Time Format and Time Zone preferences, the affects of the overrides are now properly reflected in the UI. * Publishing a story or media document along with its related story or media documents from a publish desk again correctly publishes the original asset as well as the relateds. * Deleted output channels no longer show up in the select list for story type and media type elements. * Deleting a workflow from the workflow manager now properly updates the workflow cache so that the deleted workflow is removed from the left navigation without a restart. * When Bricolage notices that a document or template is not in workflow or on a desk when it should be, it is now more intelligent in trying to select the correct workflow and/or desk to put it on, based on current workflow context and user permissions. * Content submitted to Bricolage in the UTF-8
Re: [RELEASE CANDIDATE] Apache-Test 1.13
On Aug 19, 2004, at 12:17 PM, Stas Bekman wrote: You can download the release candidate from here: http://www.apache.org/~stas/Apache-Test-1.13-dev.tar.gz All tests pass for me, and it appears to work nicely with my module that uses Apache::TestMB. Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: Apache-Test module skeletons
On Jul 7, 2004, at 7:01 AM, Geoffrey Young wrote: the bug reporting skeleton has become so useful for me (and others) that I have created two new skeletons: I would add a Build.PL with these contents: use 5.00503; use Apache::Test::MB; Apache::Test::MB-new( module_name = 'Apache::Test::Skeleton', )-create_build_script; Regards, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-Test module skeletons
On Jul 9, 2004, at 11:41 AM, Stas Bekman wrote:
Isn't that Apache::TestMB?
D'oh! Yes! Sorry!
use 5.00503;
use Apache::TestMB;
Apache::TestMB-new(
module_name = 'Apache::Test::Skeleton',
)-create_build_script;
And in fact, to make it more generally useful, I think I'd actually
make it:
use 5.00503;
use Apache::TestMB;
Apache::TestMB-new(
module_name= 'Apache::Test::Skeleton',
license= 'perl',
requires = { 'Apache' = 0,
},
build_requires = { Test::More = 0,
},
)-create_build_script;
Regards,
David
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-Test module skeletons
On Jul 9, 2004, at 1:09 PM, Stas Bekman wrote:
There is no Apache.pm in mp2. You probably wanted to say:
requires = { 'mod_perl' = 0,
Right. In fact, it should probably be
requires = { 'mod_perl' = '1.0',
in the MP1 example, and
requires = { 'mod_perl' = '1.99',
in the MP2 example, yes?
Geoff, did you get all that? ;-)
Regards,
David
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-Test module skeletons
On Jul 9, 2004, at 1:38 PM, Stas Bekman wrote:
It won't work since the version number lives in the package mod_perl.
and most likely you'd want to require a minimal version at some point.
Ah, but this is one of the beauties of Module::Build, my friends.
Behold!
use 5.00503;
use Apache::TestMB;
Apache::TestMB-new(
module_name= 'Apache::Test::Skeleton',
license= 'perl',
requires = { 'mod_perl' = = 1.0, 1.99,
},
build_requires = { Test::More = 0,
},
)-create_build_script;
:-)
David
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-Test module skeletons
On Jul 9, 2004, at 1:45 PM, David Wheeler wrote:
use 5.00503;
use Apache::TestMB;
Apache::TestMB-new(
module_name= 'Apache::Test::Skeleton',
license= 'perl',
requires = { 'mod_perl' = = 1.0, 1.99,
},
build_requires = { Test::More = 0,
},
)-create_build_script;
Oh, and FWIW, CPANPLUS should soon have the ability to check such a
spec. Not sure that CPAN.pm ever will, though.
Regards,
David
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-Test module skeletons
On Jul 9, 2004, at 2:03 PM, Randy Kobes wrote: But won't the CPAN indices (which are used by both CPAN.pm and CPANPLUS.pm) still just recognize one version of mod_perl.pm? Either the current one associated with mp1, or, when mp2 is out of development, that associated with mp2 (assuming mod_perl.pm of mp2 has a higher version compared to that of mp1). Or will CPANPLUS go beyond the CPAN indices? That I don't know. I would ask the CPANPLUS developers. http://cpanplus.sourceforge.net/ One (qualitatively similar) example is the GD module, for which there's two major (incompatible) versions, 1 and 2. Currently CPAN.pm reports GD as being version 2.12, and so to install an earlier version 1.x, you have to tell CPAN.pm explicitly which distribution you want to install. Right, the indexing is still a problem. However, for those who have the proper mp installed already, it should just work. And for those who don't, installation should fail, but they'll be told why. But I agree that the indexing issue is important. Perhaps there should be a META.yml rule to tell CPAN what to index, so as to keep track of older versions of modules for those that really need to? I dunno. Something to ask Jarkko about. Regards, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache-Test module skeletons
On Jul 9, 2004, at 2:23 PM, Stas Bekman wrote:
I don't know how M::B does the version checking, but EU::MM does file
parsing, searching for the $VERSION line, so the version number must
be hardcoded there, unless you do something like:
$VERSION = do { require Apache2; require mod_perl.pm;
$mod_perl::VERSION }
Module::Build uses the same approach. I think that the efforts were
synchronized here.
David
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [RELEASE CANDIDATE] Apache-Test-1.06
On May 19, 2004, at 9:02 PM, Geoffrey Young wrote: a release candidate for Apache-Test 1.11 is now available. http://perl.apache.org/~geoff/Apache-Test-1.11-dev.tar.gz please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. All tests pass for me, both in Apache::Test and in my module that uses it. Regards, David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
ANNOUNCE: Bricolage 1.8.0 Arrives!
It is with great pleasure that the Bricolage development team announces the release of Bricolage 1.8.0. The culmination of over 15 months in development, with contributions from over 20 independent developers, and new features sponsored by numerous organizations world-wide, version 1.8.0 represents a significant new pinnacle for the much-lauded open-source content management and publishing system. This release offers more new features, improvements, and performance gains than any previous release. There are so many, in fact (over 120), that they can't effectively be included in this email. Here are some of the highlights: * Support for managing multiple sites from a single Bricolage installation. Each site has its own categories, templates, document types, and workflows, and collaboration across sites is supported by document aliasing and shared workflow desks. * Significant performance boosts to search queries and URI uniqueness validation. * Email document distribution, which can be used to email the files generated by an output channel to one or more email addresses. * A greatly simplified and flexible templating and element API. * Template sandboxes to enable template development without interfering with production templates. * Support for Template Toolkit templates (http://www.template-toolkit.org). * New Publish and Recall permissions, for improved workflow management. * Per-user preferences. * Document formatting at publish time, rather than publish scheduling time. * New German and Mandarin localizations. * Image thumbnails and icons for all media documents. * Support for HTMLArea WYSIWYG editing with HTMLArea. See http://www.interactivetools.com/products/htmlarea/. For a complete list of the changes, see the release notes and changes list at http://sourceforge.net/project/shownotes.php?release_id=235793. For the complete history of ongoing changes in Bricolage, see Bric::Changes at http://www.bricolage.cc/docs/Bric/Changes.html. Download Bricolage 1.8.0 now from the SourceForge download page at http://sourceforge.net/project/showfiles.php?group_id=34789, and from the Kineticode download page at http://www.kineticode.com/bricolage/index2.html. ABOUT BRICOLAGE Bricolage is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete HTML::Mason, HTML::Template, and Template Toolkit support for flexibility, and many other features. It operates in an Apache/mod_perl environment and uses the PostgreSQL RDBMS for its repository. A comprehensive, actively-developed open source CMS, Bricolage was hailed as Most Impressive in 2002 by eWeek. Enjoy! --The Bricolage Team -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [RELEASE CANDIDATE] Apache-Test-1.10
On Apr 15, 2004, at 12:26 PM, Stas Bekman wrote: Unless someone reports problems, I'm going to release a new version of Apache-Test tomorrow. Please test this release candidate: http://perl.apache.org/~stas/Apache-Test-1.10-dev.tar.gz All tests pass for me, and my module that uses it still passes all of its tests. Works for me! David -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
ANNOUNCE: Bricolage 1.6.8
I'm pleased to announce the release of Bricolage 1.6.8. This maintenance release addresses a few issues discovered since the release of version 1.6.7. Here is the complate list of chnages for this release: * Custom select fields now correctly pay attention to the size attribute. Reported by Dave Rolsky. [David] * The element type manager now displays Subelement instead of Story for subelement element types. Suggested by Dave Rolsky. [David] * Updated to work with PostgreSQL 7.4. [David] * Improved error message in Bric::Util::Trans::SFTP. [David] * It's possible to create new stories again without running into errors saying that a URI is not unique because the cover date and slug were accidentally excluded from the URI. [David] * Mason story templates now inherit from all category templates, thus enabling the access of %attrs and calling of %methods in category templates from story templates. [David] * Permission to edit element fields is now based on the permissions granted to edit the elements they belong to. This means that users other Global Admin group members can now edit fields. [David] * Dates are no longer editable if a user doesn't have permission to edit them. [David] * Users without EDIT access to an element no longer see a link to Edit fields of that element, but a link to View them, instead. They will also no longer see an Add Subelements button. [David] * Fixed bug that triggered an invalid error message when a story URI is non-unique. Reported by Kevin Elliott. [David] * Assets with the same IDs but in different classes (media vs. stories vs. templates) no longer prevent each other from being added to a desk that can contain different classes of assets. Thanks to Scott for the spot and doing the research that lead to the replication of the problem. [David] See the changes page for a complete history of Bricolage changes. http://sourceforge.net/project/shownotes.php?release_id=200747 ABOUT BRICOLAGE Bricolage is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete HTML::Mason and HTML::Template support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. A comprehensive, actively-developed open source CMS, Bricolage has been hailed as Most Impressive in 2002 by eWeek. Learn more about Bricolage and download it from the Bricolage home page, http://www.bricolage.cc/. Enjoy! David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
