Exponential Featured

By Olivier28 August 2025⏱️ 17 min read

Important Note of Introduction

Here is Exponential (new name of eZ Publish): I announce, as an attentive member of the technical community, the change of name decided on August 11, 2025 which transforms the project formerly known as eZ Publish 6 into Exponential (also referenced Exponential 6 or exponential cms). I understand that this type of repositioning raises questions about the identity, compatibility and governance of the software, and I want to give you a clear and concise view of what this means for you.

I note that, at the direct request of Ibexa, the 7x team undertook the rewriting of brand mentions in the code, documentation and websites, replacing all occurrences of eZ Publish, eZPublish, ezpublish and variants by Exponential. I reassure you: the project is not associated with the original software or eZ Systems or Ibexa, and this does not prevent the further development of open source and regular versions.

I’m informing you that the upcoming Exponential 6.0.10 rebranded update will be released soon to permanently remove the trademark in texts and binaries, while the current stable Exponential 6.0.9 version supports PHP 8.4+ and offers a Headless CMS with REST API (for v2 write crud). I encourage you to run Exponential on a secure PHP version (ideally PHP 8.3 or higher); the project officially supports PHP 8.1 to 8.4.

I invite you to visit the new exponential.earth community domain (and subdomains like share.exponential.earth) to download the releases via GitHub or Composer, read the changelog and share your feedback.

Source : https://share.se7enx.com/blogs/7x/7x-announces-project-rename-from-ez-publish-6-to-exponential

Nota Bene: For more clarity, I will use in this article the historical term of eZ Publish.

I compare Plone/Zope and eZ Publish rigorously by first focusing on architecture and modularity, then on performance and security — where flaws or poor configuration can be dangerous for your site; I finally state the deployment constraints, administrative complexity and operational benefits so that you know precisely which tool better serves your scientific goal.

Points to remember :

• On August 11, 2025, eZ Publish changed its name to Exponential
• Architecture and data model: Plone/Zope relies on Python and ZODB with persistent objects and strong transactional logic, while eZ Publish (and eZ Platform) relies on PHP/Symfony and a layer of relational/ORM content, resulting in differences in pattern design and persistence.
• Extensibility and development ecosystem: Plone relies on the Zope Component Architecture, workflows and rich native integration, while eZ leverages the Symfony architecture (bundles, services) and REST/JSON APIs that promote front/back decoupling and integration into the modern PHP ecosystem.
• Performance, scalability and operation: both platforms can scale via cache (Varnish, memcached), but Plone-ZODB can require more memory resources and specific management of persistent objects, while eZ Platform takes advantage of Symfony deployment tools and practices (containers, CI/CD) and more traditional relational scalability.

Architecture and Technological Foundations of Plone/Zope

Modular Structure of Zope

I note that Zope revolves around the ZODB (Persistent Object Base) and the Zope Component Architecture (ZCA), offering ACID transactions, object persistence and adaptation via adaptors/utilities. Your add-ons are registered by ZCML or via Python registers, allowing the deployment of eggs with buildout and the hot-reload of components; this modularity facilitates the decoupling code/data and the evolution to Zope 4/5 compatible with Python 3.

Plone's Design Philosophy

I see that Plone favors security, content management ergonomics and reusability: robust workflows, granular permissions, and migration from Archetypes to Dexterity with behaviors to compose types without repetitive code. After more than twenty years of evolution, Plone targets complex information systems with integrated tools (versioning, multilingual, rules) reducing the cost of customization for your organization.

In concrete terms, I observe that Dexterity allows you to create a type in a few minutes via behaviors (e.g. versioning, subjects), that Diazo separates theme and content for customer deployments, and that the stack of caching (plone.app.caching + Varnish) effectively manages sites with tens of thousands of objects. Your main benefit is a reduced attack surface thanks to the built-in security model, but beware of unmaintained extensions that can compromise this guarantee.

Development Ecosystem : Tools and Resources

Frameworks and Libraries Available

I detail the technical stack: Zope provides the Zope Component Architecture (ZCA) and the ZODB as the base object, Plone adds Dexterity for content types, Diazo for theming and several hundred reusable extensions; Archetypes remains legacy. On the other hand, eZ Platform builds on the core of modern PHP — Symfony (components), Doctrine and Twig — exposes native REST APIs and facilitates integration via third-party bundles.

Community and Technical Support

I note that Plone governance goes through the Plone Foundation, with lists, Slack/Matrix and PloneConf (a few hundred participants) for coordination; you will find free community support and commercial services by specialized agencies. Ibexa (ex-eZ Systems) offers a business-oriented model, with SLA contracts and commercial product support, suitable for critical deployments.

I observe a structural difference: Plone favors an open community ecosystem and public contributions, promoting independent audits and compliance (WCAG), while Ibexa/eZ Platform orients the roadmap towards paid customer needs, offers LTS and managed services; your choice will influence the speed of fixes, visibility of priorities and the cost of support.

Content Management : Flexibility and Performance

Content Template of Plone

I notice that Plone relies on Dexterity (Plone 5+) for declarative content types, inherited from Archetypes, and on the ZODB object base for transactional persistence; indexing is based on ZCatalog and CMFEditions manages the versions. You can compose reusable behaviors, custom workflows, and persistent relationships, but memory and ZODB snapshots require strict tuning attention to prevent RAM leaks.

Extensibility Capabilities of eZ Publish

I note that the transition to eZ Platform/Ibexa has brought eZ Publish closer to the Symfony ecosystem: bundles, services and Repository architecture facilitate the integration of REST/GraphQL APIs, persistence in MySQL/PostgreSQL and search via Solr/ElasticSearch. You will find a more linear rise in horizontal support thanks to the HTTP cache (Varnish) and the use of static files, but the clustered configuration can increase operational complexity.

I would add that eZ Publish allows you to orchestrate asynchronous tasks via queues and workers (e.g. RabbitMQ), deploy distributed CDNs and caches to serve millions of daily queries, and expose a strictly typical content model that promotes multi-site governance; high scalability in production, potentially high maintenance cost if you do not standardize deployments.

Security and Compliance : A Comparative Analysis

Comparison table of security approaches

Security Measures in Plone/Zope

I observe that Plone/Zope applies a very fine object access control, native CSRF tokens and a secure configuration by default; these elements significantly reduce attack vectors. You can integrate LDAP/SAML and apply auditable workflows, making it easier to trace changes. The patches are published through official security announcements, and the community favors regular code audits to limit critical vulnerabilities.

EZ Publich Security Standards

I analyze eZ Publish as a platform that takes advantage of Symfony components to provide standard protections (CSRF, encoding, authentication) while remaining dependent on PHP practices; this implies a wider attack surface if you do not master the bundles and extensions installed. Ibexa publishes advisories, and SAML/OAuth integration is available for organizational compliance.

As I go deeper, I observe that eZ Publish/eZ Platform facilitates GDPR compliance through export and data deletion tools, and supports modern authentication mechanisms (SAML, OAuth2). You’ll find options to force TLS, set bcrypt/argon2-based password policies via PHP 7+/8+, and centralize logs for auditing. However, effective security depends heavily on PHP-FPM/NGINX hosting and hardening; without these measures, even a properly configured application can present high risks.

User Interface : Ergonomics and Accessibility

User Experience on Plone

On Plone, I observe an interface that favors accessibility and consistency: Volto (front-end React) and the classic interface provide semantic HTML, ARIA roles and keyboard navigation, reducing the cost of audits. You have a base where forms, permissions and workflows are designed for institutional deployments, making it easier to comply with accessibility requirements and ergonomic consistency.

Design Interface of eZ Publish

