I'm quite new at Symfony CMF contributing, but I think Symfony CMF lack a stable release compatible with Symfony 3 which was released a year ago. I don't know what work is required to get a stable 2.0 release, but I think we need a plan.

This plan should, IMHO, focus on breaking things. New features could be delayed in the 2.X series. For example, we started to extract FormTypes for sonata Admin classes. In hindsight, this task is too big and we should focus on moving sonata stuff in it's own bundle, and then as new feature adding form types.

Does this could be applied to others things wanted for 2.0 ?

WDYT?

Composer deprecated target-dir in favor of PSR-4 autoloading. We should update all bundles for 1.1 (there is a potential BC break when people did weird things as we do with the CreateBundle composer tasks, as the absolute path under vendor will change when going to PSR-4)

We discussed this topic on and off, but i did not find any documentation, so lets collect this discussion here.

Currently, we provide sonata phpcr-odm admin classes in many of the cmf bundles. The bundles do not depend on sonata admin, creating an "optional dependency". This becomes more and more of a problem, see for example https://github.com/symfony-cmf/RoutingBundle/pull/292

If we split the admin out into their own bundle, we can properly manage dependencies without worrying about the impact on users that do not need sonata at all. This would allow to provide admins for different versions of sonata, and will a better solution when admins for other systems than sonata are developped.

We can keep the namespaces as they are, making the only BC break (if that is to be called a BC break) that users of sonata admin need depend on the new bundle(s) in addition to the sonata admin.

Options:

One bundle CmfSonataPhpcrAdminBundle

I would suggest that this covers only the bundles that are included in symfony-cmf/symfony-cmf

Pro

• Less separate repositories, less confusion
• Possibility to share code between admins

Con

• How to model dependency on feature bundle? Depend on symfony-cmf/symfony-cmf? Or keep optional dependencies?

A bundle per feature bundle CmfRoutingSonataPhpcrAdminBundle

Pro

• Very clean dependency modelling
• Handle version differences in the cmf feature bundles (i could use the admin that goes with RoutingBundle 1.3 together with the admin that goes with ContentBundle version 1.5)

Con

• Lots of repositories for the user to depend on and for us to maintain.
• No sharing of common code

I noticed issue connected with uploading image. During editing content I just click image, select image and try to upload it. I got an error. Request is send to:

symfony-cmf/create/image/upload/ckeditor?CKEditor=editor3&CKEditorFuncNum=221&langCode=pl

After that, error occurs. In my dev env I got Property \"parent\" mapped as ParentDocument may not be empty in document of class \"Symfony\\Cmf\\Bundle\\MediaBundle\\Doctrine\\Phpcr\\Image\", class: Doctrine\\ODM\\PHPCR\\Id\\IdException.

Error occurs even on demo page http://cmf.liip.ch/en - thrown error 500.

right now our Bundles follow the general convention of including the vendor prefix in the extension alias, ie. "symfony_cmf_core". However Symfony2 itself reserves the right to not include this, ie. "framework", "twig" etc.

we could therefore by the same logic decide to also drop this prefix. however this can lead to some problematic names:

1. "core"
2. "create"

etc.

so maybe we should just drop "symfony_" but keep "cmf_"?

During initial configuration there are questions about pdo_sqlite only. I can change settings for pod_mysql in config.php.

After that there is error with doctrine:database:create and doctrine:phpcr:init:dbal

Using doctrine:database:create give an error:

        Undefined index: dbname in D:\workspace\cmf\vendor\doctrine\doctrine-bundle\Doctrine\Bundle\DoctrineBundle\Command\CreateDatabaseDoctrineCommand.php on line 61.
        Could not create database for connection named ``
        An exception occurred while executng 'Create DATABASE ``':
        SQLSTATE[42000]: Syntax error or acces violation: 1102 Incorrect database name ''

