I activated the blocks feature on the Dexterity page type of Plone 6 with Volto and I get a new experience with the Volto frontend. Everything on the page are now similar to the work in a current WordPress site. I could move aroud this blocks very easily. And I found out that I could insert a blog for an image. I could set the size of this blog to small and align the image to the left side. I move this image block to the top and the first text block adapted its wide to the image block. You could see this behavior on the screenshot below.
I created an instance from the development branch of Plone 6. The source code of this branch could be cloned from the Github repository of the Open Source project: https://github.com/plone/buildout.coredev
I also cloned the Volto repository from Github: https://github.com/plone/volto and started with building the backend. Then run ‘yarn start’ and fixed the missing dependencies, especially ‘razzle’ (yarn add razzle). Once this was done yarn build the Volto client and server. I could get the Volto interface at ‘localhost:3000’ yet. But it is missing a Plone instance, because it had not been up.
I fixed this by running the instance of my Plone 6 buildout, created a new Plone site with the default name ‘Plone’. This site could be reached in the (old) classic Plone interface at ‘localhost:8080/Plone’.
I had to install the ‘plone.restapi’ inside the new Plone site (within the settings site under ‘add-ons’). The Volto interface at ‘localhost:3000’ could connect to the Plone instance yet.
I made a first test with the new Volto interface and created a new Page inside the Plone instance (inside a folder) to test its functionality. I copied a text from a popular Open Source projects website for this test. I could paste it directly into the new page. Then I tried to insert a grafic into the page. But this functionality wasn’t available in my Volto interface yet. I could integrate this grafic within the edit feature of the classic Plone interface and display it also on the Volto interface. The screenshot at the top shows the result of my short test.
It’s always an issue to protect forms (especially contact or support forms) against robots and spammer.Usual technologies of protection are the use of question and answers (e.g. a calculation task) or a captcha. But this way of protection has an impact on the usability and user friendliness of the site and especially of the forms. The user get bothered by the necessity to always look an click on small pictures. And if you use the service recaptcha for the protection task you may get in addition into a privacy issue too. The picture below shows the HCaptcha protected form.
And once the user activated the checkbox to submit that she/he is no robot, the user get the captcha showed in the screenshot below.
But there is a new solution for the protection task. This technology works with a honeypot technology. Plone community members created a new add-on, which build on this technology: collective.honeypot. They published releases on PyPI: https://pypi.org/project/collective.honeypot/. The current release is version 2.0.
I used this honeypot add-on and its technology for new versions of Plone add-ons, which I already created and published some months ago. This add-ons contain mail forms to get in contact with the author of a product or a project owner. This forms previously used the captcha technology, and especially the recaptcha service. Thus I decided to move away from recaptcha. First I created a new version of the add-on, which uses the hcaptcha service. I created a new Plone add-on for this purpose: plone.formwidget.hcaptcha (https://github.com/plone/plone.formwidget.hcaptcha). This add-on is available on PyPI: https://pypi.org/project/plone.formwidget.hcaptcha/. It’s current version is 1.0.
Once I finished the move to hcaptcha I worked on a further version of the Plone add-ons which uses the honeypot technology instead of hcaptcha. The honeypot technology makes it possible that the protection of the form works without the need of user interaction. The human user will not notice anything about this protection technology. The form has no visible extras, like e.g. a captcha (see screenshot above). Thus it is more user friendly. You can download the two Plone add-ons with the honeypot technology from PyPI:
I got the current version of Plone with the new frontend ‘Volto’ today. I cloned the repository ‘https://github.com/plone/volto.git, installed ‘docker-composer’ on my machine, activated ‘docker’ and run ‘docker-composer up’ inside the new local git repository.
I got an error with a version conflict during the first run of the docker-composer command. I had to stop the command with ctrl + c. But the second run works without issues and the demo-site was up on ‘http://localhost:3000’. It uses the usual login for Plone development sites.
Once you’re logged in you’ll get a menu bar with tools to edit existing content and create new content on the left side (see screenshot below, logged in as admin user). (This is the only user after creating the new site, but it is possible to create new users with different, fine grained rights of access).
In den letzten Tagen habe ich mein kleines HowTo, wie man LibreOffice Extensions (Erweiterungen) für Inhalte erstellt, überarbeitet. Das HowTo enthält Informationen dazu, wie man mit einer Extension verschiedene Arten von zusätzlichen Inhalten, z.B. einer Gallery mit Bildern, für seine Anwender zur Verfügung stellen kann. Das HowTo enthält auch Hinweise auf entsprechende für die einzelnen Arten dieser Non-Code-Extensions für LibreOffice. Diese habe ich meinem Github-Repository erstellt. Die Links zu Ihnen werden im HowTo jeweils genannt.
Die neue Version des HowTo können Sie von meiner Webseite über folgenden Link herunterladen:
Zwischenzeitlich habe ich auch noch an einer PythonQT-Anwendung gearbeitet, über die sich die entsprechenden LibreOffice Non-Code-Extensions (Inhalte-Erweiterungen) über eine Benutzeroberfläche erstellen lassen. Diese Anwendung können Sie aus dem Python Package Index (PyPI) herunterladen bzw. mit Pip installieren (empfohlen in einer virtuellen Python3-Umgebung):
I’m currently working on a Python program to create LibreOffice (non-code) extensions. This program uses the PyQt5 framework to create a user interface, where the extension author could add the necessary information and the links to the files which should be included in the LibreOffice extension, e.g. gallery files.
The source code of this Python program is available from my Github repository:
It is work in progress and the functions will be implemented step by step.
If you are developing an add-on for the Plone Content Management System (CMS) there will be regularly the need for some configuration options, e.g. you want the user to choose from some categories or versions. And you don’t want to hard code this options and thus make you program more flexible.
Therefore you need some fields where you could provide this entries (options) and a place to store them. The first option to do this would be inside the add-on objects itself, e.g. in the root content object. There you could add such fields, index their values into the Plone ‘portal_catalog’ and query them from there. But I think there is a much better option to set such options. You could create a controlpanel and add this to the ‘site configuration’ page, dedicated to the admin and site admin of a Plone site. There is already a section for add-on configuration entries available.
It’s very easy to add new configuration fields to the controlpanel. There are fields available for lists, tuple, Textline and Text etc. The values of the fields could be stored in Plone’s ‘Configuration Registry’ and taken with features from the Plone api from there very easy.
Here a first example for the source code of a controlpanel:
# -*- coding: utf-8 -*- from collective.templates import _ from plone.app.multilingual.dx import directives from plone.app.registry.browser.controlpanel import ControlPanelFormWrapper from plone.app.registry.browser.controlpanel import RegistryEditForm from plone.supermodel import model from plone.z3cform import layout from Products.CMFPlone.utils import safe_unicode from zope import schema from zope.interface import Interface class ICollectivetemplatesControlPanel(Interface): available_category = schema.Tuple( title=_(safe_unicode('Available Categories')), default=('Business',), value_type=schema.TextLine()) allowed_templatefileextension = schema.TextLine( title=_(safe_unicode( 'Allowed template file extensions')), description=_(safe_unicode( 'Fill in the allowed (...).')), default=safe_unicode('ott|ots|otp|otg'), ) legal_disclaimer = schema.Text( title=_(safe_unicode( 'Text of the Legal Disclaimer and Limitations')), description=_(safe_unicode( 'Enter the text of the legal disclaimer (...).')), default=_(safe_unicode( 'Fill in the legal disclaimer, (...).')), required=False, ) (...) class CollectivetemplatesControlPanelForm(RegistryEditForm): schema = ICollectivetemplatesControlPanel schema_prefix = 'collectivetemplates' label = u'Collective Templates Settings' CollectivetemplatesControlPanelView = layout.wrap_form( CollectivetemplatesControlPanelForm, ControlPanelFormWrapper)
The code above showed different field types for the configuration options. There are the ‘Tuple’ which contains a listing of values. Because the value type is schema.Textline every line of the field contains a single value of the listing.
Then there is a TextLine field for in this example a single value of allowed file extensions. The different allowed values are seperated by a pipe in this case.
The last field is Text field which is able to get a text with more than one line. In this case a text which should be shown to a user (contributor) of a site. It would be possible to use also a RichText field inside this controlpanel, but there will pop up an error message once you try to write the value of such field to the Plone Configuration Registry.
But the use of a RichText field isn’t necessary in this case. If you want to display the content of a Text field on a webpage inside Plone you could write the text including HTML tags, e.g. for headings and paragraphs.
I’ll explain in an upcomming blog post how to add this controlpanel to the site configuration page and to write the values of the fields to the Plone configuration registry.
The last lines of the above source code example create the registry form from the above schema.
I made a quick calculation of the emails that were sent to the project organization list of the LibreOffice germanophone project (de-discuss-list). I looked at the number of mailing addresses which were subscribed to the list and the number of postings during one year from 2015 to 2020. I started with the numbers from 2015-06-14 and my calculation endet with the numbers from 2020-06-21.
The number of mailing addresses subscribed to the list:
– June 2015: 198 addresses
– June 2016: 208 addresses
– June 2017: 204 addresses
– June 2018: 208 addresses
– June 2019: 210 addresses
– June 2020: 221 addresses
I calculated the number of mails during one year since June 2015:
– June 2015 to June 2016: 1208 new mails
– June 2016 to June 2017: 1281 new mails
– June 2017 to June 2018: 1087 new mails
– June 2018 to June 2019: 865 new mails
– June 2019 to June 2020: 699 new mails
Although the number of mail addresses subscribed to the list increased during the period (with one exception) the number of new mails declined dramatically to approximately 54 percent. Thus the communication inside the open source project went alarming down.
Update December 2020
I looked again on the numbers on the mailing list of the germanophone project to get an impression, if there is some change in the direction. But I had to state that the numbers develop in the same direction further:
– December 2019 to December 2020: 514 new mails
Although the number of inscribed mail addresses increases from 213 to 222 the communication inside the open source project went down further.
I worked on a Plone add-on to manage conferences. I already created such an add-on to run the LibreOffice conferences in Berlin (2012) and Milano (2013). But this add-on was build against a former version of Plone and Python 2. It used the Grok style which could have some side effects. Thus I decided to move away from Grok style for an upgrade / a new setup of the add-on.
I already moved all modules and active functions away from Grok and reordered the structure of the add-on. I added a new configuration panel to the administration page. I could also fix relations and the indexing. You could get the code from Github at: https://github.com/collective/collective.conferences.
I worked further on a Plone add-on to manage conferences and had to work with the navigation root of a Plone site. I moved this navigation root to the container object of the conference add-on. The navigation worked as expected yet (the objects in top container made it to the main navigation menubar), but the login and register links at the top of the site didn’t work anymore. Thus I had to edit the links of this actions / portal_actions inside the ‘Site Setup’ or the Plone ‘Management Interface’. I added a short howto about this.