We define safe e-commerce as "a digital financial transaction where the sender and recipient both can feel safe". This means that the shop knows that the vital client information they handle can't fall into the wrong hands through unauthorised access to computer systems. Moreover, the end client can feel safe in the fact that the shop handles the information with the highest level of security possible.

Big systems built on sandmark

The popular and big systems Magento and osCommerce are built on the sandmark PHP. Independent of how skilled the programmers are, and how big the systems are, it is impossible to disregard the fact that PHP is the language that has the most security gaps. Google built everything based on solid grounds, and for the exact same reason we use Python.

We create safe solutions based on safe systems

In order to guarantee safe e-commerce solutions we work with Plone and Python. That makes it possible for us to avoid the security risks connected to other systems, and to focus on developing nice and profitable web shops that fit our clients' needs. We build solutions for the future and our goal is to always be one step ahead with security.

Do you want to know more?

Contact Sasha Vinčić for more information.

or fill in the online form

Phone: +46 708 840 660

Plone was released nine years ago, and it was the most secure, beautiful NoSQL CMS and the only one available to that date. Today it is still beautiful, fast and the most secure web CMS. It is going to be very interesting to hear about the plans for Plone, with exciting elements such as Deco and Diazo.

Pyramid – Django

Many Plone developers are using the Pyramid/Django frameworks to create advanced products online; this year there will be a related technology track and I heard that Daniel Greenfeld will talk about Django. Paul Evert is also giving a lecture on Pyramid for humans.

Multilingual sites

If accepted, I for one will give a talk about managing multilingual sites with caveats and tips. It is a non-technical talk which I also gave in 2009 and 2010 which presents use cases from multilingual sites and possible solutions to them. If you have any tips to improve the talk, add a comment or send an email to me.

We would like to thank Sipri for entrusting their confidence in us to secure and upgrade their website to Plone 4.1. We had just begin to find our feet after upgrading another site to Plone 4.1, so we felt quite confident in being able to finish the task in one week. See below what the client thought and read more about Valentine and Sipri(SV).

Dear Sasha and Pawel,

It seems that everything works fine now and the website is much faster than ever before.
Of course there will always be one or two things that need to be corrected.

Everything went very smoothly and I really appreciate the good work both of you did for us.
I hope in the future you will also be able to assist us with our website work.

Have a well deserved vacation.
Best regards,
Gerd
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gerd Hagmeyer-Gaverus
Director
Facts Databases and Early Warning  Programme
Director
Information Technology Department

STOCKHOLM INTERNATIONAL
PEACE RESEARCH INSTITUTE

That was about all they said to us during our first meeting, and they finished by saying that we have 40 hours to do it. They wanted us to take their Plone 3 site which we had never touched and uppgrade it to Plone 4.1 in one week.(Swedish) From our experience we knew that this would be a very difficult challenge to pull off. They said: Surprise us!

We accepted the challenge

We didn't, however, need to start from the beginning. They already had a buildout with an upgrade to Plone 4 which they had already started. In the end we managed to surpass both our and their expectations with flying colours. We had a working Plone 4.1 site up and running after one week!

We deliver Plone services to INCF

INCF were satisfied(Swedish) and decided to continue with our collaboration. We want to thank INCF for their confidence, and to also take the opportunity to thank Metamatrix for letting us be a subcontractor of Plone services.

Do you need a website provider?

Do you need an enthusiastic, knowledgeable and reliable website provider and e-commerce provider who can follow your development long term? Contact Valentine Web Systems for a quotation.

I'll probably end up changing my mind several times during the days and one or two regrets missing some talks but I hope it will be a nice time like all other conferences and a chance to meet friends.

Oh one more thing don't forget board nominations if you know anyone that should be on the board, even your self. Last day tomorrow Monday.

See you at the conference.

/Sasha

   >>> service = getUtility(ITaskService, name='LongRunningJob')
   >>> service.add(u'exampletask', 'input to the task')

The service will execute the task as soon as the other tasks in the queue are completed. The service and the task are registered as named utilities in zcml.

lovely.remotetask is ported to Zope 2.9 and works on 2.10 as well. It depends on zc.queue which runs on 2.9/2.10 without modification. The code is found in zope svn

The zmi (managing services and tasks) is not ported, but there is an example in svn that tells how to do it programmatically. Removing tasks can already be done in zmi as the utilities are added to the utilities folder in the site root.

Headnet sponsored this work.

Me and and Matt Hamilton started to work on improving the speed of cataloging while you move/rename a tree of objects. Matt had already an idea about using md5 hash on ZCTextIndex which in a quick test gave 30% speed improvement when you edit a document but don't change the body. But when we renamed objects we didn't get this improvement because the object got unindexed and then indexed on the new path so we tried do some magic in ObjectWillBeMovedEvent which would move the index in catalog for this object to the new path instead of unindexing and then get reindexed on ObjectMovedEvent instead of clean index. This way we could benefit from our speed improvement with md5 since the body isn't changed.

This was quickly done and the profiling after this indicated that object_provides indexing is taking way too long. We found out that the calls to zope.component.interface.interfaceToName was to be blamed for this. We tried some simple caching on it with plone.memoize and yeah! We slashed the indexing time by half on rename on a site with 300 random content objects! We let Martijn Pieters take a look at the method and why it was so slow just for an interface name. He found out that Plone really shouldn't use this for object_provides since it was there for a specific use case (I hope Martijn can comment on which) .

Martijn commited the fix, so current plone trunk has an indexing that is twice as fast as yesterday. This commit does not include the magic on ObjectWillBeMovedEvent and md5 so expect more speedups :)

