Archive for the ‘zope’ Category
Three Plone addons – part 3 : CKEditor for Plone
Why Plone4 is so cool ? because you can create easily new addons in a pure python way, look at this new addon called « CKEditor for Plone ».
A screencast here :
More information here :
Some lines of code are used to take original ckeditor svn code and place it in a Zope browser resource (because Zope is really strict about XML/XHTML we must do this little work, i hope i could replace it by a simple svn-externals in future).
Other lines of code are here to call dependencies (collective.plonefinder to search server resources, collective.quickupload for fast upload, see previous posts).
The most part of code is CKEditor Plone control panel because it’s important for managers to allow or disallow features, toolbars, or some plugins on their Plone site.
The last part of code is the CKEditor integration in plone wysiwyg templates.
Hmm, that’s all.
Some people ask me, why CKEditor ? Plone4 has Tiny MCE …
– CKEditor is fast (really fast)
– CKEditor is accessible ( http://www.w3.org/WAI/WCAG1A-Conformance)
– because i’m a FCKeditor’s friend since 10 years, Fred (Frederico Caldeira Knabben) had no chance, his initials offend some English spoken people, now than the software name is more accessible perhaps more people will be interested in its features ?
– Plone needs to be good but it also needs to have reliable addons, and CKEditor cames with a good Plone integration (relax with collective.plonefinder and collective.quickupload)
Three Plone addons – part 2 : Collective Plone Finder
Collective Plone Finder is a tool for Plone developpers that can be used to find and select elements in a Plone site. The pypi name is « collective.plonefinder » with one dependency called « collective.quickupload »
It’s a widget’s helper, and you will find in the code a simple form lib widget, it’s an example of how you can use this product. In the README.TXT, you will find a way to use the formlib widget in a Plone portlet.
In this screencast, CPF is used in a portlet named « CG30 Direct Access Portlet » (CG30 is a client) :
The goal of Collective Plone Finder is not to be used as a standalone product. But, in this second screen cast and for demonstration purpose, we use it in a full browser screen just to show you the different potential uses. Look at the address bar where you can pass some params in querystring.
More information about this package can be found here :
This product is not complete (need more documentation, unit tests, some refactorisation, and some ajax popup functions are not finished at this time, 1.0.0), but i released it because it was an important part of my third autumn Plone production « CKEditor for Plone », see the next post.
I know that many documentation is missing, free time is too short, so if you need to integrate quickly CPF features in your own widget, at this time the better way is to read the code (really easy to understand, it’s Python + Plone, a devel dream). In future i hope many good evolutions will came with Plone4 new energy.
Three Plone addons – part 1 : Plone Quick Upload
As good things usually happen in threes, i present you three new Plone addons i released in September 2010, i hope you will find them useful.
Plone Quick Upload has a control panel with useful options (limit size, limit parallel uploads, direct upload on select, fill titles before upload, …) :
As you can see, Plone Quick Upload manage errors and returns i18n messages when an upload raise an error (file always exist, file is too big, no permission to add content, bad content type, etc …).
For unfortunate MSIE users, the pure javascipt way cannot allow multiple selection and drag and drop, so the upload form has a graceful fallback, look at the next screencast, it’s not so bad.
More information about Plone Quick Upload (installation, use it in your own template, etc …) here :
Usually we build multilingual Plone sites with LinguaPlone.
This solution has a big advantage, it’s generic and very easy to implement in a plone site.
But there are many inconvenients, due to the design of this product (translations are independent by design) :
- Each translation is a new Archetype object, and it could be a big problem on sites with many contents, the portal objects number is increased by the number of available languages.
- Translations uses plone references catalog to be linked to the original (called canonical) object, but when moving objects translations are not moved, when copying pasting objects, translations are not pasted, when deleting objects translations are not deleted, when reordering contents, translations are not reordered, when publishing objects translations are not published, … For web masters maintaining a site with LinguaPlone inside could be a challenge.
- When translating folders with LP, all translated contents are moved from the canonical folder to the translated folder with same language, translating low level folders on big depth tree sites could take a long long time, don’t be surprise if you get errors.
- If a content is neutral (with no language attribute), inside a translated folder, it could not be seen when browsing a translation of the parent folder.
- At last a lower problem : the translation edit forms are not pretty to use, they show a table with two columns, the first column with the « canonical » content inside in « view » mode, the second column with the translation edit form, in fixed width sites the translated form width is sometimes ridiculously small.
But since many years we use LinguaPlone because it was the only easy way to make multilingual Plone sites.
By the past we were using a LP patch called LinguaFace to reduce the number of problems with LP (synchronisation on reorder, copy-paste, delete, or move – see neutral contents inside all translated folders – more usable translation edit forms …), but LF add a new layer of complexity and maintaining it with all LP versions becomes complicated. See some examples on how it works :
- when a content is copied, all translations are copied
- when a content is pasted or moved all translations are pasted or moved at the good place (not so easy)
- when a content is published or retracted translations follow the same workflow transition
- when a folder is translated, we don’t see only objects inside but also objects with same canonical Path (a new catalog index) to see also neutral contents.
- Navtree is patched, breadcrumbs are patched, to use canonical path
- and so on …
A big nightmare.
To day a new solution exists that store translations inside each Archetypes field, raptus.multilingualfields, and a Plone integration of raptus.multilanguagefields called raptus.multilingualplone that extends the schema of all Plone Content Types making them translatable. raptus.multilingualfields also provides multilingual catalog indexes that return the good translated data when searching for contents or displaying trees, and multilingual criterions for topics.
A LP feature not provided by raptus.multilingualfields is the internationalization of urls, if you really need this feature, i think it’s not a big challenge to add some traversal rules, for me it’s not essential.
AnotherLP feature that can’t be provided when storing translations in fields is to get different workflows or security settings for each translation. If you need this feature use LinguaPlone, LinguaPlone is done for that, it makes all translated contents independent, but i’m curious to know the number of users who really want this feature, all clients i had never ask for that but finally, after some LP experience, always wanted the exact opposite use-case.
To make your Plone site translatable with raptus.multilanguagefields, you have two choices :
- Add raptus.multilanguageplone in your buildout and install it in your Plone Site using extensions products control panel, to make all your Plone content types and derived translatable (all fields for which translation make a sense are translatable).
- I prefer integrate by myself raptus.multilanguagefields inside a product, since we could want just some fields or content types translatable, as example i don’t need to translate the images or the files contents, just their titles and descriptions.
How to implement the second solution ?
Just take a look at raptus.multilanguageplone code, it’s easy :
- Make your archetype extenders to make your wanted fields translatable, example can be found here
- register your extenders in setuphandlers (Generic Setup import step), example here
- replace the standard catalog indexes with multilingual indexes in Generic Setup profile, example here
That’s all, you will get superb edit forms with translatable fields inside, you also will get a google help to translate contents (a pleasant gadget). I say « Bravo » to raptus developpers.
- these products are young, and there’s still many work todo to make it work without problems (tests are needed …). Last 0.6 releases have bugs under plone3.3, use the svn versions below instead.
- raptus.multilanguageplone 0.6 has a bug in extenders with primary fields, tested in Plone 3.3 (fixed in branch aws_evols, not tested with images at this time)
- raptus.multilanguagefields 0.6 has a bug, doctests are broken in Plone3.3 (fixed in trunk )
- At this time these products don’t have unit tests or functional tests, it’s the only reproach i can make. I started the work here, and here
Since Plone base properties style could seems too rich for a standard use case, phantasy skin edit forms could be also too complex.
When i saw how easy it is to change some skin properties in a blog system like word press ( …), i thought we need the same feature in Plone.
Collective Phantasy is done for that.
Building a new skin product with a standard static theme and a customized skin schema is something you can do easily with collective phantasy.
If you want an example, just test the « 3 colors theme » plone product.
In your buildout :
in instance eggs section add :
in zcml section add :
Relaunch your buildout.
Launch your zope instance.
In plone_control_panel you will get :
Check for « Three Colors Theme » Product, this will install the product and its dependencies :
Go back to the home page, of course the « static » theme has changed (my poor contribution to plone themes community)
We want to change the dynamic properties, so we click on « Contents » tab, and we can see that everybody is here : the dynamic root skin for portal, and the phantasy skins repository (read previous posts …) :
We want to build a new skin, so as we have seen in previous posts, in phantasy skins repository we add a new skin :
In this form you could see differences with a classic phantasy skin form (for developpers/integrators look at the code it’s just some easy Archetypes bidouille) :
– 3 colors only + mutators to change all colors
– an entire fieldset removed
– many fields unuseful in this theme are hidden
– some skin attributes added in schema
Go back to reality : just change some colors
Now we will import a skin sample provided in « three colors theme product ».
In alternate_skin folder you will find a zip file and a txt file (howtouseit.txt).
Click on « import images and files », choose the alternate_skin.zip file
Read howtouseit.txt and change some colors or properties
Use plone kss power to change images’ names quickly
CTRL-F5 to refresh the page, of course you need some design feeling to understand what’s happen here, but it’s not so complicated (…)
In the product you will find another example with another howtouseit.txt, here, then just add a folder and choose the good phantasy skin and you will get :
Loving Plone 🙂
Today we will work on skinning Plone, you will see how easy it is, especially when using collective.phantasy.
This product is only plone3.1.x (and perhaps ++) compliant.
I suppose you know how to build a new plone instance using buildout. I know it’s not always so easy for Windows users, but keep cool, read documentations about buildout (it’s a really powerful feature), and send a comment here if you get problems with this question, i will try to help you .
So, in your plone3.1.x buildout.cfg, just add these two lines : In instance – eggs sections :
In instance -zcml section :
Now you could launch your buildout :
Then launch your Plone instance.
Install collective.phantasy in Plone
Go on your plone site > Add/Remove Products You will get this screen :
Check for « Collective Phantasy » product and Save the form.
This will install « Collective Phantasy » product and its dependency « Smart Color Widget » :
The portal look is changed, but it’s just an example, not the best wonderful design ever seen ;-),
so we will change it.
Change the portal skin
Go to your portal root, click on Contents :
You will get two new items :
– An Item called « Phantasy Skin repository », it’s a folder containing alternate skins for folders
– An item called « Plone’s logo, colors and border defaults », it’s the dynamic skin used for your portal, you can delete it and recreate it, but now we will just change it click on this item,
then click on « edit » tab
Click on « Colors » tab, change the background color value for « #f3f3fb » :
And save the form, here is the result :
Re-click on edit tabs, then on « dimensions » tab,
change the values for ‘portal width’ and « Portal horizontal position » like this :
And save the form :
hmm it’s better but we will do some new things.
First we will add our logo.
Go back to your skin, use the contextual menu : « Add new… », choose « Skin Image » :
Click on Browse (« Parcourir » in french ), choose your logo image on your HD :
Save the form. Go Back to your skin.
We will change the logo name in skin. Click on edit tab, then on « images » sub-tab.
Change the logo name value for « logo.gif » (the image id you’ve just uploaded), and save the form.
Here is the result :
Go back to your portal home page and refresh the page, CTRL-F5. If you want to see the left column as shown in next image you also need to change the portlet navigation property with « Manage portlets » …) :
Setting a new skin and choose this skin for a particular folder
See global tabs at top, Click on « Folder with other skin »
You see that the portal look is changed here. Ok. Go back to the Phantasy Skins Repository, click on Contents, you see here alternate skins which can be used by any folder :
Click on the only skin present here :
Oh, oh … the same look as we’ve seen somewhere before.
OK, now we will change everything, go back to the portal root > Contents tab, select the dynamic root skin and click on « copy ». :
Go back to the Phantasy Skins Repository, and click on « Paste » :
We will rename this skin, it could be practice, check the second skin and click on « rename » :
Then click on this skin to go on it. Now we will do always the same thing, click on « edit » and change background color, but take care because now the color value must cohabit with a future background image (use Firebug extension to help you) :
Create a css for your skin
Now we will do something special that’s not embed in Phantasy skin parameters. Edit a text file, save it on your HD as a a css file, here we call it « ornicat.css », we add a little new selector in this css, this selector add
a large left violet border to the page :
Create some images used by your skin
We create a global background image which can cohabit with the background color, using Photoshop or any picture dedicated software (we save it on local disk as « portal-background.gif ») :
We create a new logo with the same software (we save it as « logo-2.gif ») :
Post all these files in your skin
Create a zip archive with the 3 precedent files :
Go back to your browser, to your site and to your skin, click on « Import images and files » :
Click on « browse », choose your zip file on your local disk.
Click on import, wait during upload …
Upload is done
Setting up your special skin
Click on « Edit » tab, enter the css file id (ornicart.css here)
Click on « images » sub tab
– Change the logo name for the new logo id (logo-2.gif)
– add a body background image name with your background image id posted first (portal-background.jpg)
– change background image position for « Top right »
– change background image repeat for « Vertcal repeat »
– Save the form
Here is the result
Ah, i think it’s better
Give a folder a new skin
Go to « Folder with another skin », click on Edit, Below Phantasy skin, click on « Add », now you can browse the site for a new skin, Choose the « Alternate skin » we’ve made before.
Save the form Click on CTRL-F5 to refresh the page.
Now you can say « Skinning Plone is not so complex ». 🙂