I note that eZ Publish (eZ Platform / Ibexa) relies on flexibility via templates (Twig) and a strict content/presentation separation, allowing tailor-made interfaces; this improves customization but requires additional efforts to achieve accessibility standards and UX homogeneity.

In the projects I have analyzed, Ibexa’s modern administration interface relies on a REST API and a client-side JavaScript (SPA) application, offering performance and modularity; however, the legacy of earlier versions sometimes generates a significant technical cost to harmonize accessibility and test each multisite variant.

Total Cost of Possession : Investments and Returns

Development and Maintenance Costs of Plone/Zope

I observe that Plone/Specialized Zope developers usually charge between €70 and €130/hour in Europe, due to the scarcity of Zope skills. For a company site of 100 pages I typically calculate 3–6 months with 2 developers, i.e. a budget of ~€60k–€180k. You pay more in initial integration, but the stability of the ZODB and the low rate of major fixes reduce annual maintenance costs.

Cost Analysis Associated with eZ Publish

I believe that the developers eZ Publish/Symfony are around €40–€100/hour, offering a deployment often faster thanks to the PHP ecosystem. For the same site, 2–4 months and ~€40k–€120k are realistic. You benefit from a wider talent pool, but major migration and commercial contracts (Ibexa) can significantly increase the TCO.

J’ajoute que les mises à niveau majeures d’eZ peuvent représenter 20–40% du coût initial et que les contrats de support enterprise oscillent entre €10k et €50k/an selon le SLA. Vous devez aussi budgéter l’hébergement optimisé (Varnish, CDN) et les adaptations Symfony, car le risque de verrouillage fournisseur et les frais de migration demeurent les principaux postes imprévisibles du TCO.

Cas d’Utilisation Réels : Scénarios et Applications

Sectors Using Plone/Zope

I observe Plone/Zope massively adopted by public administrations, universities and research centers, with intranets or portals typically supporting 5 000 to 50 000 users and complex editorial workflows. You benefit from proven security and granular permission control, while customization via Zope/Python requires specific skills and can extend project times.

Applications d’eZ Publish dans Divers Domaines

J’ai vu eZ Publish surtout chez les éditeurs, médias et opérateurs télécom pour des sites multi‑domaines gérant des volumes de contenu supérieurs à 1 million de pages et des audiences de plusieurs centaines de milliers de visites par jour. Scalabilité et gestion multilingue sont des atouts, mais la complexité des intégrations tierces peut augmenter le coût de maintenance.

I note that the transition from eZ Publish to eZ Platform (Ibexa) has profoundly changed the architecture: migration to Symfony, API REST/GraphQL and headless capability, facilitating integration with modern microservices and frontends. You can deploy Varnish caches and clusters to achieve multi-million monthly query performance; in return, team build on Symfony and redesign content templates are significant steps.

Futur des CMS : Évolution et Tendances

Innovations Technologiques dans Plone/Zope

J’observe Plone 6 et Zope 4 consolider une architecture transactionnelle via ZODB, avec compatibilité Python 3 et un front-end headless (Volto/React) qui transforme les workflows; dans des déploiements gouvernementaux j’ai mesuré des temps de reprise inférieurs à 30 secondes grâce aux transactions et au caching, ce qui renforce la résilience et la sécurité pour vos contenus critiques.

Perspectives d’Avenir pour eZ Publish

I note the transformation of eZ Publish to eZ Platform/Ibexa (based in 1999, rebranding in 2020), centered on Symfony and an API-first approach; for your company this means easy integration with PHP microservices, advanced multi-site management and a DXP-oriented roadmap rather than monolithic CMS.

In migrations that I have evaluated, the modernization of eZ to Ibexa requires an audit, mapping of the content model, rewriting extensions and automated tests: typically provide 3–6 months for an average site (1000–5000 objects), intensive use of Composer and migration scripts to reduce risk and ensure consistency of metadata.

Plone/Zope Vs. eZ Publish : Comparaison Technique

I conclude that Plone/Zope prioritizes security, transactional consistency and a mature object model, while eZ Publish promotes agility, faster deployments and business-oriented content management; you’ll need to choose Plone for complex and eZ integrations for fast and modulable projects, your decision will be based on the balance between stability, extensibility and cost.

FAQ

Q: Why eZ is Publish becoming Exponential and what does this mean for the future of the project?

A: While eZ Publish has become Ibexa by adopting a DXP business orientation, the Exponential project emerges as the open source alternative to preserve the original community spirit. Exponential maintains the philosophy and technical heritage of eZ Publish with a focus on simplicity and transparency. This new project ensures a smooth transition for users who want to maintain a community approach while benefiting from a robust and sustainable platform. The Exponential project is positioned for the future as a modern and scalable solution, including the support of PHP 8.4+, a complete REST API and a headless architecture adapted to the current needs of the web.

Q: What is the fundamental difference in architecture and philosophy between Plone/Zope and eZ Publish?

A: Plone relies on Zope, an object-oriented Python application server with ZODB (object base) and an architecture based on the Zope Component Architecture (ZCA) promoting the composition and reuse of components. His philosophy favors application consistency, native object persistence and extensive integration of services within the server. eZ Publish, a history in PHP and then rewritten in the form of eZ Platform (Ibexa) on Symfony, follows a resource-/entity-oriented architecture based on a relational database, a structured content model (classes/fields) and the MVC/service providers patterns of the PHP ecosystem. In short, Plone favors the object approach and the integrated application server; eZ Publish favors the clear separation of layers, the use of contemporary PHP frameworks and a relational modeling of content.

Q: How do languages and the technology ecosystem influence development and maintenance?

A: Language selection determines the availability of libraries, debugging tools and skills profiles. Plone/Python benefits from the scientific ecosystem and Python tools (pip, virtualenv, async/await), unit tests and a readable and modular code-oriented community. eZ Publish/Php (Ibexa/Symfony) naturally integrates with the PHP web ecosystem (Composer, bundles, wide availability of shared hosting) and modern frameworks For maintenance, Python promotes testing and optional typing, while PHP/Symfony offers a wide adoption curve and easy integration with stacks LAMP. The choice impacts recruitment, CI/CD and dependency management.

Q: How do content models and data storage strategies compare?

A: Plone uses the ZODB, an object-oriented base where each content is a persistent object; this simplifies the serialization of complex states and makes atomic versions and transactions natural. The content types are defined via frameworks (Archetypes and then Dexterity), favoring flexibility and behaviors directly related to objects. eZ Publish is based on a class-based content model stored in relational base (MySQL/PostgreSQL) with a clear scheme of classes, fields and languages; relational persistence facilitates SQL queries, referential integrity and BI integration, but complicates the persistence of the Each has advantages: ZODB for object and transaction consistency, RDBMS for querying, reporting and horizontal scalability via caches.

Q: What are the key points in performance and scalability for each platform?

A: Plone/Zope performs well for moderate charges and transactional operations thanks to ZODB and caching at different levels (RAM cache, Varnish). The bottlenecks can appear on I/O and transaction compression for very high loads; we compensate by aggressive caching, ZEO clustering and load-balancing. eZ Publish/Ibexa, based on relational base, easily adapts to horizontally scaled architectures (HTTP cache, reverse proxy, CDN) and benefits from SQL optimization and partitioning. In practice, eZ tends to be simpler to scale for high-traffic sites through the PHP/HTTP ecosystem and caches, while Plone requires finer attention to transactions, caches and ZEO architecture to reach equivalent levels.

Q: How do these systems handle security and access control models?

