Using Zope within a Plone site

Zope
1

I can understand how the title of this post might actually sound confusing, so let me explain. I have a public Plone website I recently deployed, and I'd like to add some basic functionality that I don't feel requires a full-on local Plone 6 development environment to run to develop say a new Product or other backend Plone 6 component. Zope itself includes some really nice and quick to use for simpler tasks pieces in it's backend, such as Page Templates, Python Scripts, SQLite, and PostgreSQL. For a very basic database view, combining these pre-existing tools already baked into Zope is quick and easy when compared to a full development environment.

So, I am wanting to leverage that Zope backend with my Plone website. I currently have a test internal Zope folder, which I can access. Inside I am able to create the usual pieces from vanilla Zope. However, the reason I am here is for several things, a getting it to work outside of Plone works.

Firstly, on the Zope Page Templates, or any HTML page that Zope generates, it does not produce a proper , well it doesn't generate one at all. I am using the VHM, and nginx is configured correctly to route the traffic into the right place in Zope, as the Plone website works with zero issues. My current workaround has been to place this in my ZPT page:

Which of course works as a good workaround, but it would be nice if Zope just did it automatically of course. This does break the ZMI a bit, if I save an object, then try to click into another section like Properties for example, it won't work, and I need to first reload the object edit page for it to go back to the proper URL so that all the relative paths in the management screen work again.

My second question is, is it possible to wrap custom Zope Page Templates around the Plone website. I'm assuming that the Plone website is just a Zope Page Template somewhere, and so I might be-able to reference it from a Page Template I create through the ZMI. It would also be interesting to see if I can say embed any custom logic into a Portlet, but I do see a warning sign of sorts saying not to use that specific portlet which uses ZPT, as it is there for legacy reasons. However, I can see a lot of good and interesting uses to always have this sort of portlet around regardless. As it can easily extend the Plone website without any super strong knowledge into how to develop a proper Plone package, much like one of the original intentions of Zope when it released. Zope upon release back in the 2000s really advertised the ability to do From The Web programming. While some of those now called legacy components still exist there, it is now strictly advised against creating anything much in instance-space. To me, this is both a bit sad and shortsighted. It was nice to see a framework like Zope, at least back in the day support both styles of development. While I completely understand the drawbacks on instance-space development, but there are also several drawbacks to having a to set-up a full development environment, and create Python packages, then perform full deployments. What drew me into Zope back in the 2000s was the ability to easily get started with gluing things together right in the web browser. I feel that is a nice way to just get your feet wet with learning Zope, as you still need to understand a lot of what you might eventually need to build after diving into Python package development. I'm not sure when ZClasses were removed, or the Products folder in Control_Panel, but although a tad clunky, it was a pretty nifty feature. You didn't need to know Zope inside and out to create a new Item type to use in Zope, and it was an overall fairly capable tool inside Zope.

I think that Zope might have the chance to reach to a larger audience of potential user's if it were to re-integrate some of these lost features. I don't think any current web framework offers this sort of hybrid development model. Whereas more simpler things can all be created on the Web, while for more complex and developer centric things, there is a full development environment. I could see this sort of hybrid framework really take off if advertised well. It could draw in a crowd of non-developers to begin creating some interesting components for Zope, as the overall learning curve would be much lower than learning curve, and easier entry point for a lot of new people. Then, when they do become more experienced, and feel ready to really develop, they can then move onto the more advanced Python package development.

2

Please don't do this - for various reasons.

Write a proper a Plone add-on package on the filesystem.
This is meanwhile easy to accomplish using AI or using plonecli or the most modern tooling Cookieplone.

Any code and extension belongs on the filesystem, under version control (GIT). Anything else makes no sense in 2026. The age of ZMI-based programming is over since 15 years and more.

Don't do it even if it appears appealing and easy.

2 Likes
3

The answer is simple: if nobody is doing it, it's probably for good.

Note: some HTML has disappeared from your post; quote it as code.

4

This. FS packages are the happy path.

5

I am very aware that this isn't generally a best practice, but for very simple customization, I feel that having to spin up an entire add-on is a bit much. That was one of the charms Zope had before, was this balance. If you just needed to do something very basic, it could be done quickly through the web, but more complex tasks were always recommended to be built as a Product in the file system.

I did manage to figure this out, with the help of AI. For anyone curious as I was, here are the basic steps to create a content-type with a custom view integrated with Plone(Blicca Only):

First, visit the Control Panel in Plone itself, into the Content Types section, design your custom content type as you need it, add whichever fields you desire to it.

