this bundle has no testing. add some tests for the relevant parts and a .travis.yml file

I am getting this error after running composer update

[Doctrine\ODM\PHPCR\Mapping\MappingException] Invalid referrer mapping on document "Symfony\Cmf\Bundle\ContentBundle\Document\StaticContent" for field "menus": The referringDocument class "Symfony\Cmf\Bundle\MenuBundle\Document\MenuNode" does not exist

I am including the following packages

        "jackalope/jackalope-doctrine-dbal": "~1.0",
        "symfony-cmf/block-bundle": "~1.0",
        "symfony-cmf/content-bundle": "~1.0",

I am guessing it is something simple, but figured I would report it. Going to revert back for now.

see https://groups.google.com/forum/?fromgroups=#!topic/symfony-cmf-devs/ikJ9jpomzaQ and https://groups.google.com/forum/?fromgroups=#!topic/symfony-cmf-devs/otAht7VS04Y

i have classified this as a bug as it makes it impossible to use our menu bundle in larger setups.

i was able to reproduce this issue. it doesnt really cause a lot of problems with a few nodes, but obviously if you start having a large tree, then its a big issue.

we need to investigate this .. i am not yet sure if it just loads content/routes that are referenced in the menu or if it just flat out loads everything. i would doubt that.

potentially its impossible to prevent loading all the menu items with KnpMenu 1.x, but can hopefully ensure that at least route/content nodes are lazy loaded. i dont know the menu system that well yet.

@uwej711 you havent run into this issue yet?

@petesiss's app is suffering severely because of this, even with node caching enabled

@dbu i could come by fribourg the second half of next week if necessary.

"require": {
    "symfony-cmf/menu-bundle": "1.0.*"
}

gives this error:
The requested package symfony-cmf/menu-bundle could not be found in any version, there may be a typo in the package name.

we could allow to configure defaults for things like childrenAttributes on the ContentAwareFactory. in knp menu, those must be set on the objects, but as menu items are created programmatically, that is ok. for the cmf however this would mean storing data into the database even if it is a default.

i would draw the line at saying we can configure defaults for the things mapped in phpcr that will be applied to all menu items being created if they do not themselves provide that option. any logic to only apply the defaults to some menu items will require to extend the factory in your project, otherwise it gets too complex imo.

alternatively we could think of having MenuItemEnhancer like we have RouteEnhancer...

As a marker indicating that only Menu nodes can be created below.

support to render the menu root as home link. the workaround is rather complicated: https://github.com/symfony-cmf/symfony-cmf-website/pull/6/files#diff-34

if we render the root, it would in html live separated. should we have a feature to squash it into the first level? => check what KnpMenu currently does and see if its just a documentation issue.

We need to invent a "Mutable Associative Array type to handle key => value array fields.

Currently you can only specify a URL, Route Name, or Content Document (or rather all three at the same time if you like - would be neat to have a radio selector there, but thats another issue) and you cannot select a document from the route subtree.

I am having problems with the admin interface for Menu's which is caused by the fact that you have to specify a menu_basepath and the current MenuNodeAdmin enforces that all MenuNodes are within this base path.

For example you may want to create menu nodes that live inside your regular document structure (as a child of a page called About in /cms/simple/about). I may want to add a menu node here as a child which is a link to an external page. If I do this and I have the menu basepath set to /cms/menu then MenuNodeAdmin throw an exception when trying to edit that menu node because the basepath cant be found in its path.

I tried to solve this issue by setting the menu_basepath to /cms and now I am running another issue where the edit form doesnt work because the getMenuIdForNodeId method gets the wrong menu. I had created a separate menu for the footer in /cms/menu/footer (footer is the Menu). I added a child and it worked as expected but when I went to edit the child (/cms/menu/footer/foo) the function getMenuIdForNodeId returns /cms/menu instead of /cms/menu/footer. Obviously this would resolved if the menu_basepath was /cms/menu but then I run into the issue I mentioned above.

