Flexibility to change url paths (page manager integration)

I just came to this issue from #1278544: Change the path for the Create Entity. Like the poster in there I don't think ECK should be making assumptions about what aspects of an entity are public vs private vs admin etc. Those choices are surely driven on a purely case-by-case basis. Note, I also just found http://drupal.org/project/entity_path - not sure if/how it works, but sounds like it could be used to adjust the entity paths on a case by case basis.

Has this been completed? I'm willing to put some time into coding this feature but I'd need to know what the status is.

Alright, we've got some dev time scheduled in the first weeks of november to get this integrated into a client's site.

I'll post updates as I go.

Thanks.

Alright I've installed the branch of the module and from the looks of it there are a few issues up-front:

1) The Bundle list pages have broken menu items (the local tasks don't work) and are displaying on the wrong paths (you get all tabs for all bundles on a single page, see screen shot below).
2) No page manager page for the entity view is created
3) Invalid paths are generated for each instance of an entity bundle (i.e. after saving, when you go to view the entity, the path is invalid).

On the bright side
1) The add/edit/delete paths show up

I'll report back once I get more into it.

So far CTools and the menu system are kicking my butt. I'm not entirely convinced this can work with ECK (main issue being the paths don't have to_arg functions for each entity type i.e. _to_arg($arg)) since the entity definition is generated through generic templates and no named function exists to load the entity (similarly to how %node works in the menu system).

I'll keep at it and post some updates.

Alright

The first big hurdle has been to get the requirements of the menu system and CTools context stuff to work.

The only solution I was able to come up with is giving site builders the option to set the %wildcard value in the menu paths for entities defined by ECK

Ex:

function foo_menu() {

$items['myentity/mybundle/%mywildcard'] = array(...);
}

Preferably ensuring that myentity and mywildcard at the same value (haven't tested with different values yet, though there may be some assumptions about that fact in CTools since most entities use that pattern e.g. node_load, user_load with $items['node/%node'], $items['user/%user'])

The reason this is important is because CTools (and therefore page manager) use the _load function to build out the context required to override pages.

What this patch does is add a field when creating a new entity type to specify the wildcard. By default, ECK simply uses "%" in paths. This is still the default functionality. So this won't affect existing entities (or at least it shouldn't).

Now the down side. The user does have to manually write the myentitytype_load and myentitytype_to_arg functions either into an existing module or add it to their exported feature containing their entities. ECK can't generate these functions automatically. PHP only supports anonymous function generation. So that means someone would have to add this to a module installed on the site

function myentitytype_load($id) {
  $entity = entity_load('myentitytype', array($id));
  
  return $entity ? reset($entity) : FALSE;
}

function myentitytype_to_arg($arg) {
  // The logic in here can vary, this is a simple example
  return (empty($arg) or $arg == '%') ? 0 : $arg;
}

Now the reason the patch is so big is because ECK assumes that all $id values passed to functions from the menu system are only the integer id values of the entity. Not an entity object. Since the menu system, given the two functions specified above, will take care of loading the object into the context (which is what we want), ECK has to check if it's receiving just the id or an entity object or an array of entities throughout the code. Which is what I've done.

Anyways, it's a big patch, probably some bugs in there. But this is the first step to getting page manager to not only override the admin pages (edit, delete) but the entity view pages as well.

Feedback appreciated!

Btw, with the patch above and the accompanying myentitytype_load function, you can override ECK pages with Page Manager Existing Pages (woo!)

New patch with some updates. Adds preliminary features integration and removes some dpms.

The previous patch used $entity->type instead of $entity->entityType() in many locations. Which means it only worked for entities were the entity type matched the bundle name. This patch fixes that.

However the titles on the entity forms at "admin/structure/entity-type/%entitytype/%bundle" aren't being displayed and they throw warnings.

This patch fixed the problems with the previous patch.

The entity list and view pages work and the warnings are fixed.

Alright, so for anyone not following along, here's the history of what this patch fixes.

The root problem with ECK and Page Manager is in the way Page Manager uses the magic wildcards in entity urls. For instance, node URLs, as defined in their entity definition reside at /node/%node. When the menu system loads that url, it uses the wildcard string + _load to load a node object into the context (not to be confused with any context module). So when you visit /node/1 Drupal calls node_load(1);

With ECK, by default it generates urls like /entity_type/bundle_type/% where % is the entity id. But this is a generic placeholder, not a magic wildcard. This patch allows you to define what the % should be for your entity urls. So you can setup /myentity/bundle/%myentity which would trigger myentity_load(1) when visiting /myentity/bundle/1.

As mentioned in #8, you will need to add the function myentity_load function somewhere in code. I would suggest that when exporting an entity from ECK, that the exported feature module generate that callback. Which can be done by extending this patch (it's on my todo list).

Once in place, we'll have full support for Page Manager and then we can get into display layouts using Panels, DS, as well as the original issue of getting custom paths configured for your entities (since it will only be a matter of including the magic wildcard into a menu path).

Thanks.

My first (and second) attempt to get all this to work was with some kind of generic callback so that you didn't have to put in custom code. But because of the way the menu system works I can't see how.

Option 1:

Generalize auto-load wildcard %eck

The menu system receives a request for /myentity/mybundle/%eck where %eck = 1. This calls eck_load($id) where $id = 1 which needs to load an entity object with that id. So the eck_load function would look like:

