fix FieldAPI admin UI paths [#1363600]

The field UI admin paths for data tables are all messed up and appear in the wrong place.

In particular, for each data table you get a set of tabs 'Manage fields' and 'Manage display' but they ALL appear together at the main data table admin page.

I've tried several approaches and I can't figure out a way to get it to work right. Posting this in the hope brighter minds than mine can find a solution :)

My code comments perhaps best explain the problem and what I've tried:

      'bundles' => array(
        $entity_type => array(
          'label' => $table->title,
          'admin' => array(
            // This is fraught with difficulties with the menu system tabs.
            // We can't give 'admin/structure/data/edit/%data_ui_table' as a
            // path, because that would cause all data table entities to store
            // the same router path and thus only the last entity defined here
            // would win.
            // On the other hand, giving the table name literally as $table_name
            // messes up the tabs, as the nearest tab parent found for this is
            // the base data admin tab set at 'admin/structure/data' rather
            // than that for the table.
            // In *theory*, the tab parentage should be fixable by tweaking it
            // in hook_menu_alter(), but that doesn't seem to be working.
            // In short, ARGH! and please file a patch if you can make sense of this.

            // This does not work because multiple entities store the same router path!
            /*
            'path'      => 'admin/structure/data/edit/%data_ui_table',
            'real path' => 'admin/structure/data/edit/' . $table_name,
            */

            // This messes up the tabs.
            'path' => 'admin/structure/data/edit/' . $table_name,

            'access arguments' => array('administer data tables'),
          ),
        ),
      ),

Comment	File	Size	Author
#10	data-fix-fieldapi-admin-paths-1363600-10.patch	1.67 KB	imclean
#8	data-tabs.jpg	14.97 KB	imclean
#1	data-fix-fieldapi-admin-paths-1363600-1.patch	1.76 KB	B-Prod

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

B-Prod CreditAttribution: B-Prod commented 4 September 2012 at 19:44

Status:

Active

» Needs review

File	Size
data-fix-fieldapi-admin-paths-1363600-1.patch	1.76 KB

I think this should fix your issue as desired. The patch simply use table name as bundle and provide a bundle argument.

Comment #2

joachim CreditAttribution: joachim commented 23 September 2012 at 07:29

Could someone with more than one table give this a try?

Comment #3

imclean CreditAttribution: imclean commented 11 October 2012 at 23:48

Status:

Needs review

» Needs work

This causes some unnecessary tabs to be added to the table edit section: Manage Fields, Manage Dependencies and Manage Display.

Comment #4

imclean CreditAttribution: imclean commented 16 October 2012 at 05:32

This works well with multiple tables. With the changes above, I've left the bundle name as $entity_type as this seems to be how entities does things when there's only one possible bundle.

Comment #5

B-Prod CreditAttribution: B-Prod commented 21 October 2012 at 22:01

@imclean So it works as expected (RBTC) or not?

Comment #6

imclean CreditAttribution: imclean commented 22 October 2012 at 00:20

Sorry, it still has the extra tabs which cause errors when clicked on.

It's not perfect but does a better job than the current system with multiple tables. I'm using it and am ignoring the extra tabs. Is this a major issue?

Comment #7

B-Prod CreditAttribution: B-Prod commented 23 October 2012 at 17:21

No, it isn't.
Could you attach to thjis issue a screenshot of the extra tabs you speak about?

Comment #8

imclean CreditAttribution: imclean commented 25 October 2012 at 21:52

File	Size
data-tabs.jpg	14.97 KB

The "Manage Dependencies" tab was added by Conditional Fields module but "Manage Fields" and "Manage Display" I believe are added by Field UI.

Comment #9

B-Prod CreditAttribution: B-Prod commented 27 October 2012 at 17:54

Status:

Needs work

» Needs review

I understand now what you were speaking about. But these tabs are not unnecessary, since the data entity is defined as fieldable. That's why the "Manage Fields" and "Manage Display" tabs are automatically added by the field UI module.

So if you do not want such tabs, the question is: should the data entity be fieldable?

If not, setting the 'fieldable' key to FALSE in the entity info hook will remove the tabs.
But if adding fields to data entities make sense, those tabs seem necessary to me. Removing them may be done through a hook alter function but it is, in my opinion, a bad practice.

Please mark this issue as RBTC if you agree that it solves the initial issue.
And for the fieldable state of the data entity, feel free to open a separate issue, keeping in mind my explanations above.

Comment #10

imclean CreditAttribution: imclean commented 31 October 2012 at 21:44

Status:

Needs review

» Reviewed & tested by the community

File	Size
data-fix-fieldapi-admin-paths-1363600-10.patch	1.67 KB

Sounds fair to me. What are your thoughts on using the entity type as the bundle name? This is the default if the bundle name is left out of $info['entity keys'] when there can be only one bundle per entity.

This keeps the entity type as the bundle name but other than that is the same as #1.

Comment #11

imclean CreditAttribution: imclean commented 31 October 2012 at 21:46

Status:

Reviewed & tested by the community

» Needs review

"Reviewed and tested" means it's what I've been successfully using. Not sure I should set that on my own patch.

Comment #12

imclean CreditAttribution: imclean commented 2 November 2012 at 05:07

Semi-related to this, currently each table is a separate entity type. Would it make more sense to have an entity type of say "data_table", with each table being a bundle?

Although this may not work as the base_table would be different for each bundle.

Comment #13

joachim CreditAttribution: joachim commented 2 November 2012 at 07:56

> Semi-related to this, currently each table is a separate entity type. Would it make more sense to have an entity type of say "data_table", with each table being a bundle?

That's a whole new kettle of fish -- please open a new issue for that!
(Though I think the answer is no -- because a) that's the way core drupal works, and b) different tables may have different database fields)

Comment #14

imclean CreditAttribution: imclean commented 6 November 2012 at 21:33

A table callback could possibly get around that but as you say, it's not how Drupal works.

B-Prod, joachim, what are your thoughts on #10? Does it make sense to keep the bundle name the same as the entity type?

Needs review

» Reviewed & tested by the community

No matter with that, this is only design.

Comment #18

joachim CreditAttribution: joachim commented 21 November 2012 at 08:36

Status:

Reviewed & tested by the community

» Fixed

Patch certainly moves the menu items to the right place.

I'm getting a ton of other errors when I try to adopt tables, but since the patch can't be responsible for those, I'm going to assume that's just me not setting up my tables properly.

Thanks everyone!

Issue #1363600 by B-Prod, imclean: Fixed Field UI admin paths for data table entities."