What is the use case of this? I honestly have not seen a case where you need that variable?

@wilsonge

At the end of the series of (successful) PRs we should be able to set any desired folder name for administrator directory

Personally I would prefer that this PR is closed. When the code is created to fit the stated aim it can be included with that code. Right now it is useless and just confuses people.

@brianteeman @wilsonge If this constant is not available it would not be able to update the target code. How else do you suggest the code be updated without this?

We are not saying you wont use it.
We are saying that when you have the rest of the code written that will use it then add this code then
Right now it has no purpose

I don't understand either. Why can't you just redefine JPATH_ADMINISTRATOR directly?
JPATH_ADMINISTRATOR_DIR would be a wrong name anyway since it doesn't contain a path, just a subdirectory name.
Maybe elaborate more what your goal will be?

Since there are so many places over the cms where this will be used. Putting all changes together will make the PR big. Subsequently making it tough to test for other. I plan to implement in steps.
If you want I can at least add one usage in this PR itself.

However, as discussed with @chrisdavenport at #JWC15 he suggested not to put everything in a single PR as it will make it less understandable.

@Bakual I am open to the constant's name.

@Bakual Redefining JPATH_ADMINISTRATOR won't help as it is the entire physical path. But there are several places where just the directory name is required, such as relative paths or urls.

And, as I said I am open to the constant's name.

But there are several places where just the directory name is required, such as relative paths or urls.

I guess most of them could be fixed by properly using JPATH_ADMINISTRATOR.
When it comes to URLs, the constants are the wrong approach. It should be better part of JURI. But then I'm not aware of a place where we hardcode link to the administrator.

The biggest hardcoding I see is with the addfieldpath defined in the form XML. Not sure how you would want to fix those.

I have already done that addfieldpath defined in xml. This would be in the next PR.
I agree to the JUri thing you said.

I guess most of them could be fixed by properly using JPATH_ADMINISTRATOR.

They are too many places to do an explode over JPATH_ADMINISTRATOR and then use it. Code would be too much complicated, I think. Suggest!

@Bakual I had proposed one way to sort the addfieldpath with #4294. If you feel this is a good way to do it I will redo that PR

@Bakual Please check the other PR #8722 for said JForm fix.

I'd prefer the approach from @dgt41 here over running preg_replace which will imho create confusing behaviour.

@bakual The people dealing with these codes are developers after all, this is not that confusing. It just loads the file from administrator directory of Joomla! That's being translated to the configured name always.
PS: Yes, it makes the word administrator a reserved keyword in that context. But I don't see anything wrong with this.

If you specify a hardcoded path somewhere and it magically ends up something else in some instances, it will be confusing. You will have to search and track down the responsible code. It may also produce side issues if someone uses that word for another path for whatever reason.
What is wrong with using a predefined addfield path which will work in most cases? Many 3rd party extensions fail anyway since they will not use that new constant/API/whatever to detect the administrator. So we're mainly talking about core here. With Joomla 4 we could go a better way of course.

Compatibility with any 3rd party extension is a different issue, that's why we use deprecation procedure and fallback measures. If a user is using any such extension he always have the option just don't customize the folder name and Joomla is always shipped with the default value 'administrator'.

About the magical translation, I'd say their is no magic. Every developer out there can currently only use this word for administration directory only... No choice here. Well after this patch that would be again only the administration directory but with the variable name auto computable.
A developer is always supposed to consult the docs, which we'd be updating anyway.
The bottom line is a developer must not presume a fixed value for this directory.

I don't expect this major change in a minor release too. Its long way to go before we finally add this as a customizable parameter in Global Configuration. May be 3.6 (preferably) or even 4.0. But rest of the core must be ready by the time.

What is wrong with using a predefined addfield path which will work in most cases?

Sorry, what did you mean by this?

Before we go any further - is a change like this even going to be accepted
in the 3.x series
I've never seen any benefit to being able to move the admin folder

On 17 December 2015 at 21:12, Izhar Aazmi notifications@github.com wrote:

Compatibility with any 3rd party extension is a different issue, that's
why we use deprecation procedure and fallback measures. If a user is using
any such extension he always have the option just don't customize the
folder name and Joomla is always shipped with the default value
'administrator'.

About the magical translation, I'd say their is no magic. Every developer
out there can currently only use this word for administration directory
only... No choice here. Well after this patch that would be again only the
administration directory but with the variable name auto computable.
A developer is always supposed to consult the docs, which we'd be updating
anyway.
The bottom line is a developer must not presume a fixed value for this
directory.

