Move admin/config/media/file-types to admin/structure/file-types

It's basically a clone of content types which is in structure. Why would it be different?

atm, i'm neutral either way. though i admit that i was originally caught off guard by the move, especially considering that from what i recall the #media section was made specifically with the media module in mind, though i'd have to dig up the original issue...

I agree with Bojhan. This totally belongs under configuration

Committed the attached.

Please use critical only for things which stop someone from using the module.
Thanks,
Jacob

Since this module has been in production for 30k people and there are thousands of postings on the drupalgardens.com forums and not one person has mentioned this in the past 6 months, I don't see this as "unable to use the module because they can't find this settings page."

Anyway, we take UX really seriously, and I would absolutely consider UX bugs critical if an important (80%) feature of the module was difficult to use / discover for a majority (51%) of the people using it. I bet 5% of the user base even goes to this page, and I imagine most of them can discover it, so I while I agree that moving it makes sense, I couldn't consider it critical.

Maybe other media module maintainers feel differently, but that's my take.

Where does it say that *all* IA bugs are critical in http://drupal.org/node/45111?

Critical
Critical bugs either render a system unusable (not being able to create content or upgrade between versions, blocks not displaying, and the like), or expose security vulnerabilities. These bugs are to be fixed immediately.

In Drupal 7 this also applies to test failures: we have a policy of a 100% pass rate for tests, so failing tests block all other development.

Major versions of Drupal core (like 6.0 or 7.0) won’t be released until all critical bugs are fixed. For point releases (like 6.1 or 6.2), critical bugs won't hold back a core release if a security update is needed.

In contributed projects, it is up to each maintainer how they handle the critical status.