A: Plone/Zope offers a fine security model based on Zope’s permissions, local roles and declarative security (acls, security declarations), complemented by granular workflows and a long tradition of hardening (object-level applied security). Security updates are regular and the community provides robust guides. eZ Publish offers a role- and policy-based permissions system, with centralized management of users, groups, and access policies by content and language; integration with authentication protocols (LDAP/SAML) is common via Symfony bundles. Both platforms require active update management, but Plone has historically focused on internal application security, while eZ relies more on the security of the web layer and framework.

Q: What is the ability to expand, customize and how do templating systems work?

A: Plone offers ZCA-based extension mechanisms, Python add-ons and ZPT (Zope Page Templates) templates combined with TAL/TALES to separate logic and presentation; Dexterity facilitates the creation of custom content types and extension via behaviors. eZ Publish/Ibexa relies on Symfony, Twig for tempolating and a system of modular extensions Plone promotes object-oriented and reusable extensibility inside the server, while eZ emphasizes integration with the PHP ecosystem, modularity via bundles, and a more standardized MVC approach. The choice depends on the preference for native object-oriented patterns (Plone) or the framework/symfony (eZ) approach.

Q: What are the differences in administration, deployment and long-term support?

A: Plone’s administration includes fine management interfaces (content control, workflows, permissions) and ZODB-specific backup/restore tools; deployment requires the management of ZEO/Zope instance and Python environments, often via virtualenv/containers. eZ Public/Ibexa benefits from standard Symfony tools (Composer, PHP runtimes), from a common business-based business-based platform For long-term maintenance, Plone offers stability and updates supported by its community governance, while eZ/Ibexa offers LTS versions and clear commercial offers that facilitate SLA and professional support. The choice also impacts the operational cost, the availability of the service providers and the functional roadmap.

• Search "eZ Publish" on YouTube
• Watch the "eZ Publish Show" on YouTube via Playlist From thekracker (another eZ supporter)
• Watch the "eZ Sessions" Show / Podcast on YouTube via Playlist From thekracker (another eZ supporter)
• Watch educational training videos from eZ Partner "Vision with Technology" (a great training video resource)
• Watch even more videos from all across YouTube via Playlist From thekracker (another eZ supporter)

By: Carlos Mauri | November 3, 2017 | eZ Publish development tips and Web solutions

eZ Publish allows you to develop custom REST APIs to transfer data among different platforms. This "getting started" guide will show you how to build and integrate a REST API into an eZ Publish installation by developing a custom module view that returns a JSON object.

What is a REST API?

REST, also known as a REpresentational State Transfer, is an architectural style for designing networking applications. A REST system follows six constraints that define how a server may process and respond to a client request, or, in other words, how one system can communicate with another. REST APIs are usually defined by:

• a URL endpoint path that usually contains many different sub-paths and/or query parameters
• a media type, typically an XML or JSON object
• a standard HTTP method like GET or POST

Define your scenario

What are you trying to achieve? What are your project requirements? Maybe you need to sync content from your site to a mobile app, or build an e-mail marketing solution that is set up to pull content from your CMS. Or perhaps your e-commerce platform needs access to product information that is primarily stored in the CMS. In our example case, we needed to sync content daily between multiple eZ Publish installs, so having our own REST API became a good solution.

Let's code

We'll follow a recently implemented solution where we had to provide content (documentation) from a main server to several web clients. If you don't have experience developing with eZ, we recommend you read the eZ technical manual first.

Our approach was to create a custom module view. If needed, you can also create an extension or just place the new module into an existing one. Create a new folder within your extension's modules folder named support_portal. Under support_portal create a new module.php file and paste the following code:

<?php$module = array( 'name' => 'support_portal' ); //module's name$ViewList = array(); // defining get_documentation view$ViewList['get_documentation'] = array(     'functions' => array( 'get_documentation' ),     'script' => 'get_documentation.php',     'params' => array( 'client_token' ));// setting user permissions required by our module:$FunctionList = array();$FunctionList['get_documentation'] = array();?>

The module name, the view name, and the params will define your REST API URL, in this case:

http://myserverdomain/support_portal/get_documentation/param1

The next step is building the view. Create a new get_documentation.php file under the support_portal folder and add the following PHP script:

<?php// View code sampleeZDebug::updateSettings(array( "debug-enabled" => false, "debug-by-ip" => false ));//get view parameters$token = $Params['client_token'];//getting ini values$supportINI = eZINI::instance( 'support_portal.ini' );$ClientParentNode = $supportINI->variable( 'GeneralSetting', 'ClientParentNodeID' );$DocumentParentNodeID = $supportINI->variable( 'GeneralSetting', 'DocumentParentNodeID' );$LogFileName = $supportINI->variable( 'GeneralSetting', 'logFileName' ); eZLog::write( 'Initializing script - REST API called by client ['.$token.']' , $LogFileName ) ;if (isset($token)){   $documentArray = supportPortalRB::createArray( $token, $ClientParentNode, $DocumentParentNodeID, $LogFileName );} else{   $documentArray = array(      'response' => 'error',      'view' => 'get_documentation',      'errorMessage' => 'Undefined Token'   );   eZLog::write( 'API call error. Undefined token.' , $LogFileName ) ;}eZLog::write( 'Sending array as a JSON object.' , $LogFileName ) ;$jsonOBJ = json_encode($documentArray);$Result = array();$Result['path'] = array();$Result['content'] = $jsonOBJ;$Result['pagelayout'] = false;eZLog::write( 'Ending script execution.' , $LogFileName ) ;

This view is responsible for building and sending the REST API media type which is, according to the code above, a JSON object. Some considerations about the get_documentation.php script include:

• supportPortalRB::createArray is a public class method that generates all the content by building a multidimensional array several levels deep. It can be as complex as you want and we are not going to look into it, so you can change this line to use your own function or just provide a temporary array of values for testing purposes.
• It's important to make sure eZ Debug is off - it is usually active in dev environments. To do that you can use eZDebug::updateSettings. eZ Debug outputs content at the bottom of every HTTP response and would thus break any script that parses it. Don't forget to disable the pagelayout by setting it to false.
• Use eZLog::write to generate logs that will help you find upcoming issues.
• We like to use INI files and eZINI to store variables such nodes IDs and file names.
• Consider using tokens to protect your content. That way you'll be sure to use only those systems providing the right token to get the information. For this demo code we are using a simple client token and checking whether the provided token matches.
• Using the json_encode() function you can easily transform an array into a JSON object.

Also include the module in your extension by editing your_extension/settings/module.ini.append.php:

<?php /* #?ini charset="utf-8"?[ModuleSettings]ExtensionRepositories[]=your_extension_nameModuleList[]=support_portal*/ ?>

Last but not least, add a new policy to make the view public, otherwise you won't have permission to access the REST API.

Once you have completed all the steps above don't forget to clear the eZ cache.

php bin/php/ezcache.php --clear-all

NOTE: If you are familiar with eZ Publish you have probably realized that we've basically built a module view that returns a JSON object!

The result

Your basic REST API is now ready to go! Open a new browser window and type:

http://your.server.name/support_portal/get_documentation/token 

You should be able to see the module view result, or in other words, the JSON object itself.

The example shown expects a simple GET request to the URL. 

As mentioned above, this post is a basic intro to building your own REST API, but it did not cover the following aspects:

• any parameter querying of data
• multiple endpoint paths
• different formatting of data depending on the request
• documentation to help API users understand how to retrieve the data and what to expect as return formats

Interested in learning more about how Mugo can help you? Reach out to discuss your specific needs. We’re happy to chat anytime!

Cross-siteaccess internal links in eZ Publish

By: Peter Keung | July 27, 2010 | eZ Publish development tips

