Doing this inside Joomla has two problems.

• First JConfig is a simple class and get executed directly by some functions in Joomla. Adding a function to JConfig would cause problems with auto configuration systems.
• Adding a placeholder like "JPATH_BASE/administrator/tmp" wouldn't work because of the same problem above.

But you can create a defines.php in the root folder overriding the JConfig with a version that fit's your needs. Or rewrite the config on demand.

Doing this inside Joomla has two problems.

This is all clear. But the problem must be solved.

1. we need to solve the problem with the holder and the choice of path.
2. After that, the rest of the joomla features will adapt over time.
   . The main thing is to set the correct tone for using Factory::getConfig('tmp_path');

If you have a solution I'm happy to review it.

Just BTW: There are tools out there that help you to rewrite the configuration.php detecting the absolute paths automatically...

If you have a solution I'm happy to review it.

Variant of solution.
I came up with the perfect solution. The solution is very simple, and nothing will break. All functions will work as before.

class JConfig {
	public $tmp_path = __DIR__.'/tmp'?;
	public $log_path = __DIR__.'/administrator/logs';
	....
}

No methods or conditions. You don't need to upgrade classes framework.
However, you only need to upgrade the settings component.
In the control panel in the configuration component, you need to make a smart field where we enter the path.
If the path is left empty, the component will keep the $tmp_path path to the JConfig class relative by default to __DIR__.'/tmp'. But if you specify the path in the settings field, the settings component will write in JConfig class the absolute path '/server/user1/domains/joomla4/tmp';
.
I had other suggestions. But I refused them, because this is the best solution. It turned out to be simple and universal. However, all other methods do not need to redo the class reference.

<input placeholder="<?=__DIR__.'/tmp'?>" type="text" name="jform[tmp_path]" id="jform_tmp_path">

Not a practicable solution.
If you save the configuration in the back-end then the __DIR__ will be overwritten and you have the absolute path in the configuration.php.

Forget my last comment. I think you know that.

Any modules, any components, third-party plugins. Everything will still work. Nothing will change.
But the path will always be adaptive and universal.
If you want, write the path, and if you don't want to, use the relative default path.

Provide a pull request please to the 4.0-dev branch! Then anybody can test it. Also during updates and so on.
You have to implement your solution in the installation logic of Joomla 4.

BTW: I don't understand why some people give themselves a thumb-up ;-)

@HLeithner
... or could a change like this also go into J!3 staging branch?

It's great if it's in J3.
I don't understand much English. When I read comments and see a like(a lot of likes), then I select the comment and read the translation through Google Translator.
This way I draw attention to the message with a like and also analyze the text more carefully where there is a like.
I write texts through a translator.

@korenevskiy

You have to implement your solution in the installation logic

And also in the logic of save configuration

It's great if it's in J3.

Let's see what HLeithner will comment before you start and waste time in the wrong branch.

I don't know how to use GIT.
I can only put the corrected code in comments in one of the branches.

I don't know how to use GIT.

https://docs.joomla.org/Using_the_Github_UI_to_Make_Pull_Requests

Doing this inside Joomla has two problems.

@HLeithner, please read the simple and elegant solution to this problem in the text above.

I'm not so sure that it is so easy but I'm pretty sure it's not going in J3 because of the new input field. Maybe we get some opinions from @wilsonge and @mbabker ?

I'm not so sure that it is so easy but I'm pretty sure it's not going in J3 because of the new input field.

The new feature will not affect combat sites on J3.
Since all sites have an absolute path set in Config initially. Therefore, by adding relative path support, all previously existing sites will use the already set path as an absolute path.

I'm not so sure that it is so easy but I'm pretty sure it's not going in J3 because of the new input field. Maybe we get some opinions from @wilsonge and @mbabker ?

Well we might can add it into 3.10 and 4.x to keep them behaving the same when possible.

Well we might can add it into 3.10 and 4.x to keep them behaving the same when possible.

Please add tooltip for field in com_config components.
<input title="<?=$tmp_path?>" placeholder="<?=__DIR__.'/tmp'?>" type="text" name="jform[tmp_path]" id="jform_tmp_path">
This will allow you to see the full path in case the default path length doesn't fit in the view field.
The user can hover the mouse and see the full path for the default field.
It also allows the user to see the previous absolute path, in case they decided to change the current path but haven't saved it yet.

I think need

1. Insert a check in the doExecute method of the SetConfigurationCommand class:
   $options['tmp_path'] = $options['tmp_path']?: '__DIR__/tmp';"