Sorry for arriving here this late (I was redirected here after I opened #1165400: Move menu items from configuration to structure myself), but I strongly disagree with the decision made here.

Last week I have been playing with Media module, finding out what it does and how to use it. Having experience with D5 and D6, the knowledge that there are many similarities between file entities and nodes helped me to understand what I needed to do. However, new users will also quickly find out that there are similarities between nodes and media. Looking at the content section, Media follows the navigation structure of the Node module (/admin/content/node, /admin/content/media). That's why I also expected Media to follow the Node module in other parts of the administration menu.

Basically, the argument to move Media types to configuration is that it's used less often than Node types. I haven't seen proof for this statement. After a site is published, I don't visit the node type configuration pages often either. I don't see why I the Media type pages would be any different in that respect.

More importantly, the IA is not structured around the frequency of use to begin with. The IA is structured around meaningful topics such as 'content', 'structure' and 'people'; they are not called 'daily tasks' and 'initial setup'. The fact that some sections will be visited more often is a logical result of structuring by topic, but it should not be a goal in itself.

I would add that
"/admin/config/media/file-types/manage//fields"
page should show the name of the "file type" it deals with.

hm .... I have to agree with marcvangend. I remember the 2 days on IRC where I made a fool of myself wondering where these media files will be set up now, but it was already there. I think the most counting argument here is the "manage fields" and "display fields" feature which is 100% expected near to the pendants for content types. Even if it doesn't work yet fully, the admin structure shows where media and file_entity plans to go (hopefully) and this is definitely site structure and for the D6 users site building in mind, but not configuration settings, what is more about general settings of the site and some configurable modules.

And somebody who is using all the file types already provided will use this manage fields part for files very often.

Just weighing in on this. I agree with #11.

A pattern has been established in core that node entity bundles are configured in structure. Configuring a file entity couldn't be more analogous as an operation. By storing it under structure you are working with the user's mental model of how entities are configured.

I don't feel that the rationale of 'it is not used much' is really the guiding principle for the IA - if it was our main menus would be structured along the lines of 'most popular' etc.

I think this actually belongs to file entity

This patch just moves the menu items around.

Thanks Arthur. The patch looks good, I'll try to test it later this week.

I don't have a strong opinion here given that both arguments are valid:

1. Why muddy a menu items that houses everyday features like Basic Pages, Menus, Taxonomy and Views with 'preference-like' features that configure your site?
2. Conversely, why separate 'like' features that provide context in order to prevent muddying a menu?

Honestly, I think the catalyst of the problem is the IA itself. Config vs Structure vs Content continuously confuses both end users and developers. End users don't understand why some things are content where as others are structure, and developers aren't sure where users should interact with their module. Until this problem is solved, no solution is going to be ideal.

That said, I side on a solution that best maps to a long term strategy. In my mind, that long term strategy is one where 'Structure' is a thing of the past, and 'preference-like' features are grouped together. For me, keeping the location under config is a better long term plan. I hope and pray "structure' goes away in D8, and as such, it seems foolish to place it there. Doing so means in D8, people will again have to ask this question "where did media types go?"

I'm not so sure on this either. To configure user fields and how those fields are displayed, it's located under config, not structure. That said, it does seem to make more logical sense to put it where everything else puts their bundle admin screens.

Another possibility...

Move both Content types and Media types out of Structure and into Config. Under 'Content', create a "add a new content type" link. https://skitch.com/jeff.noyes/gsj4t/add-content-jeffer

Rationale:
1. We know from many usability studies that new users have no idea that you can extend Drupal's content types because adding new ones is not in the proximity of existing ones. Although we haven't done so yet, I have a high confidence level that adding such a link will bridge a major gap for new users.
2. Placing Content types and Media types both under config solves the relationship issue outlined in #11
3. Placing Content types and Media types both under config solves the issue outlined in #19 where Structure is muddied by everyday items (pages, views, taxonomy) with non-everyday-preference-like features (content types, media types).

Sorry, but this is not viable nor acceptable for Media or File entity to alter around the Content types menu...

Issue #1431688: Fields translation path exceeds the maximum menu parts has identified that we cannot continue to let this path live under admin/config and that moving to admin/structure would be an improvement with enabling translations of file entity fields.

So in other words, until the menu router system is more flexible, neither file types nor any type of structure item can or should live under admin/config.

Was actually planning to give moving file-types a go after I got the MSS feature done. Seems like an easy task for me to take on. Assign it to me if you think I'm up for it.

And yes, I do agree with those that says it belongs in Stucture and not Config.

Patch in #16 isn't working. The tabs doesn't render properly. Here is a new one that fixes that.

Any progress on this one?

The patch works, but the change requires a few cache cleaning/reloads for Drupal to stop throwing errors. So, the sooner we can get it committed the better.

It would be really good to maybe get Bojhan's opinion on this. We have lots of reasons why this 'revertion' is beneficial:

• People are used to configuring their entity's display and fields under 'Structure'. We've had more people get confused about where to go configure their file type displays now that it was under admin/config/media/file-types.
• The file_entity module now actually has file/%file pages that are visible to end-users unlike before.
• If we want to enable translation of file entities, we are unable to do so under admin/config/media/file-types because we will hit the 9 argument depth limit for menu router items. For example, admin/config/media/file-types/manage/image/fields/field_image_title/translate/fr is 10 segments.

@Bojhan: The patch isn't in. Adding/Managing fileds/displays for media has always been in Configurations.

As I see it:
Content = For content editors
Structure = For site builders
Configuration = Site administrators

For me, adding and managing fields and displays for the media types is a site builder task similar to working on the structure/display of content types and taxonomies. So, the logical place for doing the same for media types is in the Structure section, which is where the patch in #26 is moving it to.

Sure, we can fix the Drupal 8 menu router to have more than 9 path segments (and WSCCI likely fixes that for us), but for D7 we're locked in at 9, so I have to pull this trigger now otherwise we're blocking support for File translation. We can re-review this IA when we attempt to merge the file_entity module into Drupal 8.

The patch in #26 has been committed to 7.x-2.x: http://drupalcode.org/project/file_entity.git/commit/86ba3ff. Question is now do we back-port this to Media 7.x-1.x's file_entity? I'm inclined to say no because it's not a bug, but I'm also inclined to say we should for consistency with 2.x.

If its not a problem/bug for 1.x, then I see no reason to back-port. Also, there are so many other things that changes in 2.x so consistency is nothing to worry about :)

Release notes will need info about that clearing cache a few times and reloading pages might be needed. Was quite tricky to get it working without errors.

All you need to do is run update.php, even if there's no updates to run. That should move the menus without error.

Ahh, that's great. Good thing we got this patch in before rolling the "DrupalCon" unstable release then :)

Hi guys, you are saying Move admin/config/media/file-types to admin/structure/file-types as the subject title

also you attached patchs #26 , #6 and #16

how can i move the folders ? i don't have those folders in my drupal install folder !

again :

you are giving patchs, where to apply them ?

i need you guys give the complete path to the folder we are talking about, else if things are done in a different way, then can you say please how to do these things ?

Sincerely,
Azerttty

You do not need to actually move any files on your site. This is an menu structure change, not moving around actual directories.