@alikon can you please have a look?

if i understand well seems to me more like a new feature than an issue

Changed Label as new Features go in J4.

if i understand well seems to me more like a new feature than an issue

It would seem that I am the only person to already be completely namespacing their component, that this issue has not surfaced before, but it is none the less a 3.9 issue. Not only are the discovery and loading of menutype/item configuration files and custom fields not working intuitively, they are not working at all without some level of core circumvention. The consequence is long after the views/viewname Folders should have been deleted because the views themselves are in other folders, these folders will have to remain for menutypes/-items to be resolved correctly. Long after the fields themselves have been moved their new directory they will remain without namespacing because they are otherwise unusable in both component and com_menu context.

1. Even using the metadata.xml which exists solely for com_menu to discover 'menutypes', which works, I have to circumvent the discovery and loading of 'items' because, even though they are semantically the same thing, configuring a 'type' does not give enough configuration information for an 'item' even if the implementation allowed for more. Specifically configuring the 'type' name makes the 'item' look in component/views/typename/ for the file metadata.xml, which is pointless on two levels. If I was using that path, Joomla would be able to find the 'types' anyways and I wouldn't need the metadata.xml to begin with. Beyond that, making the static file name have to be metadata, seems like a further step away from being configurable in a file that is only being accessed because of exceptional configuration. Either the options tag needs a path attribute or the option tags do, or both. The inclusion of a prefix attribute for the tags metadata, menu or options could also be used as to load the component autoloader so that changes to the FormHelper::loadClass function would then not be completely necessary. For me, the prefix attribute could even be a boolean true for the autoloader being in the same directory as the metadata.xml.

2. As for the custom fields, I cannot understand why namespaced fields should not be able to work under 3.9. I am not using the default 4.0 folder 'Field', but instead 'Fields' since I have more than one, but the form allows me to define a path and a prefix. With both of these pieces of information available, there is no reason why my field, or FieldField rather, should not be found and required.

com_menus, and other core components (and even library classes, sadly), expect certain files to be found at specific locations. They aren't coded to be able to hand processing over to another component or to use any custom file structure you can imagine.

What you are looking for is a level of architectural change that is going to require shipping as new features, and more than likely some form of B/C break in logic, which means shipping changes in 4.0. There is not a sane way to get what you want in 3.9.

com_menus, and other core components (and even library classes, sadly), expect certain files to be found at specific locations. They aren't coded to be able to hand processing over to another component or to use any custom file structure you can imagine.

While I will not dispute that Joomla has a lot of path expectations, there are means to supplement these expectations almost anywhere that can touch non-core code other than in com_menu.

In point of fact, a search for "function add[A-Za-z_]+Path" in my libraries folder had 35 results in 19 files... Only 12 of which belong to fof.

BaseController alone has $config indexes for base_path, model_path, view_path as well as functions to ~set these very same values: addPath, addModelPath and addViewPath. Here there is another bug where the model path is not set 'correctly' and consequently ignored in model creation. The great thing is that I can create an overwrite for this obvious bug, as well as most the smaller ones:

• where the path is configured but there is no corresponding namespace handling
• where the class name gets stripped of its slashes such as $viewName = preg_replace('/[^A-Z0-9_]/i', '', $name);
• where prefix handling was not implemented (most likely) because something that looked like it was already there such as $classPrefix = preg_replace('/[^A-Z0-9_]/i', '', $prefix);
• where Joomla's folder name expectations causes it to cut on a folder name $viewpos = strpos($classname, 'View') and ignore the obvious separator of a fq classname $viewpos = strrpos(classname, '\\') which for me results in fun 'classnames' like 's\HTML\ClassName'

The thing is I can overwrite all these bugs: inheritance is forgiving.

The thing that makes com_menus special is that, when it doesn't work, I cannot overwrite it.

I am forced to write/use a content plugin to hack it and, although it works, I would really rather not have to have another smaller repository to maintain another plugin to activate and order.

What you are looking for is a level of architectural change that is going to require shipping as new features, and more than likely some form of B/C break in logic, which means shipping changes in 4.0. There is not a sane way to get what you want in 3.9.

These statements confuse me.

On point of implementation, I made my suggestion very specific and it requires 0 architectural changes, solely a couple XML tag attributes in the metadata.xml and an implementation which uses them to discover menu item configuration files and load these files and the referenced custom fields within. Barring that using the existing path and prefix attributes in the menu item configuration to correctly load fields by using the attributes in combination instead of bluntly sequential. Neither would break anything or make anything less backwards compatible.

If you were referring to my referencing where com_menus looks for view specific metadata.xml files. I never said that it should stop doing so irregardless of its inherent pointlessness. The path and prefix attributes don't have to be set and Joomla can continue to look for them if the attributes are not set or the referenced classes/files/locations do not exist.

On point of design, if you were referring to my placement of the menu item configuration XMLs, I never even hinted that I wanted to force my file structure on the community.

3.x is feature frozen at this point. Adding attributes is architectural change, in this case adding a feature to support a pseudo addXXXPath type of thing for menu item XML files (and for the love of everything sane Joomla and its ecosystem need to stop relying on path prefix attributes which are glorified hacks because it refuses to embrace autoloading or proper service oriented architecture; in a proper architecture com_menus would attempt to call a method "owned" by the component to get the data it needs and not assume everything based on hardcoded path logic in a bunch of inflexible XML files).

3.x is feature frozen at this point.

I thought there would still be a 3.10 version at some point which would be directly migratable. I would have thought that they would have cleared up the namespacing by then since it seems to be part of the core of 4.0 and since my namespacing adventure has been going on a couple of months now I would have thought that they would want to make the transition for other developers as smooth as possible.

Adding attributes is architectural change ... for menu item XML files

Ok, I think you are saying that since it is XML and these would be new attributes, that would change its 'structure' and is therefore an architectural change. That sounds reasonable.

Can't argue with the rest. :)

Closing this due to not receiving required information to determine if this is a bug or not. If you feel this still needs review, please open a new tracker entry with as much information as possible to ensure it can be reviewed properly