I don't expect this major change in a minor release too. Its long way to
go before we finally add this as a customizable parameter in Global
Configuration. May be 3.6 (preferably) or even 4.0. But rest of the core
must be ready by the time.

What is wrong with using a predefined addfield path which will work in
most cases?

Sorry, what did you mean by this?

—
Reply to this email directly or view it on GitHub
#8721 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Technically, you may say there is no benefit. I'm not sure yet. But why we people at Joomla think way more technically and too less about the end user preferences.

Many of my clients have put us down for ours being just too techy. What's wrong in going flexible? I promise millions of user will be happy to see this change. And we aren't losing anything in performance.

It may be possible to add into a 3.x release. But if Joomla 4 ends up with one entry point (one application) for both site and admin, then this would be a useless PR in the end.
Not sure what is planned currently (if anything) in this regard.

I've never seen any benefit to being able to move the admin folder

I don't see a benefit either. There may be a weeny bit more of security when the administrator isn't a well known URL, but it's security by obscurity which never really works reliable. There are much better ways to secure the administrator folder, eg a password protected folder.

I promise millions of user will be happy to see this change.

I doubt it's even hundreds. It's for sure not millions.

We don't know what's coming when. But, it should be updated if found useful. Even though something is deprecated or something, it should continue to function correctly and should be considered until it is removed.

@Bakual I'm not going to get picky about the number :-)

Do see the use case for this 1+ on closing

Consider this in line with the other changes in the product to not use hardcoded stuff:

• not using hardcoded id for Super User
• not using hardcoded username admin for Super user Suggest to commit!

@rdeutz: Make up your mind! Either you DON'T see the use case and close or you do and commit.

@rdeutz I'm confused. Did you mean merge and close? Or just close?

@sovainfo Correct! Hard-coding should be avoided if ever possible.

@izharaazmi just close

I'm just going to be honest. It's as much of a charade to suggest that the CMS can function with custom paths for every part beyond the root path as it is to suggest the CMS truly is multi-database friendly. I get people think obscure security methods like renaming a directory is such a cool thing to do, but frankly, so much gets broken if you attempt it it's truthfully better at this point to reverse course and hardcode some of the base paths to make sure users are unable to do something like move the administrator or plugins directories (both of which theoretically can be done because of the constants).

Please elaborate on what else gets broken, so we can fix those bugs as well.

Files extensions (which is also the way Joomla core gets updated). Without introducing a massively complex XML element syntax or a lot of magic regex parsing because Joomla assumes a path prefix of plugins will always mean JPATH_PLUGINS, someone using files extensions to place directories and files at specific paths which are prefixed as constant paths (admin, plugins, templates, etc.) will end up in a world of trouble. And I'm using that notion right now in a couple of extensions to provide layout overrides for different templates as standalone packages. https://github.com/BabDev/Podcast-Manager/blob/master/files_podcastmanager_hathor/podcastmanager_hathor.xml is one manifest that would break massively (actually two issues would crop up, first the administrator path prefix resolving to JPATH_ADMINISTRATOR then administrator/templates resolving to whatever JPATH_THEMES is defined as for the admin application (which is different than the path it is defined as in the site application).

@mbabker Thank you for that response, appreciated.
@izharaazmi Do you have solutions for those rookie mistakes?

@mbabker Thank you very much for your time to elaborate the possible issues in such detail. It would be my pleasure to address each point with my limited understanding.

...get people think obscure security methods like renaming a directory is such a cool thing to do ...

I personally don't think this to be a security improvement either. It's more of a user preference. Lately, around 10-12 clients have asked me to remove that administrator word from their url because they just don't like it. I had to do for few of them with hacks, that I least prefer.
Few of them told me that they won't like the e.g. publishers to feel like they're into administrator section. I say it concerns them just for what they actually see.

...to make sure users are unable to do something like move the administrator or plugins directories...

I agree. But renaming the plugin directory or not (or even having one) is not of any concern for the users (website owners esp.). That is meaningful only for the programmers – who know that it is required for the whole application to run. The rest users just see index.php or not even that.
As a developer most of us (talking about average programmers) would love if they get a chance to just hardcode everything. But ah, that's not happening. So that does not apply for plugins, libraries, modules, components or templates directory. It matters for administrator though.

...Without introducing a massively complex XML element syntax or a lot of magic regex parsing...