It seems the issue could be resolved by not requiring a menu to be in the menuRoot in the aforementioned method. Alternately the method could be modified to find the nearest Menu ancestor of the MenuNode.

It would also be nice if you could specify the menu basepath which could be used as a default for where menus are placed when creating new menus but should not prevent you from placing menu nodes in other valid places. The system would need to be able to handle MenuNodes for which a MenuId does not exist because they are not part of a menu.

The issue is primarily in the MenuNodeAdmin->getMenuIdForNodeId method

MenuItems are now forced to have there path/id end wit the string 'item' by the filter attribute on the variable annotation:

/** @PHPCRODM\Children(filter="*item") */
protected $children;

What is the reason for this restriction?

In accordance with PHPCR-ODM naming - BC break, but makes sense?

we have a multilang.locales configuration in this bundle, but the locales are never ever used for anything anymore. the core bundle knows about the locales for the TranslatableExtension, the menu does not need to know the locales it seems.

same in content bundle symfony-cmf/content-bundle#60

For example, labelAttributres, routeAbsolute, etc.

If there is to be a dependency on sonata admin by default, then it should be stated in composer.

https://github.com/symfony-cmf/MenuBundle/blob/master/DependencyInjection/Configuration.php#L25

But I think actually it should default to false and the Sandbox should specifically set it to true if it is using it. Though actually now I think of it, is it right even to have any specific mention of a specific admin system? These bundles should be completely free of any ties to specific admins shouldnt they?

I remember discussing this with both @uwej711 and @dbu but can't remember where.

Anyway IIRC the idea was to have a special MenuDirectory document or similar which can be mapped to only allow child items of type Menu.

In addition we would be able to assign a specific icon to this folder type.

once breadcrumb is merged in knp menu, we should look at how we do breadcrumbs and document it for users. see
KnpLabs/KnpMenu#45

https://github.com/symfony-cmf/symfony-cmf-website/blob/master/src/Cmf/MainBundle/Menu/MenuProvider.php

https://github.com/symfony-cmf/symfony-cmf-website/blob/master/src/Cmf/MainBundle/Resources/config/services.yml#L3

(see comments at bottom)

Reminder to add a publish workflow voter that checks if the content of a menu item is also published.

Originally reported by @wjzijderveld in ContentBundle

The embedded route and menu forms for the content admin are great!

But for multilang menu nodes, it doesn't work to well.
It only shows one node, even though I have already a menunode in 3 locales (with fixtures in this case).

I'll try to look into it myself if I find the time, but wanted to have a reference over here.

This is now a problem for MenuBundle as the admin logic has moved into the Extension.

Global issue: symfony-cmf/core-bundle#81

i think the logic to determine whether a menu node is the current menu node should be refactored out into strategies that are injected into the factory. there is already quite some logic in there, and we realized in projects that we would need other logic (in our case we have news items that have no menu item themselves, but we want the menu item of the parent news overview to be the current. there could be many cases, thus the strategy approach)

this would mainly affect https://github.com/symfony-cmf/MenuBundle/blob/master/ContentAwareFactory.php#L75 - i wonder why we just pass the name but not the MenuNode to createItem. is that an interface defining it or could we add it?

the strategy could get the current request and the menu node i think. for simplecms, the current check would be something like menunode === request->attributes->get(contentKey) ...

i can do that, but wanted to ask for opinions here.

it would be nice to have a way to just render the current submenu if there is one of that navigation depth. we can render from a menu item but not a a menu node. and we don't have a decent way to know how deep in the menu tree we currently are

this is the hack i came up with to get it going. but this is pretty ridiculous.

{% if cmfMainContent is defined and cmfMainContent.menus|length > 0 %}
    {% for menu in cmfMainContent.menus %}
        {% if menu.id|split('/')|length == 6 %}
            {% set main = menu.parent.name %}
            {% set sub = menu.name %}
            <div class="related_items">
                {{ knp_menu_render(['main', main, sub], { 'depth': 1 } ) }}
            </div>
        {% endif %}
        {% if menu.id|split('/')|length == 7 %}
            {% set main = menu.parent.parent.name %}
            {% set sub = menu.parent.name %}
            <div class="related_items">
                {{ knp_menu_render(['main', main, sub], { 'depth': 1, 'currentClass': 'selected' } ) }}
            </div>
        {% endif %}
    {% endfor %}
{% endif %}

