Twig filter/method for generating phpcr URLs that work even if document is moved.

[benglass]

There should be a built in way to embed links/urls to other routes in the CMF into the body of a PHPCR document that can be resolved to the correct URL for the page whether the page has been moved or renamed. This is a feature that other CMS's have, for example in MODx you can have something like in your content

<a href="[~14~]">A link to page with id 14</a>

And the CMS will expand that to the correct URL for the page of that id. This allows the end user to change page URLs without having to update links throughout their site. This may be possible for any documents that use the referenceable mixin as they have a unique id.

Original discussion at symfony-cmf/simple-cms-bundle#77

[benglass]

@dbu It would be be able to handle both regular symfony routes and phpcr routes but I feel the client use case is primary to insert links to other cms pages. Inserting dynamic routes with parameters would require a complicated user interface wherein you could select possible parameters. This part of the feature would be most used by developers and perhaps could be achieved by allowing some subset of twig (for example path() or url() calls could be evaluated). Perhaps this could be used as the approach for both kinds of url expansion (phpcr and symfony routes). Then the functionality @uwej711 mentioned in symfony-cmf/simple-cms-bundle#77 (comment) could perhaps be made more robust so it could handle uuid instead of a phpcr path which is volatile.

In terms of handling situations where the cms user delete a page and recreates it elsewhere im wondering whether this is should be wrapped in with this feature or considered a separate enhancement as I do not think this is something most cms' handle.

[dantleech]

See also the RoutingAutoBundle for a different approach to this problem:

http://symfony.com/doc/current/cmf/bundles/routing_auto.html

Basically that bundle will automatically create routes based on given rules for a given Document (e.g. the Page). You can then, for instance, tell it to leave Redirect routes when the page is moved.

[dantleech]

As an aside, I was thinking that it would be quite simple to create a "SimpleCMS" using the RoutingAutoBundle and the original routing system (i.e. not having a custom RouteProvider etc).

[benglass]

Interesting, it seems the RoutingAutoBundle could potentially already address the requirement of automatically redirecting when a document is moved provided that the link pointed at the auto route and not the original document. Presumably AutoRoutes have uuids and could therefore be referenced in a link and parsed out in the way as any other phpcr document. We would just need perhaps a service that provides a list of pages from which the user can select when inserting a link in the wysiwyg. Whether this service loads autoroutes or documents would be up to the configuration, perhaps some kind of Interface could be provided for this and a few base implementations although it may be enough to simply allow the basepath to be configurable on a generic provider, which would load all of the routes found at that basepath.

[dantleech]

Not sure I understand fully - in what scenario would you want to "parse
out" an auto routes UUID from a link?

On Wed, Sep 25, 2013 at 12:12:03PM -0700, Ben Glassman wrote:

Interesting, it seems the RoutingAutoBundle could potentially already
address the requirement of automatically redirecting when a document is
moved provided that the link pointed at the auto route and not the
original document. Presumably AutoRoutes have uuids and could therefore be
referenced in a link and parsed out in the way as any other phpcr
document. We would just need perhaps a service that provides a list of
pages from which the user can select when inserting a link in the wysiwyg.
Whether this service loads autoroutes or documents would be up to the
configuration, perhaps some kind of Interface could be provided for this
and a few base implementations although it may be enough to simply allow
the basepath to be configurable on a generic provider, which would load
all of the routes found at that basepath.

—
Reply to this email directly or [1]view it on GitHub.

References

Visible links

1. Twig filter/method for generating phpcr URLs that work even if document is moved. #178 (comment)

[benglass]

I havent used the auto routing so perhaps im misunderstanding but i was thinking that if a user was editing a page in the backend and inserts a link they would be able to choose from a list of pages/routes generated by the cmf. When selecting one, it would insert some special format

<a href="%%%path55%%%">Link to doc 55</a>

I was thinking 55 would be the uuid of the document to link to in phpcr. If you are using SimpleCms the uuid might be an instance of Page from /cms/simple. If you are using AutoRouting perhaps its the uuid of an AutoRoute. What options are presented to the user in terms of links they can insert to existing documents would be determined by a basepath configuration or perhaps a service that provides a Tree of documents or something similar would could be used to build a select dropdown.

[dantleech]

Ah yes. Well, in that case if the original URL was "/blog/post-1" and it
was moved to "/blog/post-2" then the routing auto bundle would have just
dropped a redirect route at "/blog/post-1" (redirecting to
"blog/post-2"). So with that approach there would be no need to have a
subsitute.

But while thats great for URLs sent out by email etc. It is les good for
internal articles that we render, in which case some sort of thing like
you propose would indeed make sense.

On Wed, Sep 25, 2013 at 01:11:06PM -0700, Ben Glassman wrote:

I havent used the auto routing so perhaps im misunderstanding but i was
thinking that if a user was editing a page in the backend and inserts a
link they would be able to choose from a list of pages/routes generated by
the cmf. When selecting one, it would insert some special format

Link to doc 55

I was thinking 55 would be the uuid of the document to link to in phpcr.
If you are using SimpleCms the uuid might be an instance of Page from
/cms/simple. If you are using AutoRouting perhaps its the uuid of an
AutoRoute. What options are presented to the user in terms of links they
can insert to existing documents would be determined by a basepath
configuration or perhaps a service that provides a Tree of documents or
something similar would could be used to build a select dropdown.

—
Reply to this email directly or [1]view it on GitHub.

References

Visible links

1. Twig filter/method for generating phpcr URLs that work even if document is moved. #178 (comment)

[dbu]