Using doctrine:phpcr:init:dbal give an error:

        SQLSTATE[3D000: Invalid catalog name:1046 No database selected

• menu entries are documents with a label (potentially i18n) and either
  • url: rendered just out
  • route: rendered to its url
  • reference (weak or hard) to a content node: rendered with the help of the repository routing bundle to the node referencing that content. (depends on #89)
• generates a structure compatible with the MenuBundle for the rendering
• there can by any number of different named menues

Currently the cmf assumes there is a single basepath for various types of documents (routes, content, menus, etc.). However in a multi-domain/website configuration this may not be true. One approach to handling this is having a service that reconfigures the basepaths in various services based on the current website. This can be problematic in the case of generating a menu or loading content or generating a url or accessing any content outside of the current basepath. Reconfiguring the basepaths dynamically is a fragile approach in this case for reasons outlined in https://github.com/symfony-cmf/RoutingBundle/issues/178#issuecomment-30635352 (this also applies to generating menus in addition to route urls outside the current basepath context).

I think it would be a great feature of the cmf (especially for multi-site functionality) to allow multiple basepaths for content, menus, routes, etc. in addition to handling URL generation to automatically include the domain when generating URLs outside of the current basepath.

Obviously this is a potentially major change that effects multiple bundles (Menu, Routing, Content, etc.) and I'd love to hear what the core devs have to say about it.

One possible approach would be centralizing the knowledge of basepaths into a BasepathProviderInterface. There could be multiple services that provide an implementation of this such as cmf_menu.basepath_provider and cmf_content.basepath_provider, these could all even be instances of the same class just with different array of basepaths configured.

Some issues that discuss this situation: https://github.com/symfony-cmf/RoutingBundle/issues/178 https://github.com/symfony-cmf/RoutingBundle/issues/149

I have now 5 menu items in sonata-admin from several CMF-bundles, but most of them (4 to be exact) have only 1, or 2 entries. Keeping in mind, that users maybe use sonata-admin for other tasks too, it can lead to quite wide menu bars at the top.

Whats about combining them into a single root-item "CMF" or something like that?

Beside, that one solution is to just merge them as they are and don't think about it any further

• Maybe sonata-admin supports more menu levels. I don't know.

• Also I don't know, if separators are supported

  Route
  Redirect Route
  -----------------------
  Menu node
  

  and so on

I made some updates for core, block, menu and content bundles:

• https://github.com/covex-nn/core-bundle/compare/master...updates
• https://github.com/covex-nn/block-bundle/compare/master...updates
• https://github.com/covex-nn/menu-bundle/compare/master...updates
• https://github.com/covex-nn/content-bundle/compare/master...updates

With these changes each bundle can be installed separately with Symfony Flex without errors. And each bundle can have a default configuration (a recipe!) like this or none:

cmf_core:
    persistence:
        phpcr:
            enabled: true

If all bundles will be combined together with doctrine/phpcr-bundle (i.e. symfony-cmf/symfony-cmf without doctrine/phpcr-odm) they also can be installed with Symfony Flex without error, a minimum default configuration (a recipe!) for such pack is here:

cmf_routing:
    dynamic:
        persistence:
            phpcr:
                enabled: true

Also i created a gist to show how it works. You need to create a composer.json, run composer install, see error message, create a default configuration, run composer auto-scripts, see no errors.

Next, there could be created packs for each jackalope/jackalope-transport package. Such pack should require doctrine/phpcr-bundle, doctrine/phpcr-odm, jackalope/jackalope-transport implementation, and phpcr/phpcr-implementation implementation. There are 5 of them in packagist.org. I hope such packages can have default configuration to have a recipe.

Together symfony-cmf-without-odm-pack and jackalope-transport-pack will install fully functional SymfonyCMF project

What do you think? If my changes are ok, a will create 4 PRs

Make the chainrouter code into a configurable bundle: http://groups.google.com/group/symfony-devs/msg/607f381110d9c741

Configuration should allow to add own router implementations before or after the default router, and to disable the default router completely if wanted.

This will then be used in #89 to hook in a cmf routing reading from the repository

I saw that there's already some supports added to other bundles, but media-bundle is still missing on https://github.com/symfony-cmf/symfony-cmf/issues/254

Is there an alternative package or still waiting for PRs?

I would like to persist an overview of the current state of all packages:

| Pagage | SF 4.2 Deprecation | Comments | |--- |--- |--- | | block-bundle | GONE | needs an upgrade of testing component | | content-bundle | GONE | ready to review | | core-bundle | GONE | needs an upgrade of testing component | | menu-bundle | GONE | needs an upgrade of testing component | |resource| GONE | ready to review | | resource-bundle | GONE | ready to review | | resource-rest-bundle | GONE | ready to review | | routing | GONE | ready to review | | routing-bundle | GONE | ready to review | | routing-auto | GONE | ready to review | | routing-auto-bundle | GONE | ready to review | | seo-bundle | GONE | needs an upgrade of testing component | | sonata-admin | GONE | blocked by block-bundle | | resting | GONE | mergend,would get an major release | | tree-browser-bundle | GONE | ready for review | | cmf-sandbox | XXX | Still has no release on CMF 2.1, there is an open PR | | cmf-docs | XXX | Still lacks on docs for CMF 2.1 |

I currently work on our dev-kit to get more controll over our releases. My main reasons are decoupling of the releases of the packages and simplify them at all. To get out faster in smaler steps. So what do i have in mind?

Independent releases

We talk about releasing each package in an independent manner, but do not do. We wait until each of the packages is ready and shout out then. This should be changed. Each package should release a new minor after mergin a complete feature into master. Each release on a package should trigger a release on sandbox also (see automation), doing so the sandbox should be fixed on explicit minor versions of our eco system and each single new release of i.e. seo-bundle would increase the version of seo-bundle in sandbox and of its own version. So the counter of sandbox versions would increase as the sum of all package's releases.

Ready to ship

This would have one outcome: each merge on master (or we do it like sonata and go on 1.x and 2.x to have master for major changes) should end in a green build on the packages, so the package is ready to ship, and on green build within the sandbox, so that the sandbox would be ready to ship. We would skip RC on minor releases and work with bug fixes instead. Why skipping RC? We currently have that less responses on our RC's that i would skip it and if something breaks, the user would hopefully report it, and would be able to switch back, as we would have more versions.

Docs inside the package repo

One other outcome would be: we should couple the docs inside the packages itself. Those common doc pages, which do not belong to any package at all, can still stay in a docs repository , which would be responseable to aggregate the complete docs. Having the docs in repo, would mean, that one Acceptence Criteria would be to fix or change docs. No more differences between docs and versions.

Release automation

At the end the releasing should be done in a automatic manner, like we used to do it day by day in our jobs. So as i said, each package PR should be merged, when:

• docs are updated and valid
• own build is green
• integration build in sandbox is green (directly use the feature branch of the package itself)

having that, a merge on master would mean, a release on package, which should be done through CI and and a PR on sandbox to increase the package's version. We can add the new stuff of our feature then here. A green build and merge on master would end up in a new release of sandbox also.

That sounds like some work, but at the end we should care about merging features in our packages only. I would even add a automatic twitter notice on each release. And i really whant to have that automatic realeases to get back on track and get back some velocity and controll.

There is now a very nice template for a good .travis.yml file in the symfony doc: https://symfony.com/doc/current/bundles/best_practices.html#continuous-integration

Is the travis config entirely generated by dev-kit? If so, we could simply update the dev-kit.

I didn't participate on the former discussion on that theme and i didn't read the old threads to feel free in mind. So i would propose to create a mono repositry for the CMF.

I wrote down my ideas and the current state of testing in: https://github.com/symfony-cmf/symfony-cmf/wiki/%5BPOC%5D-by-Max---Monolythic-Repository (feel free to correct grammar issues)

My main purpose is to work one on code base only. Especially when working accross repository boardesa it a really hard work to connect several dev branches. Especiall when having the number of maintainers in mind a mone repo will be an easier piece of code to watch.

The main issue against it is the technicial infra structure. Means: what to test and how long and how to sync to the specific read-only repositories. But as you can read in the wiki post, i am on a good way to propose a nice and complete solution. I still have one eye on splitt.sh but currently see no advantage agains writing smal own scripts. The Symfony Core got an extra tool called gh to do the special work related on merging a PR, but Fabian said it is not public.

If there are issue on the workflow, especially in my head feel free to correct and add. From my POV we do not need the complete sync from one of the many repos into mono repo. We should keep them read-only and push changes from mono repo only.

@dbu @dantleech @lsmith77 @wouterj can i have your input, please?