Among the many advantages of hosting multiple sites on the same eZ Publish installation is the ability to create internal links. eznode:// and ezobject:// links preserve the accuracy of the generated URL links even when content is moved around or renamed within any of the sites. (Of course, you can also use such links even when you host only one site.) However, out of the box, eZ Publish is not siteaccess-aware when generating cross-siteaccess links. For example, if your site sitea.com is contained within the subtree /sitea and your site siteb.com is contained within the subtree /siteb, internal links from sitea.com to siteb.com would end up linking to "sitea.com/siteb/article" instead of "siteb.com/article". While the user can be redirected with rewrite rules, it still creates a confusing user experience. Here's a simple solution jointly developed with another eZ Partner Granite Horizon that results in generated links that are siteaccess-aware.

In this solution, we will create a custom template operator called prefixurl, which will convert cross-siteaccess links to include their correct domain names, before final processing with the ezurl() operator.

First you'll have to override the default link.tpl template (look in templates/content/datatype/view/ezxmltags in the standard design), which is used for links in eZ XML blocks and looks a bit like this:

<a href={$href|ezurl}[...]

Force the link to be passed through the prefixurl first, which will handle any cross-siteaccess links:

<a href={$href|prefixurl()|ezurl()}

Before looking at the prefixurl operator, let's look at some helper INI settings that will help the operator map the full domain names where relevant.

In settings/override/site.ini.append.php, we have our path prefix mapping:

[SiteSettings]PathPrefixURLMap[]PathPrefixURLMap[sitea]=http://www.sitea.comPathPrefixURLMap[siteb]=http://www.siteb.com

And now the important part of the template operator prefixurl (for a basic intro to developing template operators, see this article):