$options['log_path'] = $options['log_path']?: '__DIR__/administrator/logs';

2.Insert a check __DIR__ in the model method that saves the file configuration.php

if(strpos($options['tmp_path'], '__DIR__')===0){
str_replace('__DIR__', __DIR__, $options['tmp_path']);
}

Allows you to write custom paths using relative paths.
I couldn't find the method of the model where settings are saved to a file configuration.php. I see my mistake, but I don't know how to write correctly.

2nd option.
Ability to process __DIR__ in the field.
Also solves the relative path problem.
PS JPATH_SITE in field.

Well since I was mentioned I'm ? here because it is a totally bad idea to try and parse these fields and turn absolute paths into relative things using either Joomla's own path constants or PHP magic constants, and try to reverse engineer those into something that can be appropriately edited in the UI.

Absolute paths are the best idea for these types of configuration. It sucks there isn't an easier way to go about it, but magic engineering to support PHP constants seems like it's going to create more problems than it fixes.

@mbabker You right.
An empty field is a good solution?

I would say the current status quo is the good solution. These types of paths should be configured as absolute paths, I wouldn't put an option in the system where someone can save the logs path as just "/logs" and it work correctly, nor would I try to create overly complex code to try and do string replacements of the generated PHP code for the configuration.php file (because it will spit "JPATH_ROOT . '/administrator" as an absolute path), nor would I try to create overly complex code to try and do string replacements of path constants when reading the configuration data into the admin form.

Yes, it is a pain to deal with when moving sites around between platforms, but it really isn't practical to try and change the handling of the configuration file in a way that makes relative paths a realistic option. If you want these types of relative paths, truthfully the most sane way to get them is to refactor Joomla's bootup sequence so it behaves more closely to that of WordPress' (where wp-config.php is actually executed on each request and isn't just a class that is included). But that also comes with a cost of removing configuration parameters from the UI. IMO the status quo is the best case scenario for the 80-20 rule.

IMO the status quo is the best case scenario for the 80-20 rule.

20% also a large number to add the relative path function.
It may be unnecessary to use constants in the field.
But using an empty default value will be enough.
My first suggestion was based on not writing in the "/tmp " fields, because it requires analysis. I suggested that if the field is just empty, it will already mean the path __DIR__/tmp.
20% of administrators is a big number, even 5% is also a big number.
PS. I suggest that when saving the configuration file, replace the empty value with __DIR__"/tmp".

To save time, this can only do this for J4.

Instead of doing this magic with constants I would suggest to create a bootstrap.php which create a JConfig class which serve your needs. In J4 we could check if JConfig already exists before we load configuration.php so your version is used.

Instead of doing this magic with constants I would suggest to create a bootstrap.php which create a JConfig class which serve your needs. In J4 we could check if JConfig already exists before we load configuration.php so your version is used.

@HLeithner
Great.
I originally had the same idea. But I thought that this method would slightly change the loading structure. And there is also the fact that some third-party extensions access the JConfig class directly without using JFactory::getConfig(). As a result the extension accessing the JConfig class directly will get the variable value not from a constant but only an empty value. A significant portion of extensions must account for this change. You can't force everyone to write code correctly.
.
But Your proposal is based on creating the right structure. The correct structure does not allow accessing JConfig values directly.
If I suddenly had to create a new CMS I would be based on bootstrap.php exactly As you suggested.
.
Why is JConfig NOT a static class? Are properties of this class allowed to have different values for different objects?. (these are rhetorical questions) We know that other configuration files must have different file names. Therefore, the properties must be static.

Beauty of the code JConfig::$host, JConfig::$user, JConfig::$passrowd. We see the ease of handling, JConfig::$temp, JConfig::$log.

We can do this check in bootstrap.php:
JConfig::$temp = JConfig::$temp ?: __DIR__."/temp";
JConfig::$log = JConfig::$log ?: __DIR__."/administrator/log";

How logical is it for framework to have constants
JPATH_TEMP and JPATH_LOG?

@HLeithner
Another possible method.
What if the extensions do not access the config, but the JPATH_THEMES and PATH_LOG constants. We don't need to change the structure at all.
There will be minimal changes.
To file defines.php.

$conf = new JConfig;
define("JPATH_TEMP", $conf->temp ?: __DIR__."/temp");
define("JPATH_LOG", $conf->log ?: __DIR__."/administrator/log");

This option is probably the simplest, lightest and most functional.
At the same time, every programmer will know that system paths are written only through constants.