Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
After thinking upon different options, I believe that setting up our menu items through page manager will give us the most flexibility and usability. Work is being done in the branch page_manager of the repository
Comment | File | Size | Author |
---|---|---|---|
#45 | eck_page_manager-1373466-45.patch | 6.88 KB | ekes |
| |||
#43 | eck_page_manager-1373466-43.patch | 9.67 KB | KeyboardCowboy |
#21 | 1373466-21-page-manager.patch | 11.38 KB | minorOffense |
#20 | loadex.tar_.gz | 586 bytes | fmizzell |
#12 | 1373466-12-eck-menu_wildcard.diff | 20.48 KB | spotzero |
Comments
Comment #1
mrfelton CreditAttribution: mrfelton commentedI 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.
Comment #2
minorOffense CreditAttribution: minorOffense commentedHas this been completed? I'm willing to put some time into coding this feature but I'd need to know what the status is.
Comment #3
fmizzell CreditAttribution: fmizzell commentedthe page_manager branch is working, so you should be able to check it out and see what is going on, but I will give an overview from what I remember.
From what is there, you are able to create pages for all the operations supported by eck on any path through page manager (add, edit, delete, view, list).
The code is capable of bundling (grouping functionality around a page). So if you put a view page for an entity at /mypage/%entity_id, you could also attach an edit page to that path (/mypage/%entity_id/edit).
I believe all of that was working correctly, but it can probably use some cleaning up.
The last part that I remember working on, was the capability to replace list pages with views. That seems outside of the scope of this issue and should probably be deleted or moved from that branch.
So I think generally, things were pretty close. The only part that I had not figured out is how to deal with the default pages that are created when a new entity type or bundle is added (should those be page manger pages, or leave them as they are, and give the user a chance to deactivate them? I did not go through the mental exercise of how that last part should work)
Comment #4
fmizzell CreditAttribution: fmizzell commentedComment #5
minorOffense CreditAttribution: minorOffense commentedAlright, 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.
Comment #6
minorOffense CreditAttribution: minorOffense commentedAlright 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.
Comment #7
minorOffense CreditAttribution: minorOffense commentedSo 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.
Comment #8
minorOffense CreditAttribution: minorOffense commentedAlright
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:
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
andmyentitytype_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 siteNow 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!
Comment #9
minorOffense CreditAttribution: minorOffense commentedBtw, with the patch above and the accompanying myentitytype_load function, you can override ECK pages with Page Manager Existing Pages (woo!)
Comment #10
minorOffense CreditAttribution: minorOffense commentedNew patch with some updates. Adds preliminary features integration and removes some dpms.
Comment #11
spotzero CreditAttribution: spotzero commentedThe 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.
Comment #12
spotzero CreditAttribution: spotzero commentedThis patch fixed the problems with the previous patch.
The entity list and view pages work and the warnings are fixed.
Comment #13
minorOffense CreditAttribution: minorOffense commentedAlright, 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.
Comment #14
fmizzell CreditAttribution: fmizzell commentedI appreciate all you work. If eck could define a default wildcard like %eck_entity, and then be able to determine what is the right entity to load in eck_entity_load(), do you think that would be a better solution than defining a wildcard for every entity type that we want to use with page manager? You have already done a lot of work so I don't want to undermine your effort, and I am not sure how difficult it would be, but the advantage I see is that all entity types will automatically have page manager support without the need to configure things and then write a custom load function. Let me know what you think.
Comment #15
minorOffense CreditAttribution: minorOffense commentedMy 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:
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.
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.
Comment #16
fmizzell CreditAttribution: fmizzell commentedI did a little research and in the documentation for hook_menu (http://api.drupal.org/api/drupal/modules!system!system.api.php/function/...) it talks about a 'load arguments" key that can be defined in the array for each menu item. We have the entity type information when we are generating the menu, so we could pass that info to the eck_load, or eck_entity_load callback so we can do what you are suggesting in option 1. I have not tried it to see if it would work, but I think is worth exploring.
Comment #17
minorOffense CreditAttribution: minorOffense commentedSo 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...
Comment #18
minorOffense CreditAttribution: minorOffense commentedI'll change this to needs work.
Comment #19
fmizzell CreditAttribution: fmizzell commentedI don't believe the entity type has to be part of the url. I will test an example and post it here for reference.
Comment #20
fmizzell CreditAttribution: fmizzell commentedHere is a tiny module showing how we can use completely arbitrary paths, and a single wildcard to load entities of different entity types. Let me know what you think.
Comment #21
minorOffense CreditAttribution: minorOffense commentedAlright. 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.
Comment #22
minorOffense CreditAttribution: minorOffense commentedOh, 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 ;-)
Comment #23
fmizzell CreditAttribution: fmizzell commentedok, i just commited the patch to the 7.x-3.x_permissions branch (I was dealing with paths so i figure I would add this since it is the more correct way of doing things). I guess any further work should be followed from that branch since as soon as I finish the permissions work it will be merged into the 7.x-3.x branch.
Comment #24
minorOffense CreditAttribution: minorOffense commentedI'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.
Comment #25
fmizzell CreditAttribution: fmizzell commentedSo the main issue here is the ability to override our eck existing pages, but there shouldn't be any deterrent from finalizing the functionality that allows "new" pages related to eck entity administration from being created. Is that correct?
@minorOffense does that functionality interest you or where you focused on the overriding capabilities only?
Comment #26
minorOffense CreditAttribution: minorOffense commentedThe 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.
Comment #27
fmizzell CreditAttribution: fmizzell commentedActually they are not. Entity types, bundles and properties (the other eck objects) are not proper entities.
Comment #28
Renee S CreditAttribution: Renee S commentedFollowing with great interest. Any further progress, @minorOffense, I can help test?
Comment #29
minorOffense CreditAttribution: minorOffense commentedWithout that core patch I don't see a way to get this to work.
Comment #30
Renee S CreditAttribution: Renee S commentedSad trombone. Ok. With everybody all D8-crazy who knows when it will get reviewed... sigh.
Comment #31
fmizzell CreditAttribution: fmizzell commentedIf ECK provided a mechanism to accomplish this, independent of page manager, would that be helpful? Or is this issue becoming more about integration with panels, and other merlin of chaos technologies :) ?
Comment #32
minorOffense CreditAttribution: minorOffense commentedIt'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.
Comment #33
minorOffense CreditAttribution: minorOffense commentedIt'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.
Comment #33.0
minorOffense CreditAttribution: minorOffense commentedsmall change on description
Comment #34
TheMGamer CreditAttribution: TheMGamer commentedUse page manager existing pages
Comment #35
fmizzell CreditAttribution: fmizzell commented@TheMGamer, the way ECK is implemented, it does not work, or have you done it?
Comment #36
TheMGamer CreditAttribution: TheMGamer commentedI have done something but didnt fully work. For example the selection rules for every variant didnt work..
Comment #37
Renee S CreditAttribution: Renee S commentedIt 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.
Comment #38
DamienMcKennaRelated: #2155565: Add Panelizer support to ECK
Comment #43
KeyboardCowboyI 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.
Comment #45
ekes CreditAttribution: ekes commentedPatch exposing eck entity pages to page manager from #43 re-rolled against 7.x-2.x HEAD
Comment #46
darren.fisher CreditAttribution: darren.fisher commentedThanks @ekes.
Patch in #45 is working for me.
Comment #47
fmizzell CreditAttribution: fmizzell commentedIs this module (https://www.drupal.org/project/eck_pm) meeting what we wanted to accomplish with this issue?
Comment #48
fox_01 CreditAttribution: fox_01 commentedeck_pm module has the very useful context eck add form which is the reason i prefer this module at the moment