Kupu rejects keystrokes - except when portal_js    tool is in debug

Philip Bauer provides the following in plone-users:

kupu stops working in plone 3.1.2 when for some reason you enable "Automatic grouping mode"
in portal_javascripts. It happened to a older site of mine that used this option.

Firebug throws two hints:
    _SARISSA_HAS_DOM_FEATURE is not defined ...
and
    tool.initialize is not a function ...

Fix: disable Automatic grouping mode :-)

Regards,
Philip

Error Value: type object 'IUserAdder' has no attribute '__iro__'

This is caused by Membrane and Remember not loading.

There's a problem with the buildout.

This had to do with the fact that I forrgot  to update the PROPERTIES on the svn dir after changing the EXTERNALS file

sudo svn ps svn:externals -F EXTERNALS.txt .
property 'svn:externals' set on '.'

Also needed to update the CacheSetup section in base.cfg

http://pypi.python.org/pypi/Products.CacheSetup

On server:
svnadmin create /var/www/svn/dev/dezinecafe/trunk

On Local:
svn --message 'initial commit' import {initial_source_tree} svn+ssh://www.eiotx.net/var/www/svn/dev/dezinecafe/trunk

Check Out:
svn co svn+ssh://sb03.eiotx.net/var/www/svn/dev/dezinecafe/trunk dezinecafe

Got this nailed. After rebuilding Zope, Plone, and a fresh clone of the Data.fs, and having no change, it was clear that the cause was deeper in the stack...

We were missing the python-ldap module on the server. Having built that and restarting Zope, all is well.

I'd been told the damn thing was cloned from the running system ;-)

Thanks to all

PF

At 2:03 PM -0600 12 11 06, Peter Fraterdeus wrote: Hi All!

I've got clone of a running plone 2.1.3 site which refuses to allow the skins to authenticate (I assume) giving the following on every object it attempts to access.

2006-11-12 13:43:37 ERROR Zope.SiteErrorLog http://cmstest.farmers.coop/images/gen-o.gif/index_html Traceback (most recent call last): File "/opt/Zope-2.8/lib/python/ZPublisher/Publish.py", line 105, in publish object=request.traverse(path, validated_hook=validated_hook) File "/opt/Zope-2.8/lib/python/ZPublisher/BaseRequest.py", line 445, in traverse else: user=v(request, auth, roles) File "/opt/Zope-2.8/lib/python/AccessControl/User.py", line 641, in validate user = self.authenticate(name, password, request) File "/var/lib/plone2.1/zope/Products/GroupUserFolder/GroupUserFolder.py", line 1025, in authenticate u = src.authenticate(name, password, request) AttributeError: authenticate

Same results whether anon, or I attempt to log-in with my ZMI user/admin , or with an LDAP auth uid....

The site is based on CMFMember with LDAPUserFolder, Zope 2.8.8, Python 2.3.5 See it here: http://cmstest.farmers.coop/ the working one is here: http://www.farmers.coop/

I have recently cloned the Data.fs from the working install, cloned the entire zope Products install from the working install, and upgraded Zope to 2.8.8

Andy McKay suggested replacing the LDAPUF in the plone site, but I can't EVEN get to it in the ZMI. The site throws the same auth error. I'm clearly at the end of my own expertise here.

I don't understand how the same data will produce a completely different result on a cloned machine. LDAP works fine from the command-line, everything, as far as I can see, is the same on the two systems.

Hints, pointers, suggestions??? I'm feeling heat from the client, as this is supposed to be our fail-over system!!

Many thanks!!

Thanks to all who contributed to shifting our reality into the parallel universe where the Democrats actually become capable of winning something.

The Excel file received has extra columns in the wrong order. First order of business is to get them arranged so:

chMemberId Account Firstname Lastname City State Postalcode Email Password Country Beef Dairy Egg Pork Poultry Produce

after further massage, including parsing the pools data into a binary value for whether there's something in the cell for that pool (there are two possible values, but for our purposes, anything is a positive), I can run the adapted "conv_farmersAndPools.pl" like so:

perl conv_farmers.pl ./farmersimport-3-28-06.txt > ./farmers_out.ldif

which produces the farmers_out.ldif file (containing the data in LDAP import format)

This file is then uploaded to the server, where it is imported to the openLDAP db with

ldapadd -v -W -D "cn=Manager,o=People,dc=farmers,dc=coop" -f farmers_out.txt

using the Manager password.

If there's a problem with the update (as there was the first time I ran it), we can remove the new records with ldapdelete, the format is the dn

uid=91063,o=Farmers,dc=farmers,dc=coop

sudo ldapdelete -cxv -D "cn=Manager,o=People,dc=farmers,dc=coop" -W -f farmers_DN.txt

I've found it very useful to keep all the actual product directories in their own category folders, ie:

plonebase - for the current dist or svn bundle
_products_tested
_products_disabled
_products_homegrown
_products_handrolled

and so forth

I use a short sequence of command line scripts like this:

Assuming that the plone Products is in /path/to/Products, the following will make symlinks for all the directories in ./_products_tested/ (for example)

    cd /path/to/_products_tested/

    for i in ./*;do [ -d $i ] && echo ln -s `pwd`/`basename $i` `pwd`/../Products/;done  # test first with echo...

    for i in ./*;do [ -d $i ] &&  ln -s `pwd`/`basename $i` `pwd`/../Products/;done # then roll it

to remove all the symlinks, deinstalling the products listed in a particular category folder, just

    cd /path/to/_products_tested/

    for i in ./*;do [ -d $i ] && echo rm  `pwd`/../Products/`basename $i`;done  # test first with echo...

    for i in ./*;do [ -d $i ] &&  rm  `pwd`/../Products/`basename $i`;done # then roll it

This is very handy for managing upgrades to Plone base etc...


Note that the ` backticks are NOT ' single quotes! under *nix, a command like `pwd` will be replaced with the output of the command. So, `pwd`(print working directory) will give the full path to the current directory.
Note also, that this assumes that the 'category folders' are in the same {Instance Home}directory as ./Products/, so that `pwd`/../Products/ will back-out one level from the current directory to find 'Products'

Geeklibrarian on #plone said:
my notes say:
Then it's very important to install the libraries and the headers (/usr/local by default):
1. make install-lib
2. make install-header
Skipping either of these last two steps means that PIL will fail its self-test for the jpeg decoder.
(that was on redhat linux something-or-other)