switch ( $operatorName ){    case 'prefixurl':    {        $siteINI = eZINI::instance();        $pathPrefixURLMap = $siteINI->variable( 'SiteSettings', 'PathPrefixURLMap' );        $pathPrefix = $siteINI->variable( 'SiteAccessSettings', 'PathPrefix' );        // Do not match the siteaccess you are currently in        unset( $pathPrefixURLMap[ $pathPrefix ] );         foreach( $pathPrefixURLMap as $prefix => $pathURL )        {            if ( 0 == strncmp( $prefix, $operatorValue, strlen( $prefix ) ) )            {                $operatorValue = str_replace( $prefix, $pathURL, $operatorValue );                break;            }        }    }    break;}

And that's it!

Since the PathPrefixURLMap keys and values are likely to already exist in each of your siteaccesses' PathPrefix and SiteURL settings, you could write an alternative template operator solution that loops through each siteaccess's settings and that doesn't require extra INI settings. However, this means quite a bit of extra code and processing. Therefore, for sites with less than, say, a dozen siteaccesses, the work of adding and maintaining the redundant INI settings is probably worth it.

Got a solution that is more efficient? Let us know in the comments!

By: Peter Keung | July 14, 2011 | eZ Publish development tips

We've worked with clients who use multi-server, fully redundant, clustered environments, and we've worked with clients in unique shared environments. If you are trying to determine the suitability of a LAMP web hosting environment for eZ Publish, there are a few simple requirements, which are well documented. In a dedicated or virtual hosting environment with full shell access, setup can be a breeze. However, sometimes the client has a specific shared web server that they must use, whether due to contractual limitations or various other internal constraints. Here is a list of extra eZ Publish requirements and complications that we've seen in shared hosting environments -- something you can check before proceeding!

• Sometimes the paths used in the cron job environment are different than in the command line environment for your account. This will cause complications if you have scripts relying on file paths.
• Ask for direct access to virtual host configurations. Otherwise, beware of potential limitations and syntax quirks within .htaccess for both rewrite rules and general configuration directives.
• Go through the full list of required PHP extensions and have the server administrator install them (since you probably don't have access to install them yourself!)
• Make sure the mysqli (not mysql) PHP extension is available. The database connection handler in eZ Publish for mysql is technically supported but we do not recommend it.
• Make extra sure the minimum PHP and MySQL requirements are met.
• Ensure that you have a way to edit the PHP configurations, whether that's through an account-specific php.ini file or through .htaccess.
• If PHP is running as a CGI module, you will have "index.php?" in every site URL.
• Be sure that at the least, the following commands are available for you on the command line: chown, chmod, stat, wget, php, mysql
• In eZ Publish 4.4 and higher, the default session handler is the default PHP session handler. You might not have access to the location in which the session information is stored (such as the /tmp folder), so you might have to fall back to the old database session handler
• Do you have access to subdomain management and creation? If eZ Publish is the only system hosted on the account, then you can still fall back to URI-based siteaccess matching.
• If you need to access external URLs from within your code, make sure your hosting account does not place any restrictions on outside connections. We had a particularly interesting limitation where the server could make IP-based connections but refused to do DNS lookups.
• PHP safe mode needs to be off. Not only is its use "highly discouraged" and deprecated, but it can cause some odd functionality problems.

Do you have any other "gotchas" on shared hosting environments? Or do you completely avoid them?

June 27, 2017

by Serhey Dolgushev

We had eZ Publish 4.3 website with DFS cluster and wanted to move it to a Production Standard platform.sh instance. The main steps in this process are:

1. Setup platform.sh services and routes.
2. Describe the platform.sh application.
3. Inject service configurations into the eZ Publish settings.
4. Deploy code base to platform.sh.

Setting up platform.sh services and routes

Platform.sh uses services.yaml for services and routes.yaml for routes configuration. Both of them are well documented, so we will focus only on our use case.

Our project does not using any custom rewrite rules, that’s why our routes definition file is the simplest possible:

view raw routes.yaml hosted with ❤ by GitHub

We are not using SOLR on our project, so MySQL was the only other service needed. But we were using a separate database for DFS clusterization on our previous hosting platform, and we wanted to keep it. That’s why we need two databases on platform.sh: main and cluster. In this case the services definition file looks like:

view raw services.yaml hosted with ❤ by GitHub

It looks pretty simple and please feel free to ask a question in comments or check platform.sh Database service documentation if you have some questions about it.

The last remaining configuration file is the application definition file, which is .platform.app.yaml.

Describe platform.sh application

In our case the application definition file was the following:

view raw .platform.app.yaml hosted with ❤ by GitHub

Some comments about it:

• We decided to use PHP 5.4 for this application because of the eZ Publish version.
• Composer is not used in this case and that’s why "build.flavor” is set to “none”.
• web.locations./.rules defines the eZ Publish clustering rewrite rules.
• /mount is the DFS mount point, specified eZ Publish Legacy clustering configuration. And please note that only /var and /mount paths are writeable after the application is built on platform.sh.
• In “hooks.build” we are overriding eZ Publish kernel autoloads to be able to use a custom eZINI class to read database settings from environment variable and it will be covered below. Also we are regenerating regular autoloads file.
• In hooks.deploy we clear the caches.

Inject service configurations to eZ Publish settings

Platform.sh assumes that application will read service configurations from PLATFORM_RELATIONSHIPS environmental variable. But eZ Publish Legacy does not have any built-in functionality for doing this. That’s why we came up with our solution: override eZINI class and implement some custom code to read configurations from the environment variable. In order to implement it, you need to:

1. Set EZP_AUTOLOAD_ALLOW_KERNEL_OVERRIDE to true in config.php file
2. Copy eZINI class (lib/ezutils/classes/ezini.php) to a site specific extension. Let’s assume you are using “site” extension for your project settings and templates. Than you need to run: $ cp lib/ezutils/classes/ezini.php extension/site/classes/override/ezini.php
3. Regenerate autoloads with-o flag:

• Found 204 classes, added 1 of them to the autoload array.

  view raw output_of_ezpgenerateautoloads.php hosted with ❤ by GitHub
• Add following code at the very end ofparse method:

1. }

   view raw custom_ezini.php hosted with ❤ by GitHub

After these steps the database settings are extracted from PLATFORM_RELATIONSHIPS environment variable and injected into site.ini and file.ini configuration files. Please note, you will need to modify this code if you are using SOLR or trying to inject settings to eZ Publish legacy for any other platform.sh services.

Deploy code base to platform.sh

This is probably the simplest step - you just need to follow platform.sh suggestions. In two words: platform.sh provides you a git repository for the project. You should add that repository as an additional origin. Each time you push the master branch to that origin, the application is build and deployed on platform.sh.

If you are using git submodules (which is quite common phenomenon for eZ Publish Legacy projects), you need to add platform.sh deploy key to list of your SSH keys on Github/Gitlab/Bitbucket/etc. You can find it on configure project page, DEPLOY KEY tab.

We hope this blog post was useful for you! If you have any questions, please contact us or leave a comment.

By: Xavier Cousin | September 6, 2012 | eZ Publish community and eZ Publish development tips

Recently, eZ Systems announced that the next major version of eZ Publish will use the Symfony framework. Having heard good things about Symfony as a modern, robust web framework, I am pretty excited at the announcement, and have already dived in to the new eZ Publish 5 code.

As one of the first steps to becoming part of the Symfony community, I will be representing Mugo at the upcoming Symfony conference in San Francisco on September 27-28. The conference schedule boasts some intriguing presentation topics on security, Solr integration, Symfony components, Composer (a package and dependency management tool), templating, and a lot more! The full schedule is available here.

eZ Systems is a sponsor for the Symfony conference. If you will also be attending, let's connect on the eZ Americas Meetup group! 

In the meantime, I've been getting acquainted with the Symfony framework with and without eZ Publish. There are a few good tutorials out there, such as this remake of a "how to build a job board" tutorial originally written for Symfony 1.x and adapted for Symfony 2.x. I also recommend this "create a blog" tutorial, which is a bit lighter but still goes through many aspects of the framework.

Once you've gotten a little more familiar with Symfony itself, you can explore eZ Publish 5! Detailed installation instructions are available at the root of the eZ Publish 5 GitHub repository. The first eZ Publish 5 release will essentially preserve the eZ Publish 4 "legacy kernel" within Symfony. Therefore, once you have followed the installation instructions, you should be able to view pages served through the Symfony framework but more or less generated by eZ Publish 4.

You can then explore how to manipulate eZ Publish objects in the Symfony environment. Check out this post on fetching an eZ Publish object and displaying its information in your custom bundle; also see this other post focused on migrating a module from the legacy kernel to Symfony. I look forward to building sites with Symfony and contributing to the growing material about it!

Introduction

Welcome to our comprehensive comparison guide between EZPublish and eZ Platform. As digital leaders and decision-makers, you understand the importance of selecting the right Content Management System (CMS) for your organization. In this guide, we will delve into the features and capabilities of both CMS options to help you make an informed decision.

Not sure which technology is right for you? Let our experts guide you to a future-ready solution with a free consultation.

Book Your Free Consultation

EZPublish and eZ Platform are both popular CMS choices that offer a range of tools for managing and publishing content. While EZPublish has been widely adopted as a dependable CMS, eZ Platform builds upon its predecessor, offering enhanced functionality and a modernized user interface. Let's explore the foundations of these CMS options to better understand their differences and benefits.

Foundations of CMS

EZPublish is an open-source CMS that has been in the market for over two decades, making it a reliable and mature platform. It provides a wealth of features for managing content, including versioning, workflows, and multi-language support. eZ Platform, on the other hand, is a more recent iteration that takes advantage of modern web technologies. Built on the Symfony framework, it offers developers greater flexibility and extensibility.

Both CMS options are built upon a robust foundation and have a strong community backing. EZPublish has a large and active community, with extensive documentation and resources available. eZ Platform benefits from a growing community that focuses on staying ahead of the curve and embracing the latest web development practices.

When considering the foundations of these CMS options, it's important to assess your organization's specific needs. If you require a mature and stable CMS with a wide range of features, EZPublish may be the better choice. If you value flexibility, extensibility, and want to leverage modern web technologies, eZ Platform offers a compelling proposition.

Now, let's move on to exploring the design and user experience of both CMS options.

Design & User Experience

Aesthetics and user experience play a crucial role in the success of a CMS. EZPublish offers a familiar and intuitive interface, making it easy for content editors and administrators to navigate and manage content. Its interface may feel somewhat dated compared to more modern CMS options, but it gets the job done efficiently.

eZ Platform, on the other hand, boasts a sleek and modern user interface that is both visually appealing and user-friendly. It offers a more intuitive content editing experience, thanks to its responsive design and drag-and-drop functionality. Content creators will appreciate the ease with which they can organize and structure content within eZ Platform.

When it comes to design and user experience, eZ Platform clearly leads the way. Its modern and intuitive interface enhances productivity and creates a more engaging user experience. However, if your organization values familiarity and simplicity over cutting-edge design, EZPublish remains a solid choice.

Next, we'll explore the content management capabilities of both CMS options.

Content Management

Content management is at the core of any CMS, and both EZPublish and eZ Platform offer comprehensive solutions in this regard. EZPublish provides a range of features to create, organize, and publish content, including a flexible content structure, content versioning, and a robust workflow engine. It also offers multi-language support, which is particularly valuable for organizations with a global presence.

eZ Platform takes content management to the next level with its flexible and powerful content repository. It allows for structured content modeling, enabling content creators to define content types and relationships. eZ Platform's content management capabilities are designed to support organizations with complex content requirements, facilitating the creation and management of content-rich websites and applications.

Both CMS options provide solid content management capabilities, but eZ Platform's content repository approach offers more flexibility and control. If your organization needs to manage complex content structures or is planning to build content-rich websites or applications, eZ Platform's content management capabilities may be the ideal fit.

Now that we have explored content management, let's move on to collaboration and user management.

Collaboration & User Management

Collaboration and user management features are critical for organizations that rely on multiple content editors and contributors. EZPublish provides a range of tools to facilitate collaboration, including user and group management, permission controls, and workflow management. It enables organizations to define specific roles and responsibilities for their content creators, ensuring smooth collaboration and content approval processes.

eZ Platform offers similar collaboration features, allowing organizations to manage users and groups, assign permissions, and create custom workflows. Additionally, eZ Platform provides an innovative content approval feature called "Content Staging," which allows content editors to preview and approve changes before they are published to the live website. This feature enhances collaboration and reduces the risk of errors.

Both CMS options excel in collaboration and user management, but eZ Platform's content staging feature provides an additional layer of control and convenience. If your organization prioritizes collaboration and requires a robust content approval process, eZ Platform may be the better choice.

Next, let's discuss the performance, scalability, and hosting capabilities of EZPublish and eZ Platform.

Performance, Scalability, & Hosting

Performance, scalability, and hosting capabilities are crucial considerations when selecting a CMS. EZPublish is known for its solid performance and scalability, having been tested and optimized over years of development. It can handle large amounts of content and traffic without significant performance degradation.

eZ Platform builds upon EZPublish's performance and scalability strengths. It leverages the Symfony framework's performance optimization techniques, resulting in even faster response times and improved overall performance. eZ Platform also offers built-in caching mechanisms, such as Content Delivery Network (CDN) support, to further enhance performance.

When it comes to hosting, both CMS options offer flexibility. They can be hosted on various platforms, including on-premises servers, cloud infrastructure, or with specialized hosting providers. The choice of hosting will depend on your organization's specific requirements, infrastructure, and preferences.

Overall, both EZPublish and eZ Platform offer robust performance, scalability, and a range of hosting options. However, eZ Platform's modernized architecture and performance optimizations give it an edge in terms of speed and scalability.

Next, let's explore the customization options, available extensions, and the ecosystem surrounding both EZPublish and eZ Platform.

Customization, Extensions, & Ecosystem

Customization and extensibility are crucial factors to consider when choosing a CMS, as they allow organizations to tailor the platform to their specific needs. EZPublish provides a range of customization options, including the ability to create custom content types, templates, and modules. It also offers an extensive library of pre-built add-ons and extensions.

eZ Platform takes customization and extension capabilities to the next level. Built on the Symfony framework, it benefits from Symfony's powerful and flexible architecture, making it highly customizable. eZ Platform allows developers to create custom content types, modify the user interface, and build custom extensions using Symfony bundles, ensuring that the CMS can be tailored to meet even the most unique requirements.

Both CMS options have vibrant ecosystems, with active communities constantly developing and sharing new extensions, themes, and integrations. However, eZ Platform's integration with Symfony opens the door to an even wider ecosystem of Symfony plugins and libraries.

If your organization requires extensive customization and wants a CMS that can be tailored to fit specific needs, eZ Platform is the more suitable choice. Its Symfony foundation provides unmatched flexibility and customizability.

Now, let's move on to discussing SEO, marketing, and monetization capabilities provided by both CMS options.

SEO, Marketing, & Monetization

SEO, marketing, and monetization capabilities are crucial for organizations looking to enhance their online presence and generate revenue. EZPublish offers a range of SEO features, including customizable URLs, metadata management, and XML sitemap generation. It also provides integrations with popular marketing and analytics tools.

eZ Platform, building upon EZPublish's SEO capabilities, offers further optimization possibilities. It includes tools for managing redirects, optimizing content for search engines, and integrating with marketing automation tools. eZ Platform also offers monetization features, such as multi-channel content delivery and payment gateway integrations, allowing organizations to generate revenue from their digital assets.

If your organization prioritizes advanced SEO, marketing, and monetization capabilities, eZ Platform provides an edge with its additional features and tools.

Next, let's discuss security and compliance, which are paramount considerations for any organization.

Security & Compliance

Security and compliance are critical for organizations handling sensitive data or operating in regulated industries. EZPublish has a solid track record in terms of security, and its community continuously monitors and patches any vulnerabilities. It also provides features like role-based access control and strong password policies to ensure secure content management.

eZ Platform places a strong emphasis on security, leveraging the Symfony framework's security features and best practices. It includes robust authentication and authorization mechanisms, data encryption, and regular security updates. eZ Platform also offers GDPR compliance features, assisting organizations in meeting data protection regulations.

Both CMS options prioritize security, but eZ Platform's Symfony foundation and focus on the latest security practices give it an advantage in terms of security and compliance.

Lastly, let's explore migration, support, and maintenance considerations when adopting EZPublish or eZ Platform.

Migration, Support, & Maintenance

Migrating from one CMS to another can be a daunting process, and both EZPublish and eZ Platform provide support to ease the transition. EZPublish offers migration tools and documentation to assist in migrating from older versions. It also provides migration services for organizations seeking professional assistance.

eZ Platform offers comprehensive migration support, including a dedicated migration extension. This extension helps migrate content and configuration from EZPublish to eZ Platform smoothly. Additionally, it provides comprehensive documentation and migration guides to assist organizations in this process.

When it comes to support and maintenance, both CMS options have active communities, extensive documentation, and support forums. However, eZ Platform benefits from being a more recent iteration, receiving active developer support, regular updates, and improvements.

Now that we have explored all the important aspects of EZPublish and eZ Platform, it's time to summarize our findings.

Conclusion

In conclusion, EZPublish and eZ Platform are both strong CMS options, each with its own set of benefits and features. EZPublish offers stability, reliability, and a vast amount of features for organizations requiring a mature and robust CMS. On the other hand, eZ Platform leverages modern web technologies, providing greater flexibility, a sleek user interface, and advanced content management capabilities.

When making a decision, consider your organization's specific needs and priorities. If you value familiarity, stability, and a wealth of out-of-the-box features, EZPublish may be the ideal choice. However, if you prioritize flexibility, customization, and a modern user experience, eZ Platform offers a more forward-looking solution.

Take the time to evaluate your requirements and engage with the communities surrounding both CMS options to gain further insights. A successful CMS implementation can have a significant impact on your organization's digital presence, so choose wisely!

Installing The eZ Publish CMS On An Ubuntu 7.10 Server

Version 1.0
is one of the most well known and widespread web content management systems. Because its setup is not trivial, this tutorial shows how to install it on an Ubuntu 7.10 (Gutsy Gibbon) server.

I do not issue any guarantee that this will work for you!

1 Preliminary Note

My Ubuntu 7.10 server has the hostname server1.example.com and the IP address 192.168.0.100 in this tutorial. I'm using Ubuntu's default Apache document root /var/www here - if you've set up a vhost with a different document root you'll have to adjust the paths where appropriate.

The requirements for an eZ Publish installation are listed here; I'll show how to fulfill these requirements and finally install eZ Publish.

Make sure that you are logged in as root (type in

sudo su

to become root), because we must run all the steps from this tutorial as the root user.

2 Installing MySQL 5.0

To install MySQL 5.0, we simply run:

apt-get install mysql-server mysql-client

You will be asked to provide a password for the MySQL root user - this password is valid for the user root@localhost as well as root@server1.example.com, so we don't have to specify a MySQL root password manually later on (as was the case with previous Ubuntu versions):

New password for the MySQL "root" user: <-- yourrootsqlpassword

3 Installing Apache2

eZ Publish works with Apache 1.3 and Apache 2. If we use Apache 2, we must install the prefork variant as follows:

apt-get install apache2 apache2-doc apache2-mpm-prefork apache2-utils libexpat1 ssl-cert

4 Installing PHP5

eZ Publish depends on a lot of PHP extensions/functions (see the requirements page), e.g. MySQL, zlib, DOM, session support, PCRE support, GD2 support, CLI support, mbstring, exif, curl, etc. which we can install as follows:

apt-get install libapache2-mod-php5 php5 php5-common php5-gd php5-curl php5-dev php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-mysql php5-ps php5-pspell php5-recode php5-snmp php5-sqlite php5-tidy php5-xmlrpc php5-xsl php5-cli imagemagick

You will be asked the following question:

Continue installing libc-client without Maildir support? <-- Yes

Now we have to enable some Apache modules (SSL, rewrite, suexec, and include):

a2enmod ssl
a2enmod rewrite
a2enmod suexec
a2enmod include

Reload the Apache configuration:

/etc/init.d/apache2 force-reload

Now open the php.ini...

vi /etc/php5/apache2/php.ini

... and make sure that PHP has enough memory to run eZ Publish. It needs at least 64MB (the more the better), so you should have something like this in your php.ini:

[...]memory_limit = 128M      ; Maximum amount of memory a script may consume (128MB)[...]

In the same file, we need to specify the correct timezone for the server (you can find a list of all timezones here: http://de3.php.net/timezones), e.g. like this:

[...][Date]; Defines the default timezone used by the date functionsdate.timezone = Europe/Berlin[...]

Afterwards we restart Apache:

/etc/init.d/apache2 restart

Next create the following file...

vi /var/www/info.php

<?phpphpinfo();?>

... and call it in a browser (e.g. http://192.168.0.100/info.php). In the output you should now find all required PHP extensions:

5 Installing eZ Components

eZ Components is a PHP components library needed by eZ Publish. We can install it as follows:

pear channel-discover components.ez.no

pear install -a ezc/eZComponents

Installing The eZ Publish CMS On An Ubuntu 7.10 Server - Page 2

On this page

1. 6 Preparing MySQL
2. 7 Installing eZ Publish
3. 8 Links

6 Preparing MySQL

Now we create a database for eZ Publish (we name the database ezpublish) and a database user (which we name ezpublish as well). First, log in to MySQL:

mysql --host=localhost --port=3306 -u root -p

On the MySQL shell, run the following commands:

CREATE DATABASE ezpublish CHARACTER SET utf8;
GRANT ALL ON ezpublish.* TO ezpublish@localhost IDENTIFIED BY 'ezpublishsqlpassword';
FLUSH PRIVILEGES;

Make sure that you replace ezpublishsqlpassword with a password of your choice.

Then type

quit

to leave the MySQL shell.

7 Installing eZ Publish

Next we download eZ Publish from http://ez.no/content/download, e.g. like this:

cd /tmp
wget http://ez.no/content/download/218812/1467959/file/ezpublish-4.0.0-gpl.tar.gz

Then we uncompress eZ Publish:

tar zxvf ezpublish-4.0.0-gpl.tar.gz -C /var/www

This creates the directory ezpublish-4.0.0 in /var/www which we rename to ezpublish:

mv /var/www/ezpublish-4.0.0 /var/www/ezpublish

(If you don't want to use eZ Publish in a subdirectory of /var/www, you can copy the contents of the ezpublish directory to /var/www:

cd /var/www/ezpublish
cp -pfr * ../
cd ../
rm -fr ezpublish

)

Now we can run eZ Publish's web based installer. Call http://192.168.0.100/ezpublish/ in a browser, and the installer should come up.

Select the installation language:

On the second page the installer checks your system. If the installer tells you to make some changes, you should execute them on the shell:

For example, I had to do the following changes:

cd /var/www/ezpublish
chmod -R ug+rwx design extension settings settings/override settings/siteaccess settings/siteaccess/admin var var/cache var/storage
chown -R www-data:www-data design extension settings settings/override settings/siteaccess settings/siteaccess/admin var var/cache var/storage

cd /var/www/ezpublish
mkdir -p var/cache/codepages \
var/cache/content \
var/cache/ini \
var/cache/override \
var/cache/template \
var/cache/template/process \
var/cache/template/tree \
var/cache/texttoimage \
var/cache/translation \
var/log \
var/storage/original \
var/storage/reference \
var/storage/variations

Then refresh the page in your browser. In my case, it told me to also run these commands:

cd /var/www/ezpublish
chmod -R ug+rwx var/cache/codepages var/cache/content var/cache/ini var/cache/override var/cache/template var/cache/template/process var/cache/template/tree var/cache/texttoimage var/cache/translation var/log var/storage/original var/storage/reference var/storage/variations
chown -R www-data:www-data var/cache/codepages var/cache/content var/cache/ini var/cache/override var/cache/template var/cache/template/process var/cache/template/tree var/cache/texttoimage var/cache/translation var/log var/storage/original var/storage/reference var/storage/variations

Refresh the page until the system chekc is ok, then click on Next >.

On the next page you must specify the method to send out mail. If you have Postfix, Sendmail, Exim, or any other MTA installed, you can use the first option, otherwise specify a mail server that can be used to send mail:

On the next page I chose MySQL...

... and then I typed in the MySQL settings:

Select the required languages that eZ Publish should support:

Select the default layout for your web site (this can be changed later on):

The site package I've chosen supports English (United Kingdom) and French (France), however, only English (American) was installed, so I had to map English (United Kingdom) to English (American) and skip French:

Select URL as the site access method:

You can accept the default settings on the following page:

Then type in the details for the site administrator:

If you see something like this...

... you should run the given command, e.g.:

cd /var/www/ezpublish
cp .htaccess_root .htaccess

Now you can choose if you want to send details about your eZ Publish installation to eZ Systems or not:

That's it, your eZ Publish installation is now finished:

8 Links

• eZ Publish: http://ez.no/ezpublish
• Ubuntu: http://www.ubuntu.com

by Ivo Lukač - February 20, 2012 on Netgen Blog

This tip is only for advanced and experienced developers, classified as "do not do this at home" and "no warranty".

A good practice in eZ Publish development is to specify the content classes (or content types) at the beginning of the project. But of course in real situations there is a big chance that something needs to be changed at later stage or even after going live. What is great with eZ is that you can easily change content types either by adding new attributes or removing the ones that are not needed. And that ability covers a lot of situation, but not all.

For example imagine a following scenario:
- a class is specified and created
- lot objects of that class are created too
- you realize that some of that objects should be of different class
- you need to convert some existing objects to that different class 

You can create the second class but the problem is that you already have the content. The swap node feature can help if the number of objects you want to change is low.  

But what to do if you need to change the class for a lot of existing objects? You could create an export/import script, but that takes time too. There was an extension for changing class on existing objects: http://projects.ez.no/object_content_class_change but its outdated (would be nice if someone could upgrade it to PHP5 and eZ 4.2+).

There is a quick solution but its not for people with weak hearth :)

1. create the new class by copying the old one and note the new class id (e.g. 111)
2. note all class attribute ids from the old class (e.g. 222,223)
3. note all class attribute ids from the new class (e.g. 333,334 )
4. collect object ids for objects you want to change class (e.g. 444,555,777,888)
5. go to your database console and verify that you have good ids:
6. backup your database (just in case)
7. lock object changes to ensure that nobody changes those objects while doing this (the safest way is to just shutdown the web site or disable login for editors)
8. run the following SQL command to update ezcontentobject table:
9. run following SQL commands to update ezcontentobject_attribute table for each attribute:
   update ezcontentobject_attribute set contentclassattribute_id = 333 where contentobject_id in (444,555,777,888) and contentclassattribute_id = 222;
   update ezcontentobject_attribute set contentclassattribute_id = 334 where contentobject_id in (444,555,777,888) and contentclassattribute_id = 223;
10. Clear the related content caches
11. Do your changes on the new class

Important thing is that you can “map” attributes only of the same datatype. Otherwise you can break the eZ data model. So the first step is crucial to create the exact same copy of the class. Afterwards, in step 11, you can do changes to your new class.So far I didn't need this to often so there is no script. It would be rather simple to create a script which could hide few steps (like 2., 3., 8., and 9.). 

by Ivo Lukač - August 24, 2011 on Netgen BlogI will share with you a secret known only to eZ Publish gurus: persistent variables are not that hard to learn :). Of course, learning depends on good materials so hopefully this blog post will help clarify some things.

Just for test I spent 30 seconds on google (usually enough time) to find some good learning content about persistent variables and I found no such page on ez.no ecosystem. I did found 2 short  blog posts (first and second) about the topic, not counting several forum posts. Interesting though, from both blogs you can see that authors haven’t been aware of persistent variables possibilities (second one even calls it mythical) but realised quickly how useful they are. 

Before proceeding to the good stuff there is an important thing to know to successfully master persistent variables (advanced users can skip the next part). 

The Execution Order

Sometimes while you are learning a technology you get misled and learn things the wrong way. When you reach a certain point and look back you can only hit the wall with your head because of the time you wasted. I admit, when starting with eZ, it took me a while to understand in which order templates are executed. Probably the fact that pagelayout.tpl includes the $module_result.content was misleading so I thought pagelayout is executed first. Don’t make the same mistake.

The right clue was under my nose all the time: check the debug log templates list, node/view/full template is the first :)

Why is this important? You can’t transfer variables from the layout to the module, of course. But you can do it in the other direction, although, that usage is not obvious as you may think.

Persistent variables

First let see what documentation specifies about these variable:
“A variable set in one of the templates used by the view that was executed. Regardless of the caching mechanisms used, this variable will be available in the pagelayout. The type of the persistent variable depends on the value it contains. If the variable is not set, it will simply return a boolean FALSE” (link). Not clear enough, I would say, so lets help out here.

Setting a persistent variable

You can find the simplest example in full frontpage template of the ezwebin extension:

<span class="xml">{set scope=global persistent_variable=hash('left_menu', false(), 'extra_menu', false(), 'show_path', false())}</span>

Here you enable or disable certain parts in the ezwebin pagelayout. The problem with this code is that:

• all variables can be set only once, if you call the above line the second time it will reset all variables set before
• hash array can’t be created dynamically so you can’t set more combinations without nested “if” nightmare..

Solutions is the ezpagedata_set() operator from the ezwebin extension. You can simply set each variable like this:

<span class="xml">{ezpagedata_set('key', 'value')}{ezpagedata_set('key2', 'value2')}</span>

More elegant, of course.

Using persistent variable

After you set a persistent variable it can be used where needed in pagelayout templates. There are 2 ways:

- via module_result variable:

<span class="xml">{$module_result.content_info.persistent_variable.key}</span>

- via ezpagedata() operator from ezwebin extension:  

<span class="xml">{def $pagedata = ezpagedata()}{$pagedata.persistent_variable.key}</span>

Simple is that.

Few simple scenarios

• controlling things shown in layout like path, menus and similar
• showing some information from $node so it's not needed to fetch it again
• replacing some default info with current node specific stuff (e.g. <title>, meta description, meta keywords, etc.)

Advanced usages

1. Override a template with persistent variable:

<span class="hljs-section">[foo_layout]</span><span class="hljs-attr">Source</span>=pagelayout.tpl<span class="hljs-attr">MatchFile</span>=pagelayout_foo.tpl<span class="hljs-attr">Subdir</span>=templates<span class="hljs-attr">Match[persistent_variable]</span>=foo

2. Transfer bigger chunk of html. Use set-block and persistent variable to transfer bigger chunk of code.   

<span class="xml">{set-block variable=$foo}    <span class="hljs-tag"><<span class="hljs-name">div</span> <span class="hljs-attr">class</span>=<span class="hljs-string">”box”</span>></span>        {node_view_gui content_node=$child view=’line’}    <span class="hljs-tag"></<span class="hljs-name">div</span>></span>{/set-block}{ezpagedata_set('foo', $foo)}</span>

3. Doing some really cool stuff like setting Varnish TTL via custom headers (via @jeanvoye).

Things to remember

Persistent variables are usually generated in full views and as such are part of view cache. They will expire with the view cache of the view. Of course, if used within a cache-block in pagelayout they will be cached again. So don’t get confused.

You can’t store complex data types like objects, but usually numbers, strings, arrays and hashes are enough.  

Any feedback on this topic would be useful. Thanks.

eZ publish Overview : What is eZ publish?

eZ publish is a content management framework. A base set of features and functions that make up the core of a content management system.

It can be used as a system straight out of the box with its standard functionality which provides the majority of the features clients are likely to need.

However, often clients require parts of the system to be customised to their needs.

This is where the approach taken in the eZ publish framework comes into it’s strength.

Separation of Layers

One of the greatest strengths of eZ publish is the way it cleanly separates layers.

In traditional software architecture, there are 4 layers

• User Interface

• Business Logic

• System Interface

• Data Access & Storage

The theory is that each layer should be independent from the other layers so that changes can be made within a layer without affecting the rest of the system. Also known as the “black box” concept, that is, the inner workings of one layer is like a black box to the other layers. The benefit of this is that each layer can be updated, modified or replaced without having to change any of the other layers. Eg. a particular solution might use Postgres as a part of the data access layer but the client has decided that they want to move to Oracle. If the business logic layer has been cleanly separated from the data layer, it means that only the data layer has to be modified to work with Oracle instead of Postgres.

Unfortunately, in many web applications, the presentation, business logic and data access layers become intermingled making it difficult to update and modify without running into trouble. eZ publish solves this by ensuring the layers are cleanly separated. This means you can change one layer without impacting the other layers. A common example is that you can change the entire look and feel of a site quickly and easily without affecting the rest of the system.

The way eZ publish achieves this is through the use of designs, templates, content classes and extensions.

• The user interface is created through a combination of design & templates

• Business logic is created through sections, access control and extensions
• Data access is built into the framework

Initially it’s not obvious as to why this idea of separation of layers is so powerful.

When initially building a system, allowing the layers to be mixed might lead to a quicker result, it’s not until working on larger systems with many developers or once the system requires updates and maintenance that the layered approach proves to be far superior.

The benefit of the eZ publish framework is that the layered approach is built in.

Fetching content the new way on eZ Publish 5.x.

In the following article we are going to show you how to fetch information in the new eZ Publish version considering that permissions may be set in place on different sections and we will compare it to how is it done in the legacy kernel.

During the flow of this article we will introduce a new undocumented method which is going to let us bypass permissions set to different sections.

In our example, let's suppose that we are displaying a set of images in the media library. These images are displayed within the content structure tree, but aren't supposed to be directly accessible in the media library. Therefore, the anonymous user does not have permission to directly view those images and we need to bypass that permission limitation in our fetches.

Fetching content in eZ Publish legacy

Using the current user

This simple fetch will return a list of the images that we have, although if the anonymous user does not have permissions for that folder in the media library, we will get an empty result.

(In our eZ Publish legacy code examples, we are showing example template code. For eZ Publish 5, we are showing PHP code in a custom controller, since data fetches are now expected to be done in PHP land ...

Lately, I've been testing and fixing several issues with the eZ Publish REST API v2. To manually test it, I use cURL (man curl) because it's widely available, well documented, and like any other command line tool, you can use it together with others text processing tools (grep, xmllint, xsltproc,…). I'm writing this post as a memo for me but I'm sure some people will find it useful as well.

The whole REST API v2 is specified in the ezpublish-kernel git repository. Yes, that's a huge document, because the REST API is huge :-) A shorter introduction/documentation is also available in the eZ Publish documentation.

Note: to keep this post short and readable, the command results are not in the post itself but the whole command line session is available on this page ...

If you're relatively new to eZ Publish, you might know about siteaccesses, design, extensions, and overrides. You can build a basic extension, edit a template file, and write a simple full view override rule. However, you might have trouble putting this all together. You might struggle with whether to put your template in the "standard" design or a custom site design folder. You might be confused as to whether to put your template in the "override/templates" folder or the "templates" folder, and/or the overall template path in the first place. This article will take a step back for a high-level look at how eZ Publish loads extensions, particularly design extensions, as well as how to find out which templates are being used and how to properly override them.

At the end of this tutorial, you should understand best practices when it comes to design extensions and template paths, and you should be able to apply this new understanding to efficiently troubleshoot and identify common mistakes ...

How to make eZ Publish use override conditions when loading a template

I answered this question today on IRC and a colleague asked me the same thing about two weeks ago… it's time to write down the solution :-)

Basically, you just need to tell what design keys you want to use and their value to the template engine of eZ Publish. The design keys are the parameters you will be able to use in an override condition. Let's take an example with a simplistic PHP view