function eck_load($id) {
  return entity_load_single($entity_type, $id);
}

Problem is, there's no way to know what $entity_type should be. That isn't passed as an argument. Which brings us to option 2

Option 2:

Generalize auto-load wildcard %eck and using path to determine entity type

Same setup as before, except we read the /myentity/mybundle/%eck path and extract the entity type "myentity" and pass that into the function.

function eck_load($id) {
  $path = current_path();
  $entity_type = |regex to get entity type here|;
  return entity_load_single($entity_type, $id);
}

But then you're accepting entity type from the path and making a pretty big assumption. Not a good idea. So then we have option 3.

Option 3:

Dynamic php function

Using the create_function to create the load functions for each entity defined in eck. The issue here is getting the menu system to call that function. You can't name the function in the expected pattern of "wildcardname_load" which means it won't get called. We could create the function and call from a generic callback but that loops us back to Options 1&2.

So with that said, if you know of any other options or possible ways to make the load callback generalized that be great! Maybe some hidden magic in the CTools package but I haven't seen anything.

In any case, let me know what you think.

So that would be option 2.

We would need to know which entity type is being requested and have the menu system send the entity type along. Which would mean the entity type has to be part of the URL. So long as that's an acceptable requirement we can try that out.

It just means the base url for entities defined by ECK are set and cannot be changed. Only given aliases (I.e. path auto style overrides). Which I think is fine since that's how node works anyways.

I can update and give it a shot. At the same time, what about dropping the bundle from the URL? Instead just have myentitytype/id ?

I suppose that would be a separate issue...

I'll change this to needs work.

Alright. I've got an updated patch which uses the load arguments. However, it seems pm_existing_pages and/or the default context plugins for ctools don't handle load arguments very well (i.e. the contextual object doesn't load).

But this patch does get the object loaded by the menu system properly. Next is to figure out what ctools needs to handle object loading with arguments.

Note to anyone trying this patch: This doesn't work with page manager yet.

Oh, you may want to reevaluate the eck__entity__view, eck__entity__edit, etc... functions as they now receive an object instead of the id. You might be able to trim down the number of arguments those require and the extra calls to load the entity type and such (but that's a different issue ;-)

I've opened a core issue to get the additional info required for context loading arguments. Hopefully it makes it's way in.

I did some testing and it seems that ctools can't load any object into context from the menu if there are additional load arguments (I tried other modules like Image and attempted to override those page with pm existing pages)

#1977852: Add load arguments to the list of returned values from _menu_load_objects().

In the mean time if I think of another way for ctools to get at this data properly I'll supply a patch.

The admin objects in ECK are entities themselves correct? (Bundles, entity definitions) and are of a fixed entity type. Meaning they have a simple load callback.

Meaning so long as the changes above affect those entities and their menu items the admin pages could be able to be overridden. But I think the patch needs to be extended to include those entities (never tried it/don't remember writing that).

I'll give it a shot.

Following with great interest. Any further progress, @minorOffense, I can help test?

Without that core patch I don't see a way to get this to work.

Sad trombone. Ok. With everybody all D8-crazy who knows when it will get reviewed... sigh.

It's how Page Manager Existing Pages overrides paths and loads the objects so Page Manager can get context about the object being displayed. Otherwise, you override the path and a whole lot of nothing happens. That patch to core let's the menu system give extra information about the arguments being passed (which is required for page manager existing pages to tell what two arguments ECK is using when generating menu paths).

If we move away from using Page Manager Existing Pages and wrote a custom CTools plugin I would assume it could work. Though I've never written one nor do I know what type of plugin would need to be written (the names of those plugin types are super non-descriptive). So long as the plugin can tell page manager what type of entity it's trying to load (i.e. set the context properly) it should work fine.

So not all hope is lost, but maybe the way I initially approached it isn't possible/practical at this point.

It's how Page Manager Existing Pages overrides paths and loads the objects so Page Manager can get context about the object being displayed. Otherwise, you override the path and a whole lot of nothing happens. That patch to core let's the menu system give extra information about the arguments being passed (which is required for page manager existing pages to tell what two arguments ECK is using when generating menu paths).

If we move away from using Page Manager Existing Pages and wrote a custom CTools plugin I would assume it could work. Though I've never written one nor do I know what type of plugin would need to be written (the names of those plugin types are super non-descriptive). So long as the plugin can tell page manager what type of entity it's trying to load (i.e. set the context properly) it should work fine.

So not all hope is lost, but maybe the way I initially approached it isn't possible/practical at this point.

small change on description

Use page manager existing pages

I have done something but didnt fully work. For example the selection rules for every variant didnt work..

It works sort-of, but doesn't provide much context so I ended up having to use a bunch of views in the panel that grabbed the page argument from the URL.

Related: #2155565: Add Panelizer support to ECK

I hope this is an appropriate issue for this patch. I feel like there are two issues happening in the thread. If I'm mistaken I will gladly open a new issue for this request.

The patch adds support for all ECK entity types into page manager for panels layouts to override the layouts.

To customize the URLs for each entity I use the module Pathauto Entity.

Patch exposing eck entity pages to page manager from #43 re-rolled against 7.x-2.x HEAD

Thanks @ekes.

Patch in #45 is working for me.

eck_pm module has the very useful context eck add form which is the reason i prefer this module at the moment