Future ideas

David Buchmann edited this page Mar 30, 2016 · 8 revisions
  • Please try to add github issue links to your points where they exist
  • Remove things that are on a Release x.y page or that got implemented
  • See also Feature brainstorming

Bundle improvements


Extensible way to embed dynamic/service-based content into Phpcr fields

This would be a generalization of the cmf_embed_blocks filter. (Which is broken when using frontend editing, as then the rendered output is stored instead of the short tag).

The initial use case for this is being able to insert wiki-style links in your document content that contain a reference to the uuid of a Phpcr page. The full URL would be replaced in the content via a twig filter. This concept could be generalized to something like wordpress' short tags (A feature which is present in many CMSes). It would be great if this was generalized so users could tag a service as a cmf.embedded.provider and we would provider a twig filter that looked for a format like foo, { param1: 'value' } that would get the provider with the alias 'foo' that was tagged as a cmf.embedded.provider and call a method on it with the params provided that would be used to replace that tag with the dynamic content. Discussion at https://github.com/symfony-cmf/RoutingBundle/issues/178

Editing workflow

  • linear workflow: draft, ready, published, archived... (we have a basic publish workflow solution in CoreBundle)
    • page preview of drafts with access control


Referencing content from templates

The integration between code / templates and dynamic content is a difficult problem that is not addressed by the cmf so far. See https://github.com/symfony-cmf/symfony-cmf/issues/212 for the discussion.

dtl: As said I hinted in the meeting I think we can fix this through the introduction of a bigger feature i.e. site "contexts" and "resource location". Which would be a major feature and would kill not a few birds with one stone including Multi-site, centralized base-path management Referencing and resources with static identifiers.

REST write support

Unify the ContentBundle / CreateBundle REST support, so that we can read/write/delete any content based on the actual routing structure.

Furthermore look into providing a generic REST API on top of PHPCR (potentially based on Jackrabbit Oak's REST API). Also look into SyliusResourceBundle, Marmelab PHPCR-API and other related projects.

This would open the road for things like marmelab/admin-ng.


Split out Media component

See this PR https://github.com/symfony-cmf/MediaBundle/pull/50

SonataMediaBundle integration

Work on the SonataMediaBundle to integrate it with the CmfMediaBundle for phpcr (rmsint)



Creation of a sitemap in different formats based on cmf routes and its content https://github.com/symfony-cmf/SeoBundle/issues/132.

Sonata Admin

Grouped Admins

Finish grouped admin list and implement it for the block and maybe the media bundle (keeping probably the admin separate from the core as mentioned above)



  • linear versioning control in admin backend (the phpcr level is implemented in jackalope-jackrabbit and phpcr-odm supports it)

Common Features for all implementations

Make all admin implementations more equal to increase maintainability, move code duplications to the AdminBundle.

Cross-bundle improvements

Doctrine ORM Support by Standard

Implement ORM support in all bundles.

Multi-site Support


New functionality


Find a solution for tagging. There are several Bundles out there already: https://github.com/symfony-cmf/symfony-cmf/issues/161

In terms of leveraging PHPCR see here: http://stackoverflow.com/questions/14315031/best-way-to-implements-a-tag-based-search-system-by-jcr-like-modeshape

Another cool feature for 1.1 would be to revive the support for http://wiki.iks-project.eu/index.php/Stanbol


Integration with ORM and other object-mapper systems

We should be able to link doctrine entities, mongo/couch documents or also non-doctrine things with adapters. There have been a bunch of half-finished efforts for this:

One to one mapping between node-type and document

I think a one-to-one mapping between node type and document would have huge benefits for the ODM.

  • Queries would become more logical (SELECT FROM odm:user AS u LEFT JOIN odm:site AS s).
  • We could generate CND schema for each document.

Content deployment


indexing into ElasticSearch for Jackalope


improving the CachedClient for Doctrine DBAL

Right now the entire node data cache is cleared on any node write. This could maybe be made smarter.

Furthermore maybe the solution could be made generic to also work with other transports

Versioning for jackalope-doctrine-dbal



The component has received a lot of attention and we need to make it standalone from the CMF. To do this some things are needed:

  • The component should not require any database layer by default. It should only provide optional integrations with the PHPCR odm and the ORM.
  • All documents should be moved to the bundles inwhich they are used
  • The way the component works with different database layers should be refactored (see next section)

Decouple database from bootstrap (dtl)

A useful testing component would be able to be used outside of a Symfony context, for example when testing components which are not coupled with Symfony - for example PHPCR-ODM or Routing.

  • This would enable us to move documents et al to components and keep tests where they belong - in the component.

Refactor database layers

Currently, the component has not the best setup for database-testing:

  • The database is only created before running the tests, this means all tests will get the mutated database, depending on what was done before it.
  • To make clear which database layer, phpcr odm or orm, is used, the component uses environments. This is not the best thing to do.

Both drawbacks can be fixed by organizing the tests in testsuites, one for phpcr odm and one for orm, and using PHPUnit_Framework_TestListener to create the database on startTestsuite and using startTest to clear the database and load the fixtures (configured in the db helper).

Make tests run quicker

Some tests take up to an hour, that's not good for a test. We should rethink the required packages, to make composer quicker and we should introduce parallelized builds.

Split into small parts

There is discussion if this is desirable and how we would best do this. git subtree split was mentioned...

Standard Library (dtl)

A standard library containing cross-cutting interfaces and traits.



I started something here: https://github.com/dantleech/cmf-standard-lib

Removal of integrations in "core" packages (dtl)

The following are some of the current integrations we have in the CMF:

  • Sonata Admin (in every adminstrable bundle)
  • Doctrine ORM
  • Doctrine PHPCR-ODM
  • ElFinder

and I am sure that there are some more. We can imagine adding more third-party integrations as people ask for them or PR them.

Having these integrations in the core bundle causes the following problems:

  • It forces the developers of the code bundles to take responsiblity for an unbounded number of third party integrations.
  • Tests become increasingly complicated and long running.
  • We either include all the dependencies or we suggest them - but this defeats the object of dependency management!.

I would suggest that:

  • We outsource all the third-party integrations into satellite packages
              Orm/     < -- Bundle root is here

We can make sattelite bundle configuration suitably brief by providing a special bundle class:

// /vendor/symfony-cmf/menu-bundle-persistence-doctrine-orm/[...]/MenuBundle/MenuPersistenceDoctrineOrmBundle.php

namespace Symfony\Cmf\Bundle\MenuBundle;

class MenuPersistenceDoctrineOrmBundle extends BundleExtension
    public function buildContainer(ContainerBuilder $container)
        $def = new Definition('cmf_menu.persistence.orm_provider');

Use of traits in bundles

Traits will supplement Interfaces to provide boilderplate code which can be imported into user implementations.

An example of what might be done with the MenuNode:


use Symfony\Cmf\Standard as Std;
use SYmfony\Cmf\Bundle\Menu\LinkTypeInterface;
use SYmfony\Cmf\Bundle\Menu\LinkTypeTrait;

class MenuNode implements 
    use Std\Meta\LocaleTrait;
    use Std\PublushTimePeriodTrait;
    use Std\PublishableTrait;
    use Std\ContentTrait;
    use LinkTypeTrait;

dbu says: This would make a lot of sense indeed. Unfortunately, we can't rely on this for our own code. Redhat is still at PHP 5.3 so i guess requiring PHP 5.4 has to wait another year or so. We could announce at 1.2 that 1.3 will start to use traits, wdyt?

Move code to components for parts that are usefull to be framework agnostic

(See MediaBundle above)

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.