Missing explanations

[r4fx]

Hi, yours extension looks very promising, thanks for your work and sharing.
I have some question at beginning.

During reading manual i read in configuration section

You can use the "extends" attribute ... See configuration examples how this is done.

but i can't find anything about that in examples.

Second thing, in extensions like cooluri or realurl the main configuration file is located in configured (from EM) location, how this is managed in network-uri ?

[thommyhh]

Hi Rafał,

unfortunately the documentation is not quite finished. I'm working on providing some more examples, using the "extends" property.

For registering a configuration you have to use the provided Nawork\NaworkUri\Utility\ConfigurationUtility::registerConfiguration method. Depending on which version you use (2.x or 3.0) you have to provide the hostname (2.x) or an identifier as the first argument. The second argument will the path, e.g. EXT:my_ext/.../. This is briefly described in the section below "Configuration" "Version 2.3 - 2.7" and "Version 3.0 and above".

We use an extension that holds the templates and configuration for a site, so we just put the call for registering the configuration in its ext_localconf.php

I hope this helps a bit. More examples are coming soon.

[r4fx]

We use an extension that holds the templates and configuration for a site, so we just put the call for registering the configuration in its ext_localconf.php

Isn't it a bit complicated for an integrators ? Can't it be configured from Extension Manager ?
For my testing purpose I placed the path to the configuration file in AdditionalConfiguration.php

$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['nawork_uri']['Configurations']['default'] = '/home/project/typo3conf/NaworkUriConf.xml';

Is it a safe option ?

[thommyhh]

One of the features of nawork-uri is, that you can have different configurations for different domains. Configuring this via the extension manager interface would be a mess, e.g. strange comma/colon separated strings with domains and config files. Therefore have we decided, that this is the most flexible and clean way to accomplish this task.

If that is safe? I would say no. It is not planned, but I can't promise that the location/mechanism how the configurations are handled internally will not change in the future, e.g. with new TYPO3 CMS releases providing better ways for this.

Even if this works now, I would not recommend it. The provided API would not change without further notice (e.g. new major version), but the underlying infrastructure might change in the future. Isn't there any file that is included after the extensions, or at least nawork-uri, are loaded, where you can place the method call?

[plojewski]

One of the features of nawork-uri is, that you can have different configurations for different domains.

How can I config this per domain?

[thommyhh]

Which version are you using? 2.7 or 3.0?

[plojewski]

2.7.5

[thommyhh]

According to the documenation (https://github.com/nawork/nawork-uri/wiki#version-23---27):
Use ConfigurationUtility::registerConfiguration($domain) where $domain is the host name you want the configuration to be active for. So, if you have, e.g. development, testing and live host names you need to register the configuration three times.

Or, if you like to do it your way, which I still cannot recommend:
$GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['nawork_uri']['Configurations']['{your-hostname-here}'] = '/home/project/typo3conf/NaworkUriConf{your-hostname}.xml';

[plojewski]

OK, thank you for explanation.

[SicorDev]

@thommyhh Could you now provide a working XML configuration using the "extends" Tag ?
We currently use one master configuration and now we have to copy the configuration multiple times for every domain, just to change a single TransformationConfiguration.

[thommyhh]

@SicorDev I will work on some more explanations.

This is how it should work: Set <nawork_uri extends="..."> to extend the whole configuration from your default. Then for the parameter you like to change, set <TransformationConfiguration extends="...">) to get configuration to override.

But: As I took a look in the code, it seemed to me, that this could not work. I will work on this as soon as possible. If you want to try to dig into this yourself, start in Nawork\NaworkUri\Utility\ConfigurationUtility::buildParametersConfiguration, ll. 607 - 703, where the "children" (single parameter configurations) are processed.

[thommyhh]

@SicorDev I added examples how the configuration inheritance could be used on https://github.com/nawork/nawork-uri/wiki/Configuration-examples.

This works in the current master. Could you try that and provide feedback. If this works as expected, I would then port the changes to back the 3.0 and 3.1 branches.

[SicorDev]

Sounds good, i'm going to test the master branch in our project and provide some feedback.

[SicorDev]

Just tested with the following 'extending' configuration:

<?xml version="1.0" encoding="utf-8"?>
<nawork_uri extends="Standard">
    <Parameters>
        <!-- Languages -->
        <TransformationConfiguration>
            <Name>L</Name>
            <Type>ValueMap</Type>
            <Mappings>
                <Mapping Value="4">
                    <Replacement></Replacement>
                </Mapping>
                <Mapping Value="0">
                    <Replacement>en</Replacement>
                </Mapping>
            </Mappings>
        </TransformationConfiguration>
    </Parameters>
</nawork_uri>

Works as intended, everything except the Language is used from the base configuration.
So far I couldn't find any problems with the new extend config.

I've cleared over 1000 lines of duplicate configuration with the extend option.