i would propose that instead (or in addition to) an internal link target selector, we should also have a doctrine listener that finds link to the site domain and resolves the target path of a normal <a href="... with the router to detect the route / content document and replaces the absolute link with the phpcr path and the uuid.

having the user put a uuid or something as link target will not work in frontend editng with CreateBundle, as the filter is then already applied and the link transformed into the real link. on the next save in frontend, the id would get overwritten.

[benglass]

@dbu good point and i can think of other ways in which front end editing could cause issues like.

For example on our cms architecture we are not currently using the concept of a page being composed of multiple blocks (same with simple cms) so I implemented a twig filter which inserts dynamic calls to blocks based on a format.

<p>Some static content</p>
%%%sonata.block.service.foo &bar=`baz`%%%
<p>Some more static content

The %%%foo &bar=baz%%% would be replaced with the sonata.block.service.foo block service and called with the options array('bar' => 'baz').

This would be rendered by create as the final HTML output of the block and would be broken by front end editing. This approach is actually based on one that is written about in the docs of cmf block bundle at http://symfony.com/doc/current/cmf/cookbook/using_blockbundle_and_contentbundle.html#tutorial-block-embed

It makes me wonder about the approach of allowing users to editing filtered content through the front end as it could have a lot of potential issues similar to these which we cannot predict. Making it so users are editing the content that is stored in the phpcr (instead of the rendered content) may have other issues (we'd have to save the content and re-filter it and inject it into the space after editing).

1. Can we somehow mark parts of the content as non front-end editable?

<span class="no-editable">
The dynamically generated html
</span>

Not even sure this would help unless we then matched up the no-editable sections with the original content which seems messy and error prone.

1. Perhaps we can just allow the developers to disable front end editing on a page by page basis
2. The doctrine listener for the create cmf that converted site URLs (such as /foo/bar) back into uuid's would solve the issue for these URLs but not for embedded blocks or other dynamic content.

Putting all your content into a collection of child blocks can sidestep the issues of the dynamic content a bit.

For me I think it would be an acceptable solution if I could just disable frontend editing of some pages and if the edit button just took users to sonata admin page edit for those pages but id love to hear other folks' thoughts.

[dbu]

i think the url is a very basic and thus special case where a back-and-forth conversion would make sense.

setting a part non-editable will not help, its still part of your wysiwyg blob that gets stored back into the db. what the embed block thing could do would be to have the filter render something around the magic tag that allows a listener to remove the rendered stuff and restore the call (unless the frontend editor goes destroying that something while editing, but then screw him). something like <div cmf-block-render="{eventual:parameters}">.... this concept could be applied to any filter thing somebody comes up with: if you provide a filter, you should provide a listener as well.
each filter you activate is going to cost you. listening on save operations should be comparably cheap as its not happening that often. and anyway is not more expensive than rendering the page.

deactivating frontend editing on a per page basis should become possible at some point. you definitely can do it on a per template basis by not rendering the createjs annotations. but once we have fine grained permission management, we need more. right now we just don't render the create.js inclusion if you are not allowed to edit (based on a role). anyway, this topic belongs into CreateBundle... for the OT i would vote for listeners to convert things back.

[dbu]

btw, as we already have the block twig filter, can you open an issue on BlockBundle explaining what was missing from the provided filter? could we extend the filter to be able to do what you want? or is it a very special case?

[benglass]

@dbu perhaps this can go into block bundle but the reason I created a separate filter was that I am not embedding blocks that are stored in the database. These are service oriented blocks that are not about there being editable content stored in the cmf. They are basically just standard sonata blocks and I want to render them inside a cmf doc.

The main missing feature (which could certainly be added to block bundle) would be the ability to specify parameters in the embedded call. This is key for my use case where you are listing projects (or perhaps showing 3 featured products in which case we want the options of feature=1 and limit=3 in the embedded call). Ill move the discussion over there and see if there could be some enhancement to block bundle to suit this.

[benglass]

@dbu I have moved the block discussion to a new issue symfony-cmf/block-bundle#143

[benglass]

@dbu so at this point it looks like we can move forward with adding the following

1. A twig filter that converts uuids to URLs

   What format should it be looking for? I like [uuid] as its very simple. It seems it might be worthwhile to come up with a standard format for dynamic content like this in documents which may be replaced. MODx uses brackets as does wordpress. Alternately it could be something that looks like like twig {{ path('', { phpcr_uuid: 55 }) }} and then we could actually parse it out and call the path function which could be made to support phpcr_uuids which would have other advantages.

2. A doctrine preUpdate listener (or listener to a specific CreateBundle event that is fired before save would be better since its only for front end editing) that converts relative URLs or absolute URLs containing the current domain to the format we decide on.

I would say the other items we discussed such as parsing dynamic sections should be treated as a separate issue.

[dbu]

1. sounds great. i would not go into sub-rendering twig, that is quite tricky business as it can lead to security issues. lets go with [uuid].
2. i would do a doctrine listener. then the backend editor can also insert his links as absolute links without troubles. easier than writing plugins for all the wysiwyg editors and make source editing people figure out uuid's. i wonder if we should store the uuid of the Route or of the Content. when generating it does not matter as long as the content is still implementing RouteReferrersInterface. maybe lets go for route? as even if you move it and we lose it, there might still be a redirectroute at that place.

magnolia cms stores not only the uuid but also the path. this has the benefit that after migrating content or destroying and rebuilding a content, things still work. the uuid has the benefit that after moving, things still work. so ideally we would also store both path and uuid to have a way to survive as much as possible.

the filter for dynamic sections should go to BlockBundle, created symfony-cmf/block-bundle#144 for that.