Introducing a standard XML syntax would be a better approach, but we should also put some B/C workaround. We can go with this approach in some major release such as 4.0.
Talking about the regex parsing, it is not an issue if we document it on the docs pages that a prefix of administrator or /administrator in a manifest file would automatically be translated to the correct backend directory name as configured. No developer would need to make any changes in their installer manifest.
Additionally, we don't need to bother about accidentally replacing /administrator with our new value as from a programmer's view using /administrator for something entirely different in the same context would always cause conflicts (Think if the user does not use this customisation feature at all).

...because Joomla assumes a path prefix of plugins will always mean JPATH_PLUGINS, someone using files extensions to place directories and files at specific paths which are prefixed as constant paths (admin, plugins, templates, etc.) will end up in a world of trouble.

As I mentioned above, it is not much important for a common user to rename plugins, templates etc directories as they practically never see them. So this should not be any trouble if we keep this limited to administrator directory only.

And I'm using that notion right now in a couple of extensions to provide layout overrides for different templates as standalone packages. ... is one manifest that would break massively...

Your notion is perfectly fine with this patch. I tested it by installing pkg_podcastmanager_2.2.0.zip and files_podcastmanager_hathor_2.2.0.zip and everything was installed correctly.
I tested it trice. First without this patch, second after this patch but still keeping the default name administrator and next with custom name power. No files were missed or misplaced during the installation.

I am now going to commit and PR all my changes together so that people can test it as a whole. Previously I was trying to put changes in small chunks assuming it to make tests faster. But I see it is causing more confusion.

@sovainfo Yes, I do. The whole patch is on its way for everyone to test. Thank you.

The admin directory should not be treated as a special case. Anything with
a path constant should be able to me moved in theory without breaking
Joomla. For example, some devs would like to be able to move everything
outside of the web root except for web assets (index.php, media dir,
etc.). Just because the admin directory is the one most users will see
doesn't mean that is the only one that should be treated as a special case
that can be renamed.

On Saturday, December 26, 2015, Izhar Aazmi notifications@github.com
wrote:

@mbabker https://github.com/mbabker Thank you very much for your time
to elaborate the possible issues in such detail. It would be my pleasure to
address each point with my limited understanding.

...get people think obscure security methods like renaming a directory is
such a cool thing to do ...

I personally don't think this to be a security improvement either. It's
more of a user preference. Lately, around 10-12 clients have asked me to
remove that administrator word from their url because they just don't
like it. I had to do for few of them with hacks, that I least prefer.
Few of them told me that they won't like the e.g. publishers to feel
like they're into administrator section. I say it concerns them just
for what they actually see.

...to make sure users are unable to do something like move the
administrator or plugins directories...

I agree. But renaming the plugin directory or not (or even having one) is
not of any concern for the users (website owners esp.). That is meaningful
only for the programmers – who know that it is required for the whole
application to run. The rest users just see index.php or not even that.
As a developer most of us (talking about average programmers) would love
if they get a chance to just hardcode everything. But ah, that's not
happening. So that does not apply for plugins, libraries, modules,
components or templates directory. It matters for administrator
though.

...Without introducing a massively complex XML element syntax or a lot of
magic regex parsing...

Introducing a standard XML syntax would be a better approach, but we
should also put some B/C workaround. We can go with this approach in some
major release such as 4.0.
Talking about the regex parsing, it is not an issue if we document it on
the docs pages that a prefix of administrator or /administrator in
a manifest file would automatically be translated to the correct backend
directory name as configured. No developer would need to make any changes
in their installer manifest.
Additionally, we don't need to bother about accidentally replacing
/administrator with our new value as from a programmer's view using
/administrator for something entirely different in the same context would
always cause conflicts (Think if the user does not use this customisation
feature at all).

...because Joomla assumes a path prefix of plugins will always mean
JPATH_PLUGINS, someone using files extensions to place directories and
files at specific paths which are prefixed as constant paths (admin,
plugins, templates, etc.) will end up in a world of trouble.

As I mentioned above, it is not much important for a common user to rename
plugins, templates etc directories as they practically never see them. So
this should not be any trouble if we keep this limited to administrator
directory only.

And I'm using that notion right now in a couple of extensions to provide
layout overrides for different templates as standalone packages. ... is one
manifest that would break massively...

Your notion is perfectly fine with this patch. I tested it by installing
pkg_podcastmanager_2.2.0.zip and files_podcastmanager_hathor_2.2.0.zip
and everything was installed correctly.
I tested it trice. First without this patch, second after this patch but
still keeping the default name administrator and next with custom name
power. No files were missed or misplaced during the installation.

