- Entries : Category [ Zope ]
Bye handmade, hello coreblog
or how I decided to change my filosophy about that
Yes, after almost 4 years I have decided to switch my website from a handmade code written in Python on top of Apache and mod_python to coreblog on top of Zope.
This was a hard decission to take, because I like to have my own code running somewhere, and I'm proud when my creations are useful, even if they are useful only for me.
Once i've decided to switch, the first thing was to learn a little bit more about coreblog itself, and how to change the ugly (at least for me) default skin.
Coreblog comes with 2 skins by default, default and plonified (this one didn't work for me anyway), but I want to give my new weblog some different look and feel.
Obviously, the base design is not mine, I just got it from OSWD, more precisely the Syndicate Me one. I just picked up the free design and I used it as the base for my own design. More changes will be applied soon.
Once I got the template, I could play a little bit with the coreblog integrated skin system. It couldn't be easier. I only had to copy the skins/default folder to another folder like, for example, skins/e-shell.
Then I got into the new skin directory, just to change the stylesheet file and replace the contents with the CSS code from the template.
This was a little bit tricky, because I had to mix the template css naming convention with the coreblog names for css classes and ids. Anyway, it didn't took me more than one hour.
Well, after changing the css stylesheet file, I still had some work to do with some DTML files inside the skin directory. The most important one is index_html, where almost all the blog is mixed and prepared for publishing, with blog_banner, blog_header and blog_footer being important too (as those are imported within index_html to assemble the header and the footer of the weblog.
Depending on each setup, it is probably that more files should be changed, like entry_body for the layout of the inner part of each post.
So, finally, after some work (near 2 hours) I have my coreblog site as I would like it to be. Now I should read some more about the inner aspects of the software, how to customize it's functionalities and learn about all the options it offers.
or how to update your wikis in less than 5 minutes
I've been using Zwiki a lot lately. I use it for some internal documentation sites at work, I've set up a customer private zone for Codigo23 customers and I've been setting up a new site for e-shell.org and Codigo23 based on Zwiki.
Before beginning to use it so much, one of the first things I tried was the Zwiki upgrade process,that is, the way I would upgrade all those sites, and if that process would be painful (like with any other systems) or not.
Well, today I decided to switch my production wikis from 0.59 to 0.60...
And it was a really easy operation.
First I downloaded the latest -stable version from Zwiki.org (saving the sources inside the Products folder of my Zope instance):
[Frey] /usr/local/www/Zope210/e-shell/Products> wget -c http://zwiki.org/releases/ZWiki-0.60.0.tgz
Resolving zwiki.org... 22.214.171.124
Connecting to zwiki.org|126.96.36.199|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 644,475 (629K)
100%[====================================================================================================================>] 644,475 102.89K/s ETA 00:0
17:43:51 (98.73 KB/s) - `ZWiki-0.60.0.tgz' saved [644475/644475]
Then I created a backup for the old Zwiki release:
[Frey] /usr/local/www/Zope210/e-shell/Products> mv ZWiki ZWiki-0.59
and after than I unpacked the .tgz file containing the new release:
[Frey] /usr/local/www/Zope210/e-shell/Products> tar -zxvvf ZWiki-0.60.0.tgz
And of course I restarted my Zope instance:
[Frey] /usr/local/www/Zope210/e-shell/Products> sudo ../bin/zopectl restart
. . . . . . . . . . daemon process restarted, pid=39256
and et voilá, I have all my wikis upgraded to 0.60.
HoneyPotBL Zope product
or how to secure your comment forms...
One of the reasons I've switched recently to CoreBLOG + Zwiki (instead of the old handmade code) is Betabug. Well, not himself, but all the ideas, comments and suggestions from him.
Today, he released a new Zope product of his own, HoneyPotBL. This product allow you to check the blacklist databases from Project Honeypot within any other Zope product you have installed, Which means that you can check comments or trackbacks in your blog, posts in your wiki site or phorum, etc in real time and discard those from any well-known spammer in those blacklists.
Now time for a little howto on how to integrate that with some products?
UPDATE: you can read more about the HTTP:BL spec here: http://www.projecthoneypot.org/httpbl_api.php
Problems with COREBlog and page encoding
or how you shouldn't mix different charsets...
Probably most of you who speak spanish noticed that my posts that were written in than language appeared corrupted until some hours ago.
Well, basically the problem was that everything in this blog is managed in UTF-8 while (I still don't know why) COREBlog itself is encoding all the pages as ISO-8859-15 before serving them. Of course that caused that all the spanish special characters (accented vocals, the famous ñ and some more) appeared as strange symbols on screen.
The solution to that problem is really easy, I only had to add a single line to the blog_header DTML method inside my skin folder:
<dtml-call "REQUEST.RESPONSE.setHeader('Content-Type', 'text/html; charset=utf-8')">
That forced COREBlog to set the proper content-type in each page headers (to UTF-8).
MiniPlanet, a Mini Feed Aggregator for Zope
or another Zope product from the greekmeister...
As you should noticed lately, last week I set up some kind of a little planet, just there, on the left side of this blog, under recent comments.
This little planet is powered by MiniPlanet, a new Zope product from Betabug. I've been testing it during all that time, and it is very useful, so I recommend you to give it a try.
The product itself picks up feeds in rss/rdf format and creates a little (and customizable) html result that can be used with any other Zope Product (not only COREBlog).
Seems like our friend has been very active lately, this is the second Product release in 2 weeks, after his HoneyPotBL product.
Plone vs Zope
or how your little child could eat you up...
After reading that post in Chris McDonough's blog, I've been thinking about that Plone vs Zope topic.
I've covered such topic before. For me, it is clear that Plone is a Product (like any other) inside a web application server like Zope (at least Zope2). Anyway, Plone has grown a lot those years, getting closer to end users, so it is very common to find users/customers/bosses that ask for Plone directly, even if they do not need the full bloated Product.
Do not misunderstand me, in my oppinion Plone is a very good piece of software, probably my choice to build big high-end robust web portals, but sometimes you can find better solutions to given problems.
For me, it is like driving a truck, when you only need a bike.
If you've read Chris post, there you will find that it seems like Zope3 isn't so used as expected because of that too, that is, Plone runs on top of Zope2, not on top of Zope3, so Zope2 is still the preferred environment (because people don't know even about Zope2, they ask directly for Plone).
That's even worse, because Zope3 is a totally different approach to web development as in Zope2, it is closer to a web development framework than to a web application server, so you can't compare Zope3 and Zope2 directly (nothing to say about comparing Zope3 and Plone).
Finally, there is grok, a new web development framework built on top of Zope3, which is getting a bigger name than Zope3 itself in the web development world. Anyway (imho), grok couldn't be considered to Zope3 as plone is to Zope2, because Plone is a product to build web portals (among other things), while grok is a framework you can use to build whatever you want.
Conclusion: It is clear that Zope2 needs plone to survive, but I do not think that Zope2 should be used exclusively with Plone, there are a lot of other interesting Products out there, and building your own is pretty easy.
Conclusion (another one): It seems like the time to begin playing with Zope3 and their components and new ideas, now it seems mature enough, and things like grok probe it.
Plone, Zope and the PlacelessTranslationService
or when you feel yourself lost in a vast ocean...
Last two days I've been trying to figure out why PloneGazette didn't work properly in a Plone site I've been working on lately. Plone version was 3.0.5, on top of Zope 2.10.5, everything running (almost) fine, but that PloneGazette product didn't want to show up in my site default language (spanish).
At first, I noticed some ugly error messages in Zope's event.log:
2008-02-12T14:10:25 ERROR Zope.SiteErrorLog http://prunus:8080/Control_Panel/TranslationService/PloneGazette.i18n-plonegazette_es.po/index_html
Traceback (innermost last):
Module ZPublisher.Publish, line 122, in publish
Module ZServer.HTTPResponse, line 262, in setBody
Module ZPublisher.HTTPResponse, line 324, in setBody
Module ZPublisher.HTTPResponse, line 476, in _encode_unicode
UnicodeEncodeError: 'latin-1' codec can't encode character u'\ufffd' in position 4192: ordinal not in range(256)
Weird, seems like there was some problem with the translation file for spanish. After opened up the ZMI in a web browser, I took a look over the PlacelessTranslationService just to find out that the special spanish characters (accent vocals, ñ, etc) were screwed up.
After a while, I noticed that the translation file set up its charset as iso-8859-1:
"Content-Type: text/plain; charset=iso-8859-1\n"
While the file itself was encoded as UTF-8:
[prunus] /usr/local/www/zope2105/Products/PloneGazette/i18n> file plonegazette_es.po
plonegazette_es.po: UTF-8 Unicode PO (gettext message catalogue) text, with very long lines
Well, easy solution to an ugly problem, just setting up the right encoding solved part of the problem:
"Content-Type: text/plain; charset=utf-8\n"
After changed the .po file, I just reload the catalog for it in the PlacelessTranslationService and the event.log error went away.
NICE! (I thought), I just tried again the Plone site just to find out that the PloneGazette messages were still in the default language (english). WTF...
Then I noticed that the site was as its default language spanish(spain), that is, es_es, while the .po file for the spanish translation was primary for es and it was the fallback for those:
"X-Is-Fallback-For: es-ar es-bo es-cl es-co es-cr es-do es-ec es-sv es-gt es-hn es-mx es-ni es-pa es-py es-pe es-pr es-us es-uy es-ve\n"
Exactly! no es_es in there!
So, two easy solutions:
- Change the default language for the site to es
- Add es_es to the list X-Is-Fallback-For
And then the problem was solved (well, sort of, cause the .po file wasn't entirely translated anyway).
COREBlog and pygments
or how to get your source code blogged and colorized!
This is a little recipe for all of you, COREBlog users out there.
In this very site, I've posted some interesting things about (for example) Django, or some shell scripting examples. As I'm using reStructuredText as my markup language, I always marked source code snippets with the usual :: (which in rst will be translated into <pre></pre> in HTML format). This ends in the sourcecode appearing as any other pre/code/similar text, which isn't as cool as seeing the code as in my favourite development editor.
In Emacs, I use a special mode for each language I usually work with, so the code gets (among other things) colorized. Wouldn't it be cool to have my code colorized online too?
After searching a little bit, I found Pygments:
a generic syntax highlighter for general use in all kinds of software such as forum systems, wikis or other applications that need to prettify source code.
Of course, it is Python code, so I thought that it should be pretty easy to integrate it with some other Python-based apps like COREBlog (in fact I've created a little Zope Product to create paste sites on top of Pygments, but that's another story).
To integrate Pygments and COREBlog all you need is to get the file rst-directive.py from Pygments and save it inside your COREBlog Product folder:
[Frey] /usr/local/www/Zope210/e-shell/Products/COREBlog> ls -l rst_directive.py
-rw-r--r-- 1 wu wheel 2490 Nov 21 2007 rst_directive.py
(I've renamed the file to rst_directive.py to avoid problems importing the file later)
Then, all you have to do is import this module into COREBlog. To do that, add the following line on top of the COREBlog.py file inside your Product folder (where you put the rst-directive file):
(You will see more imports there, put that line wherever you think is a good place for it)
Now restart your Zope instance and you will be able to use the sourcecode directive in rst, someway similar to:
.. sourcecode:: python
(which I've used some lines above)
That will generate all the necessary HTML code to highlight properly the source code snippet.
Finally, you will have to add some CSS styles to your site stylesheet. You can get all the necessary stuff to put into your css files using the get_style_defs() method from Pygments:
>>> from pygments.formatters import HtmlFormatter
>>> print HtmlFormatter().get_style_defs()
Just copy the CSS style definitions you will see on-screen to your COREBlog skin CSS (probably located, inside the ZMI in yoursite -> contents tab -> skins -> yourskin -> style_css dtml method) and you are done!
Note: of course you can colorize much more source code than only Python, just take a look at Pygments Lexers to know how to call the proper lexer for your programming language.
Zope Security advisory 2008-08-12
it is not too dangerous anyway...
From http://www.zope.org/advisories/advisory-2008-08-12 :
PythonScripts in Zope 2 can be misused for shutting down
a complete Zope 2 instance or misused for a local denial-
of-service attack. This issue affects only those Zope 2
instances where users have unrestricted access to the ZMI
and the ability to edit PythonScripts. This should
usually not be the case for instances where the Manager
access is granted only to trusted persons.
Anyway it is not too dangerous, because you usually do not give manager access to untrusted users. Luckily, install the patch that solves the problem is as easy as download it, put it inside your instance Products folder and restart your Zope instance.
(More information in the README file)
(Ah!, and exploiting the bug is pretty easy once you have manager access, I did some tests by myself some hours ago and all were successful)
ImportError: No module named i18n.normalizer.interfaces
this one was hard to solve...
Today I've found one of those ugly problems that took me some time to resolve. In one of my servers I've a Zope instance that was created using a Zope install from the FreeBSD ports collection (pretty useful if you only need plain Zope, as it was my case). Since I installed such version of Zope, I've added a plone "production" buildout to the same server and everything was running smoothly... until I had to restart my original Zope instance (which, yes, has an old plone site inside too). Zope restarted correctly, but when trying to access the plone site, I got a message about the plone site being broken... wtf?.
I took a look over the event.log file of the Zope instance, and I found this error:
ImportError: No module named i18n.normalizer.interfaces
Pretty strange... but seems I wasn't the first one with this problem. In the end it was a path-related problem, as the python process running Zope was picking up some modules from the site-packages directory, instead of the instance lib/python directory.
Final solution?, easy, I just modified my zopectl script to get something like:
export PYTHONPATH INSTANCE_HOME SOFTWARE_HOME
exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@"
Setting PLONE_SOFTWARE_HOME and adding it to the PYTHONPATH var.
(of course I should have moved the plone site into the buildout, but that is another story...)