NB! This fix is for trunk (plone 3.x) but me and others have the object_provides index in older Plones so please check the diff (see also) and fix your indexes to get some speed.

Thanks to Nate at Jazkarta for sponsoring, we got a nice sushi delux meal for dinner yesterday.

Since Lovely Systems has deployed some fast sites I was eager to see if I could reuse some of it with Plone. One of the products was lovely.remoteinclude which enables viewlets to be accessed through own unique urls and therefore cached separately. With nginx you can then use SSI (server side include) to assemble the page instead of doing it all in Plone. The lovely.remoteinclude hooks up adapters for all IIncludableViews if they send the event zope.contentprovider.interfaces.IBeforeUpdateEvent. The adapter then checks if the view is called from within a page or directly. If it is called within a page the render method is changed so it renders the url to the view, and when called directly, no changes are made.

My task was to try to make Plone portlets accessible through urls. This was little bit harder then just marking the PortletManager and PortletRender with IIncludableView since they where not normal viewlets or viewlet mangers and there was no acquisition in portlets. Anyway after some pair programming with Tom Gross we managed to create a package valentine.remoteinclude (we didn't dare to name it plone.remoteinclude). This package is a proof of concept that lovely.remoteinclude can be used on Zope2 and Plone. It will provide urls for portlets that are available on the plone root. While we were learning the plone portlet machinery we found the namespace ++contextportlets++ which we reused to generate urls for our portlets. We also added a namespace for portlets since the ++viewlet++ didn't work for plone portlets. An url to a default calendar portlet will look like:

<!--#include virtual="/++contextportlets++plone.rightcolumn/++portlet++calendar" -->

Together with Whit Morriss and help from Tim Terlegård(who made lovely.remoteinclude work with Grok viewlets) we set up a buildout that will build a nginx and a varnish prepared for SSI and lovely.remoteinclude. The templates were made from a configuration provided by Lovely Systems. With this buildout and the valentine.remoteinclude enabled on a plone trunk builout we where enable to render a normal plone page where nginx assembled the calendar portlet with the rest of the page.

Tom and I couldn't figure out how to get the information from a portlet from which context the "mapping" (portlet storage) and then the portlet was fetched we where not able to generate urls for context specific portlets other then the root. This information seems to be hidden by the PortletFetcher in Plone. Ideas on how this could be solved are welcome.

With your help I think we can create a good SSI solution for Plone which would enable us to include structure and content in the page from different servers and have it assembled before sent to the user. This would be one step in the direction of using the right tool for the job and not put everything in Plone.

Technorati Tags: plone, zope, nginx, ssi, snowsprint

This is what your viewlet code could look like:

class PortalHeader(grok.ViewletManager):
    grok.name('header')

class Logo(grok.Viewlet):
    grok.viewletmanager(PortalHeader)
    grok.template('logo')

    def update(self):
        self.willBeAvailableInTemplate = 8

A template that wants to render the 'header' viewlet would include this:

<div tal:content="structure provider:header" />

I wrote a sample grok application, grokremoteinclude , to make sure the grok viewlets were compatible with other zope3 packages dealing with viewlets. It's a buildout, running it will install the grok app, nginx and varnish. Read the README.txt for instructions how to get going. The application uses SSI which allows viewlets to be either cached or retrieved from another server. The same technique can be used in Plone which was recently reported by Sasha Vincic.

Buildout.cfg:

[buildout]
parts = plone repoze zope2 instance addpath
eggs =
find-links = http://dist.repoze.org

[plone]
recipe = plone.recipe.plone

[zope2]
recipe = plone.recipe.zope2install
url = ${plone:zope2-url}

[repoze]
recipe = zc.recipe.egg
eggs =
     PasteScript
     WSGIUtils
     repoze.zope2
     deliverance
     ${plone:eggs}

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
http-port = 8080
debug-mode = on
verbose-security = on
eggs =
    ${buildout:eggs}
    ${plone:eggs}
products =
    ${plone:products}

[addpath]
recipe = z3c.recipe.runscript
update-script = addpath.py:main
install-script = addpath.py:main

This is not that different from a normal plone buildout. What's new is [repoze] which installs paste, deliverance and repoze eggs and scripts to enable wsgi.

When you want to start the instance you can either start it the old way without enabling repoze or wsgi::

  $ bin/instance fg

  $ bin/paster serve paste.ini

You need do add the paste.ini file to your buildout. The file says where it can find zope.conf, what server should run and what middleware should be in the wsgi pipeline.

Last in buildout.cfg there's an 'addpath' section, which is a little hack to come around the fact that repoze has a dependency on zopelib which is an egg with all of zope2. But here I want to use the version of zope that is officially supported for the current plone version instead of the version that comes with repoze. So addpath runs a script that adds 'parts/instance/lib/python' to the top of the egg listing in bin/paster. The result is that the compiled zope will be used instead of repoze's zopelib.

You can find a buildout with all necessary files in collective trac or collective svn.

To make repoze/wsgi easier with buildout I think we would need to make a repozpe.zope2-like package without the plone and zope dependencies that repoze.zope2 currently has. Then you could pass 'extra_paths = ${zope2:location}/lib/python' to zc.recipe.egg and the compiled zope2 would be found. That would make [addpath] obsolete. This would be a first step to ease the use of repoze in buildout.

Call or email us asap. You may send us your CV right ahead. Our office is located in Malmö, Sweden. You are more than welcome to work together with us there, but you may also work from your home or anywhere else if you like.