At the moment it is possible to crash Sonata by not specifying a parent or nodename

The document manager to use should be dynamically configurable. For example when multiple workspaces are used, it might be necessary to specify which document manager (usually linked to a specific workspace) should be used in certain situations (e.g. when editing or viewing).

This has already been done in RoutingBundle PR 97 and PR 99 and BlockBundle PR 54 and PR 66.

The 'standard' way of doing this has been to use set a ManagerRegistry property when constructing a class that needs a manager, and providing a setManagerName() method to change the name of the manager that should be retrieved from the registry.

In our current pprojects we have many menu items that have to be shown only to particular roles. How about a new document class - SecuredMultilangMenuNode with @PHPCRODM\String(multivalue=true) property $roles, and logic to render items based on roles?

Hi all,

it will be simpler to explain on an example

Menu: HOME | CREW | SHOWS
Url : / | /crew | /shows

These menuitems don't have any sub menuitem. Is it possible to mark SHOWS as active (CurrentAncestor) when page /shows/show1 is opened. Page show1 does not exist in menu.

function isCurrent inside manuitem.php only match full url with menuitem url

thx,
Milos

see https://github.com/symfony-cmf/cmf-sandbox/blob/master/src/Sandbox/MainBundle/Resources/views/EditableStaticContent/index.html.twig#L40

to better understand the concept of the menu system see:
http://cmf.symfony.com/slides/routingandmenu.html#1

to see the menu system in action see:
http://cmf.liip.ch/admin/bundle/menu/menuitem/list

The use case we came across is that your primary navigation has a top level link called Projects (which links to a ProjectController::listAction in a standard symfony 2 controller) and you want that menu node to have a child for each project in the database, with a link to its detail page.

