Blog

Ever since Ross Patterson wrote collective.formcriteria all will be well.

Stop writing search forms for each and every special case by hand and start thinking of search-forms as content just like collections are custom search-results as content. Ross saved us a lot of hassle by extending these almost all-powerfull collections to create custom forms searching through the collections content. And as added value displaying the results in a much nicer and more useful way than the default search.  

Say, you want a searchfield in your site only to search through the press-releases of all your departments.

• First add collective.formcriteria to your buildout and install it via quickinstaller.
• Create a new collection "Press-Releases".
• Select "summary view" as Form Results Layout in the edit-tab of your collection (thus giving you the added value of preview-images being shown if the searchable content type has a image-field, e.g. news-items).
• Edit the collections criteria and add the contenttype "News Item" (or the folder where you put the press-releases if you don't use a special contenttype) as a criterion.
• Use "relevance" to sort the results.
• Add "Searchable text" as criterion without entering a text (if you choose to enter something it'll populate the search-field as default-value) and select this field to show as "Form Fields".

Your new collection now shows you all your news items. Yawn! But when you switch the display to "Search form" the content of your collection disappears and a new search field is shown. Nice!

I prefer search-forms in portlets: Create a "Search form portlet", connect it to your collection. Voilá: custom search - whereever you want it. And that was a only an easy example.

More goodness in the most recent version include:

• The "Content"-tab now works just like with a folder, meaning you can use content-actions like copy, rename, change state and such for your search results even if they are in different folders. With that collective.formcriteria outperforms the default search in almost every aspect.

• The new "export"-Action allows you to save the results to CSV. You can specify the used columns via in the collection's "Table Columns" fields.

For custom searches using operators such as OR or NOT you still need to write your own search-forms using AdvancedQuery (and possibly anthill.querytool). But an implementation of these operators using subcollections is already on the ToDo-List.

Get it here: http://pypi.python.org/pypi/collective.formcriteria/

The plonator-sprint takes place at the department of informatics at the University of Munich and aims at improving the visibility of the plone-community.

The munich plone-user-group managed to get plone.de online since January 2011 after a year of back and forth about the domain. We plan to run plone.at and plone.ch on the same site. To enable the austrian and swiss communities to excert some control over the page yesterday I wrote a view that forwards visitors to country-specific landing-pages. Visitors of plone.de will end up at www.plone.de/de and visitors of www.plone.at at www.plone.at/at - de and at being folders with a collection as default_page and custom teaser-images.

At the moment we are knee-deep in a discussion about plone, open-source and marketing. This afternoon we'll visit the munich strong-beer festival…

Starzel.de hat für das geplante NS-Dokumentationszentrum München seit einiger Zeit einen interaktiven Stadtplan entwickelt der nun endlich online gegangen ist. Der Plan zeigt einen Querschnitt von historisch bedeutsamen Orten, die zwischen 1918 und 1945 Schauplätze von Aufstieg und Herrschaft des Nationalsozialismus waren sowie Orte die mit Resistenz und Widerstand gegen das NS-Regime verknüpft sind.

Erweiterungen um weitere Karten, z.B. zu Erinnerungsorte an den Nationalsozialismus in München sowie Orte der künstlerischen Auseinandersetzung sind in Vorbereitung. Für den ThemenGeschichtsPfad "Der Nationalsozialismus in München" entsteht zudem eine Online-Variante mit Audioguide-Einbindung.

Eine Vorversion der Software auf Basis von scriptaculous ohne Anbindung an Mapserver (d.h. mit statischen Bildern) haben wir u.a. für eine Seite über Bayerische Berufsschulen verwendet.

I tried to commit code from this directory tree:

toplevel/

  .svn/ 

  ...

  2ndlevel/

      (no .svn here)

      ...

      3rdlevel/

          .svn/

          code_to_commit

Trying

cd 3rdlevel
svn commit -m 'bla'

produced the error

svn: '2ndlevel' has no ancestry information

which I didn't understand, since the 3rdlevel was a check out of it's own, not related to the toplevel.

subversion seems to look up .svn/ directories along the complete absolute path of the directory which is checked in and hasn't recorded that 3rdlevel/ is a "checkout root".

The solution: removing the .svn in the toplevel dir (putting a reasonable one in 2ndlevel by adding it to svn might have worked, too).

Some noteable things:

• There is more than one login-form. In fact I counted at least six different login-forms. Ever heard of 'failsafe_login_form'? Searching for /login_form will not be enough.
• The page you get after logging out has it's own login-form. Since I use this page to switch back to http I chose to remove the form by customizing the template 'logged_out.pt'.
• Since I redirect to https when Plone' s Authentication-cookie '__ac' is present calling '/logged_out' while still logged-in would result in an infinite recursion. That's why I break before the rule is called when '__ac' is still set.
• Don't use the login-portlet since I don't see how it can be delivered via https if you want to deliver the site with normal http.
• Never ever expose your zope-root or login using the zope-admin-Account via http since the zope-admins password is only uuencoded in a cookie!

Here is my config:

upstream myzope {
 server localhost:8080;
}

ssl_certificate      /home/starzel/nginx/starzel.crt;
ssl_certificate_key  /home/starzel/nginx/starzel.key;

# http
server {
 listen myserver.com:80;
 server_name www.mysite.com;
 access_log /var/log/nginx/mysite.com_access.log;
 rewrite ^(.*)(/login_|/require_login|/failsafe_login_form)(.*) https://$server_name$1$2$3 redirect;
 if ($http_cookie ~* "__ac=([^;]+)(?:;|$)" ) {
     rewrite ^(.*) https://$host/$1 redirect;
 }

 location / {
     proxy_pass http://myzope/VirtualHostBase/http/www.mysite.com:80/Plone/VirtualHostRoot/;
 }
}

# https
server {
 listen myserver.com:443 default ssl;
 server_name www.mysite.com;
 access_log /var/log/nginx/mysite.com_access.log;
 if ($http_cookie ~* "__ac=([^;]+)(?:;|$)" ) {
     # prevent infinite recursions between http and https
     break; 
 }
 rewrite ^(.*)(/logged_out)(.*) http://$server_name$1$2$3 redirect;
 location / {
     proxy_pass http://myzope/VirtualHostBase/https/www.mysite.com:443/Plone/VirtualHostRoot/;
 }
}

# zmi 
server {
 listen myserver:443 ssl;
 server_name manage.mysite.com;
 access_log /var/log/nginx/heeschmusik_zmi.de_access.log;
 location / {
     proxy_pass http://myzope/VirtualHostBase/https/manage.myserver.com:443/VirtualHostRoot/;
 }
}

The cookie-regex explained (thanks to Hanno Schulz and Vlad Vorobiev for their wisdom): $http_cookie (which is a string) is searched for anything containing '__ac=' followed by 1 or more characters which is not ';' (which would mean the cookie has no value), followed by either an ';' (signaling the beginning of another cookie) or the end of the line. If you are as ignorant of regex as me you might consider keeping this regex-cheatsheet close.

By the way, this site neither uses nginx nor is it not secured. But this one is: www.heeschmusik.de. I plan to move most sites to nginx in the near future.

Feeback appreciated.