[image: 1]
https://cloud.githubusercontent.com/assets/6706189/12005956/1f2f30fe-abe5-11e5-82be-da696cf533bf.png
[image: 2]
https://cloud.githubusercontent.com/assets/6706189/12005957/1f313d72-abe5-11e5-9c27-74f8beff0292.png

I am now going to commit and PR all my changes together so that people can
test it as a whole. Previously I was trying to put changes in small chunks
assuming it to make tests faster. But I see it is causing more confusion.

@sovainfo https://github.com/sovainfo Yes, I do. The whole patch is on
its way for everyone to test. Thank you.

—
Reply to this email directly or view it on GitHub
#8721 (comment).

Yes, theoretically and technically that is absolutely nothing different. It would be great if we can do that for all those constants.
But practically, we need to satisfy our clients first and foremost, so I came up with this change. We may later work on others too if we feel like.

Also instead of using those regex everywhere we may abstract the logic in some suitable functions. Suggestions for improvements are always welcome.

But practically, we need to satisfy our clients first and foremost,

While that is true, not everything a client wants is a wise thing to do. Sometimes it's our job to educate them instead.

Personally, I don't like regex solutions. Most of the time they look hackish to me.
I would try to solve this with Joomla 4.0, where we could work toward a good and clean solution. Adding this into 3.x quite sure produces side effects and/or needs code which you don't want to touch ever again.

Trust me, we do educate people. But few things they feel annoying such as index.php in url, we made it possible with sef-rewrite, session sharing for administrator and site we did with 'session_name' in configuration and many things.
If they ask us something that's totally irrelevant we can certainly convince them, else we need to comply.

The regex solution may be mostly hackish but not always. Here they are to allow current implementation where the developers are allowed to use hardcoded string inside manifests. This is a workaround for B/C. I have used the regex at exactly 10 places (1 of which was already there) that can be reduced to 1 by abstracting it. And that would not be something

which you don't want to touch ever again.

We can improve that as and when we provide some standard approach for the developers in some major release.

My big thing against a partial implementation anywhere is you introduce inconsistent behaviors. From 1.6 to 3.4, the extension install adapters were massively inconsistent with the order of operations or even using install scripts. And that arguably should be a piece of API that should have been consistent from day one given how widely used it would be. I don't mind working through things in bits and pieces, but in the end of something is merged, it should be with full support and not just "well you can move the admin directory but good luck with anything else".

Moved to the PLT list for a decision.

In my opinion, even if the cms itself uses non standard code, we should fix it. Let apart the 3rd party extension. This is one more step towards standard code within the cms. This will encourage the 3rd party developers to write compliant code.

Either way we still support them with default value of this configuration. If a user intends to customize he need to check for the compatibility of used extensions from relevant sources.

One idea that I see better is to allow this customization through configuration.php file for now and hide from global configuration page. This way only pro users will be able to use this. Meanwhile others get time to fix their extensions code. We may make the field visible in J3.6 global configuration.

Have an idea how can solve JForm problem, and maybe other related

Not found that it was mentioned,
In theory it can be solved with custom wrapper http://php.net/manual/en/class.streamwrapper.php
so we can have 2 wrapper site:// and admin:// and use them in the form addfieldpath eg addfieldpath="site://components/com_example/model/form/blabla.xml"
addfieldpath="admin://components/com_example/model/form/blabla.xml"

easy

And seems use the custom wrapper more flexible than use the defined constants, because it more easy to define the variable with path:
$path = JPATH_SITE . 'path/to/some/file.txt'; - it cannot be used in XML or JSON
vs
$path = 'site://path/to/some/file.txt'; - can be easily used everywhere

I think we really need to consider to use the custom wrappers instead of (or additionally to) define the constants, at least for Joomla 4.0

Of course it require more work than just tricky preg_replace (at least need to write the class for each custom wrapper)

ps. and to be honest, I still not understand why we need JPATH_ADMINISTRATOR_DIR, JPATH_ADMINISTRATOR should be enough for everything.

@izharaazmi @Fedik I am totally against this hardcoded part in the XML. I prefer the option to a known scaffolding for the component/modules/plugins/libraries where the fields are simply inside a directory named fields. That was my intention with #4294. The only problem is that even if that PR was accepted and addFieldPath was deprecated the actual use will not come before v4 where the function will be removed. There is no easy way out when there is a B/C promise...