I was able to hack something together by (overriding cmf_menu.provider.class parameter class of the MenuProvider)(https://github.com/symfony-cmf/MenuBundle/blob/master/Resources/config/persistence-phpcr.xml#L13). I could register my own menu provider but i couldnt remove the existing one and since the existing one always returned true for the has call for a phpcr menu mine would never get called. I dont think there was a way to set a priority on the menu provider (i could easily be mistaken /cc @stof). From my overriden MenuProvider class I could then add children to the menu but that requires knowledge of what order the menu items appear in or assumptions about the label or path in order to add Projects menu at a certain item. This was obviously a hack.

I am thinking of a special kind of MenuNode you can insert into the PHPCR street which could have properties that determine the id of a service to call to generate the menu or perhaps just the service id of a menu provider that could provide its menu. It could also have options for whether the menu provided by the configured provider should replace the existing node as a set of siblings or be added as children.

The project example I gave could then be implemented either by having a single top level MenuProviderNode configured to link to the Project::listAction controller and to add the provided menu's children to itself OR as a top level MenuNode (still linking to Project:listAction) with a single MenuProviderNode child that is configured to replace itself with provided menu.

I dont know if this is the best approach and it would require either that your MenuProviderNode was a service so you could inject a ProjectManager to retrieve the projects (which is probably bad for the same reason you dont inject services into Doctrine entities) OR the existing MenuProvider would be container aware and parse the menu it builds looking for instances of MenuProviderNode and calling some special method like processMenu(Container $container, MenuNodeInterface $currentMenuNode).

It would be best if the dependencies required for the provider node could be configured via the DI container instead of injecting the container, this is just the first solution I was able to think of.

I wanted to use the phiamo/MopaBootstrapBundle in conjunction with the symfony-cmf/MenuBundle. But, there is a slight problem, where the default CSS from MopaBootstrapBundle expects the menu to be a list with the class attribute set to "nav":

<ul class="nav">
    <li><a ...>...</a></li>
    ...
</ul>

It seemed to me at first, that the SymfonyCmfMenuBundle does not provide a way to set that class, so for me it looked like this per default:

<ul>
    <li><a ...>...</a></li>
    ...
</ul>

My first approach to solve this issue was to extend the given PHPCR menu provider in the bundle:

<?php

namespace Acme\Bundle\WebsiteBundle\Menu;

use Symfony\Cmf\Bundle\MenuBundle\Provider\PHPCRMenuProvider as BasePhpCrMenuProvider;

class PhpCrMenuProvider extends BasePhpCrMenuProvider {

    public function get($name, array $options = array()) {
        $menu = parent::get($name, $options);
        return $menu->setChildrenAttribute("class", "nav");
    }
}

and to override the default menu provider in app/config/config.yml like this:

parameters:
  symfony_cmf_menu.provider_class: Acme\Bundle\WebsiteBundle\Menu\PhpCrMenuProvider

By now, I am aware that there is a another approach to this problem, without the need to code anything: Setting the menu-root's children attribute "class" once to "nav" in the PHPCR storage backend.

For example like this:

        [...]
        $dm = $this->getContainer()->get("doctrine_phpcr.odm.default_document_manager");
        $menu = $dm->find(null, "/cms/menu/main");
        $childrenAttributes = $menu->getChildrenAttributes();
        $childrenAttributes["class"] = "nav";
        $menu->setChildrenAttributes($childrenAttributes);
        $dm->flush();
        [...]

But it took some time and "code surfing" for me to gain the understanding required to see that.

Maybe a tutorial, a small chapter in the documentation or a setting in app/console/config.yml for the default UL-class might help some other clueless guy like me next time? Or did I miss something obvious?

Currently menu nodes do not use their label field as the display field within Sonata Admin. This is because MenuNode does not implement __toString and the MenuNodeAdmin does not implement toString. The result is that the name field is being used which is generally all lowercase and does not match with other items when displayed in a tree.

I don't have a preference on which of these 2 approaches is used (__toString on MenuNode vs toString on MenuNodeAdmin) but if you guys do then let me know and I'll create a pull request.

Would it make sense to distinguish between the root node (the menu) and the menu nodes?

Doing so would enable us to list the actual "Menus" in the system in the admin interface:

-> Main Menu
-> Side Menu
-> Footer Menu

And perhaps then we can provide a dedicated interface for each menu (i.e. with drag+drop menu placement maybe) instead of a big list of nodes from all menus.

Currently the only way to reorder menu nodes is through the tree browser.

Tickets to be considered after 1.0

seems the PR for publishable and to move mappings to xml happened at the same time. the MenuNode still has bogous annotations on publishable and publishStart|EndDate and the xml mapping is missing for those. we have to move all to xml.

While I install knp-paginator-bundle few other bundles are updated. After update symfony-cmf/menu-bundle throwing me error

InvalidConfigurationException: The path "symfony_cmf_menu.multilang.locales" should have at least 1 element(s) defined.

Update packages

  - Installing knplabs/knp-components (1.1.2)
    Downloading: 100%         

  - Installing knplabs/knp-paginator-bundle (dev-master 0d719a9)
    Cloning 0d719a9bd6973bde1b10587fc2c85cf04c5e0e9d

  - Updating symfony-cmf/content-bundle dev-master (60b7193 => cfc7bd9)
    Checking out cfc7bd953490618ee29e3a15adedf4016e555a73

  - Updating symfony-cmf/menu-bundle dev-master (4d8a1b8 => e72d283)
    Checking out e72d28319994e638a8fa08e8237ac55c2f93fd88

  - Updating symfony-cmf/routing-extra-bundle dev-master (3af0d4c => 6dd5837)
    Checking out 6dd58373626dd9f4c1603ec04c0f14b720f33060

Help me solve the issue

should MenuNodeCommon not be called MenuNodeCommonAdmin??

the menu bundle should use the repository concept like the router does, to abstract from phpcr-odm specifics.

main changes in https://github.com/symfony-cmf/MenuBundle/blob/master/Provider/PHPCRMenuProvider.php and in DI

Currently you cannot use the PhpcrMenuProvider to load menus outside of the menu basepath due to https://github.com/symfony-cmf/MenuBundle/blob/master/Provider/PhpcrMenuProvider.php#L128

I would propose that since this code assumes you are providing a path relative to the basepath (ie "footer" would load "/cms/menu/footer") that if you provide an absolute path (starting with a forward slash) it should use the provided path without modification. This would allow you to load paths relative to the menu basepath by providing relative paths (no forward slash) and paths at any location by providing absolute paths (starting with a forward slash).

This would be a simple change and I'd be happy to PR if you are amenable. What I don't know is if this would break backwards compatability but I'm pretty sure it wont and in fact that the current code may have an issue where if you do provide an absolute path it will fail because its looking for /cms/menu//footer (note double slash). So this would also fix that issue.

this looks pretty bad (the current sandbox is still the same):
http://cmf.liip.ch/de/admin/bundle/content/multilangstaticcontent/cms/content/demo/edit

is there a way we can not have the admin extension trigger when embedding? i guess that is up to the extension itself to figure it out - should we adjust it? i guess we should also hide the name as its not editable anyways.

When you create a menu node, it can be of type "route" and point at a symfony route.

If the symfony route accepts parameters, I am not sure how you can go about setting those parameters on the menu node.

For example, if the route projects_by_category has a parameter named slug, how can you add a MenuNode that will link to this route with the slug parameter set to "foo".

It looks like the ContentAwareFactory already calls getOptions on the MenuNode when it is being created, so if that returned an array with the key routeParameters then those route parameters would be included in the url that is generated. It also looks like MenuNodeBase has a routeParameters member variable that is mapped as an assoc multi value field, so it looks like the only missing piece is a way to specify route parameters when editing a MenuNode.

Providing this functionality (editing a multi value phpcr field while preserving keys) is a more general question. Is there something in sonata phpcr admin that could be used for this? This also relates to a general question about how to map data via a symfony form when the property path would require multiple arguments when called. In other words I need to call $model->setRouteParameter('slug', 'value') rather than just $model->setRouteParameter('value')

It seems implementing the PWF interface is not enough for the admin to work properly.
I get the following error when trying to update a menuItem:

Neither the property "publishable" nor one of the methods "setPublishable()", "__set()" or "__call()" exist and have public access in class "Symfony\Cmf\Bundle\MenuBundle\Document\MultilangMenuNode".

Does anything speak against making menus nodes etc referenceable?

    <mapped-superclass
        name="Symfony\Cmf\Bundle\MenuBundle\Model\MenuNodeBase"
        translator="attribute"
        referenceable="true"
        >
 ...

I was tring to build a simple Menu Block referenceing to some menu item, so i could display a menu in some block somewhere but
Referenced document Symfony\Cmf\Bundle\MenuBundle\Doctrine\Phpcr\Menu is not referenceable. Use referenceable=true in Document annotation: testmenu

see the travis tests of the bundle
https://travis-ci.org/symfony-cmf/MenuBundle/jobs/10886858

note the test is now marked as skipped in master

This is just a reminder of possible problem when moving to KnpMenu 2.0 support.

PHPCRMenuProvider.php , approx. line 103
$menuNode->setCurrentUri($this->container->get('request')->getRequestUri());

the call will not work any more

see https://github.com/symfony-cmf/cmf-sandbox/blob/master/src/Sandbox/MainBundle/Resources/views/EditableStaticContent/index.html.twig#L40

Update the classes to conform to the CS

when upgrading, we need to refactor our parts (have our voter interface extend the knp voter and deprecate it) and keep a compiler pass that ensures BC for a while.

and let the admin see if its embedded. same as @EmmanuelVella did in https://github.com/symfony-cmf/RoutingExtraBundle/pull/77