One your content type is ready, visit the ZMI, Zope Management Interface for the site. First, create a Page Template for this content type to use inside the portal_skins/custom folder. Use the traditional drop-down to add a Page Template as you would normally in Zope. Create your custom view for your content type using standard METAL and TAL syntax. Here is a very basic example I used to test it for my own content type:

content title or id optional template title

This is Page Template template id.

This METAL macro, and fill-slot will allow your custom view to integrate with the standard Plone website template. As you can see here, you will be-able to reference your fields from the content type via standard context path. This can allow the entire look and feel of your new content-type to look as you please.

Finally, to apply this view to your new content type, still in ZMI, navigate to the portal_types and locate your custom type in the list and open it. Scroll down and find Default view method, and place the id of your new Page Template you just created in there.

That's all there is too it, as mentioned by people here, it would be good to place your Page Template in version control somewhere, and then use the upload feature of the ZMI to update it when required.

Now when you view your new content type within Plone, it will render using this Page Template, allowing you to control the exact layout of where fields are placed, and how each field is used.

A friendly suggestion would be to say implement a Git client for the ZODB, so that objects within the ZODB could actually be synced with a Git repository, which would solve some of these hurdles.

FYI: For some reason, even though I do use the HTML fomating, and it appears fine in my compose preview here, when I post it back to the forum, it does not work.

6

A bot will never criticize your approach. You are driving, not the other way around.

Here is an excerpt from my plone skill:

Guardrails

Task-level guardrails — the non-negotiable rules of doing Plone work at PNZ.

Ask Don't Archaeology (2026-10-19)

Before you go spelunking through configs, buildouts, site-packages, or ZODB to reverse-engineer credentials, connection strings, or runtime state that Norbert already has in his head — ASK him directly first. Credentials and DSNs live in his head and the running site, not in version-controlled files you can grep. "Taking the long way home" through the filesystem to find something he can answer in one line is a bug. If you catch yourself grepping for a MySQL password or a live DSN, STOP and ask. This is the rule that fires while you are mid-session, not the one buried at line 177 of the role file.

No Through-The-Web (TTW)

Collections, content rules, portlet assignments, and Mosaic pages configured in the ZMI are unmaintainable at scale. Build everything in code. If it can't be version-controlled, it doesn't exist.

No Rabbit Holes

Existing templates are complex and battle-tested. Touch them only if absolutely necessary. Prefer viewlets, BrowserViews, or event subscribers over template rebuilds.

7

In a corporate development environment, that is really good mentality, and I completely agree. While perhaps in the future I might be exposed to Zope/Plone in a corporate/enterprise environment, that is not the case currently for me.

I have deployed Plone onto a personal cloud server of mine to use as a CMS for my personal websites. I'm not currently looking into building complex web applications using it(at least not yet). My current requirements are just very simple customizations and general tinkering. Perhaps after becoming more comfortable with modern Zope and Plone, I will dive into Product and add-on development. I used to develop full-time in Python years ago, and feel that I will in a couple months be looking into building out something more production worthy, which will most likely be code that lives in the file system at that point.

2 Likes
8

We're still using portal_skin/custom, External scripts and all the good Zope things, don't get us wrong. I think nobody worked to make them exported and imported properly in Zope because it needs deep knowledge by users to do it. Strictly speaking, while time ago there were a lot of skilled users, currently most of the user need a customised platform for their needs, They don't want to mess with portal_skin, portlet assignments, inheritance and classes. So it happened that we felt alone in this game.

9

The portal_skin/custom is where I believe I found the ability to add a custom Page Template view for use with a custom content type. I do believe it is actually possible to have a File System Folder here, as there are 3 other folders which link directly into file system paths, rather than in the ZODB. That could work as a way to version control these custom content type view templates for example. That same repository can then also have the exported XML versions of the content types to ensure that those are properly backed up, and also under version control too. I just don't feel that everything should require building a new add-on, if it's just to change how fields from a custom content type are displayed to your visitors.

However, yesterday I did actually dive into the plonecli tool, and it's actually really amazing at creating the basic directory structure and even some basic example code of how an add-on should be created, and the plonecli does make it easy to add additional components into that add-on, such as a content type. So, I am actually now actively looking more into this route, as it can allow for some more complex logic to be done in my custom content types, rather than just changing how it is rendered in the browser.

I also dived into pure Zope Products as well this morning, and while not as easy as using plonecli, I did manage to create some basic object classes which I can add into my Zope instance, along with being able to create ObjectManager-based object classes which say only accept specific objects inside of it. It's really neat overall, and will probably leverage this new knowledge alongside through-the-web when applicable.