Also if we standardise the scaffolding of the component/modules/plugins/library then the part admin/site is way to easy to handle, I guess

hardcoded part in the XML

Use the costume wrappers is not hardcode
Maybe need just more time to get the idea, and count all profits from it

btw, my suggestion is "Not a new idea" ... it already used in the wild by another CMS(s)

@dgt41 Your PR is absolutely a nice addition. It gives the module/plugin/template developers (component developers already have one) a defined place to put their field classes.

But sometimes one may need to reference a field class defined in other component from a custom plugin. How do you suggest that to be handled?

Assume I have a module say mod_xyz in which I use a custom field that is defined in some other component say com_xyz. How would I?

@Fedik I think using JPATH_ADMINISTRATOR only won't help as it is the entire physical path. There are several places where just the directory name (such as administrator) is required instead of the full path /users/izhar/public_html/joomla/administrator. Examples are the relative paths or urls.

If we want to get rid of JADMINISTRATOR_DIR constant we might need to use basename(JPATH_ADMINISTATOR) everywhere, or not? Any suggestions are always welcome!

Examples are the relative paths or urls

For this JUri::base(true) always helps, for me.
I think enough use basename(JPATH_ADMINISTATOR) only once in JUri::base() https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/uri/uri.php#L148

hm, but if you need get admin path from site instance (or vise versa) then maybe will need something like JUri::baseSite() JUri::baseAdmin()

In case of use the custom wrapper it could be JFactory::getStreamWrapper('admin')->getRelativePath() of course getRelativePath should be implemented in the Custom wrapper class for admin:// wrapper

@Fedik Correct. You edited

However, we don't need the two methods JUri::baseSite() and JUri::baseAdmin(). The JUri::root() does it for site and we can have JUri::admin() or JUri::administrator() for backend.
This can bring peace to many hardcoding around.

I like the idea of having the custom stream wrapper. But right now, B/C?

I like the idea of having the custom stream wrapper. But right now, B/C?

Good question
I am not sure.

and I just noticed there alredy something https://github.com/joomla/joomla-framework/blob/staging/src/Joomla/Filesystem/Stream.php

I am still to this partial change. Also remember something here, your earlier claim:

The people dealing with these codes are developers after all

The folks who are developing extensions in Joomla are more often than not following a book or copy/pasting code snippets together. No offense to anyone reading this comment, but there are a lot of extensions written by folks who really don't grasp Joomla's API or PHP all that well. Magic acts like your regex's are only going to confuse folks. Even moreso if they run extensions that actually use the administrator directory for any reason.

Actually, for that argument alone, it would be next to impossible to introduce any type of configurable file path into the CMS before 4.0. You will break extensions if you put something into the UI that lets the user arbitrarily rename a directory. Heck, as is, this patch can't be tested successfully. Your method of letting a user put a custom directory name into the global configuration then expecting a user to use a FTP client or SSH console to physically rename the directory means as soon as someone clicks the save button their installation is fatally broken.

I said it earlier, and I'll expand on it now. A partial solution for directory renaming should not be entertained. A full proposal MUST be presented as to how the CMS will deal with ALL constant defined paths (and how those paths can be different between applications, such as JPATH_THEMES or JPATH_COMPONENT) and the mitigation plan for extensions to be able to cope with this change. The proposal can be worked on in bits and pieces (i.e. continue going with just focusing on JPATH_ADMINISTRATOR, then when a working solution is reached, then move on to something else until you have all of them covered), but it should not be accepted in a work-in-progress or partially implemented state.

Lastly, don't over complicate things. You don't need streams to accomplish the admin:// or site:// prefixing either. Look at any FOF2 extension and how they load layout files (BTW the method that does it uses those prefixes).

This was discussed within the PLT and we decided not to add the supposed constant. I am closing this PR.

@Fedik I was not much aware of the way of implementation for stream wrapper
when I said I like the idea. But I see it requires a lot of stream handling
methods which is not required here.
So I suppose instead of stream we can use those prefixes in the XML and
parse it to get real path using some replace or regex replace.

In this case stream does not fit as of my opinion. Let's see what others
say.

Oh well, this was already closed. Thanks folks!

Yes, the FOF kind of implementation is much better than the stream wrapper stuff.

Look at any FOF2 extension and how they load layout files

is there a quick example? at least the component name, file where to look ... I am too lazy to search

https://github.com/akeeba/release-system/blob/2.5.1/component/frontend/views/category/tmpl/default.php#L24 and trace your way up the stack as needed.

@mbabker thanks!