New Feature: Exclude resource alias from child URIs

[bertoost]

This can be helpful when you have a container just for site-working purposes, like grabbing it's child resources. For example:

Footer pages

• Sitemap
• Privacy statement
• Disclaimer
• Conditions

In this case you get an automated alias like "footer-pages/sitemap.html" or "footer-pages/disclaimer.html". This is unwanted in this case, because you don't want "footer-pages/" in your url. Of course you can use "freeze uri" function on every child, but when you a have a container with a lot of children pages and a lot of children-children pages that's a hell of a job. In that cases it's easier to turn a parent to be excluded in child paths.

I already have this working; I tried to send a PR but cannot get only those commits to be a PR. Please look at these two commits...

https://github.com/bertoost/revolution/commit/4323cfdbdb9afca3ff23d30faf0492e524b57faa https://github.com/bertoost/revolution/commit/1a9bd36035b6bba28ff50a2692060b8567949fd3

OR to move the field below alias (and some changes to the texts)

https://github.com/bertoost/revolution/commit/07cd3a4b8045ba6868d455c6fa7965a1f5690576

[eladnova]

LOL Are we working on the same website(s) ?? Thats a great idea and a problem I've had in the past.

[bertoost]

I think everyone building websites will have this annoying issue with containers that just function for selection (like with getResources)... Now you also can create containers like "Top navigation" or "Left navigation" and just "exclude" that alias from it's childs, whithout having to set freeze uri for every child. You can even still use that for a single child that needs a specific URL

[eladnova]

Makes perfect sense. I wonder how many others have this problem too.

[eladnova]

Would this be a checkbox under a Resources Settings tab?

[exside]

Here, here, and acually I made a ticket or comment some time ago in the old tracker about exactly this problem and I guess there was some kind of solution, after a quick check I couldn't find this ticket...maybe someone else is more lucky...I found these two though:

http://bugs.modx.com/issues/9857 http://bugs.modx.com/issues/3942

[exside]

yeah, would say so @eladnova, somewhere near "Fix URI" or so?

[bertoost]

I have putted that below "Freeze URI" setting indeed; http://i.oostdesign.com/s/modx-exclude-alias-below-freeze.png (fixed the typo already hehe)

[exside]

Exactly @bertoost, that's it =)...does it work already for you or just a mockup? Aaah, where is that ticket, I know somebody posted code to make this work!

Update Got IT!: http://bugs.modx.com/issues/4065

I actually thought I could solve it this way (by not publishing the parent container > the organizational one), but didn't work...doesn't actually seem to matter for accessing the (published) child resources if the parent is not published...but also doesn't hide the parent from the path...

[bertoost]

I have it working in a project.. So it's from a working example :-)

[zaigham]

:+1:

[eladnova]

Why does the label mention 'child paths' ? I thoughtt the checkbox is only relevant if a Resource is set to a Container and only applies to the Container. Maybe I'm misunderstaning?

I also wonder could it have a shorter label such as 'Mask alias' instead of 'Exclude resource alias in child paths'

[bertoost]

It says what it is.. "Mask alias" makes no sense to me. It's mostly indeed applied to a container, but it affects the child resources, not the containers alias itself.. It saves the state of the setting in the database, for when you create new child resources or update existing one.

MODX builts every resource alias path when you change a parent alias or when you modify a child alias. It generates a new whole alias path for that resource on save. So saving this setting needs to change all childs (same as when you change the alias of a parent) and childs are looping up parents to get all alias elements, that's why I have to check for every parent resource (on save) if that setting is made or not, whether or not to include that resource alias

Please look at the file changes ;-)

[bertoost]

Btw.. there is also a little help description on the checkbox ;-) http://i.oostdesign.com/s/modx-exclude-alias-desc.png

[bertoost]

Of course we can move the field too.. like below the alias field; http://i.oostdesign.com/s/modx-exclude-alias-below-alias.png

[update] Field label sould be more like "Exclude alias in child URIs"

https://github.com/bertoost/revolution/commit/07cd3a4b8045ba6868d455c6fa7965a1f5690576

[rthrash]

This is very cool! Your last, more concise label is better as well. I do wonder though if this belongs on the settings tab as it will be infrequently used outside of initial setup by a site builder. I suppose Form Customization could take care of that. Speaking of, does Form Customization need an update to know about this?

[bertoost]

Thanks Ryan! My initial thoughts where settings tab too.. I just show to other that it could be everywhere And I guess that FC should be modified too indeed, not looked at that either. Also; with FC you're not able to move default core fields, only TVs can be moved.

[rthrash]

Not being able to move core fields has been a frustrating issue for a long time. That's why it would be important to get this right. Think you could look into FC for this one, as it should be able to be hidden?

[bertoost]

I am diving in to that.. should be possible of course!

[update] You should just create new records in "modx_actions_fields" for that and be aware of the ranking. This will enable the field to be visible in FC sets and you can then turn the visibility off to hide the field. NO file changes needed for this

[exside]

I actually like the placement near the alias better and @rthrash: The inability to move core fields is indeed frustrating. Would make things a lot more flexible, but probably this is another feature with lot more work involved =)!

[Qwarble]

I have had this problem too, but I solved it by excluding unpublished resources from path. It is quite easy and may be you dont have to add some additional fields in UI, but edit function modResource::aliasPath.

[bertoost]

Yes. But unpublished pages cannot be accessed on the website. So if you want the page to be accessed too, you're solution is not going to work. Also when having the container inside a listing like Wayfinder or getResources, it will not show (even childs will not be shown) if you have your page set unpublished.

[Qwarble]

You are right. But I think, for common tasks like 'top menu', 'left menu', 'service blocks' it's enough. But checkbox probably more suitable.

[bertoost]

Yeah! If we need to change the core, then do it right, so it suits a lot of situations ;-)

[rthrash]

@Qwarble I think your suggestion makes the most sense, and I would personally use it. Bonus: now new fields to deal with! I do think for backwards compatibility it should be a system setting that has to be enabled to take affect. Any chance you could do a pull request?

[bertoost]

@rthrash it's not a solution for all situations ;-) read my arguments hehe.. And what's the difference (when we talk about workload) for adding a new field (which I already have done for you) or adding a new system setting (which should be in de docs too hehe)

[Qwarble]

@rthrash Pulled my version of modResource::getAliasPath for excluding unpublished resources from url.

[adamwintle]

An option to remove/hide the parent URLs for all the children resources would be super useful for some scenarios. I'm +1 for this too.

[digitalbricks]

I am using modx only since a few weeks but i can't reproduce this issue. In my test project i arranged pages in containers too but the container alias is NOT present in the URL. So a resource placed under "footermenu" with the alias "contact" generates example.com/contact.html. The alias of the container "footermenu" isn't visible. Even better: I freely can define all url segments – so if i set the alias of the page "contact" (placed unter "footermenu") to "foo/bar/contact" i get example.com/foo/bar/contact.html. I love this freedom and so i wonder that you have this issue. I started with Revo 2.2.13 and there this issue wasn't present, no i am on 2.2.14 an still everthing is fine. Maybe it's a system setting?

[digitalbricks]

I checked my settings: I have "Use Friendly Alias Path" set to "No". If i change this to "Yes" i can reproduce this issue – so please check your settings and make sure "Use Friendly Alias Path" is set to "No". I am new to ModX so i hope i understood your issue correctly.

[exside]

@digitalbricks: yes, this issue is arising in the scenario where you have alias_paths enabled and you don't want to show certain parent (containers) in the resulting URL.

[exside]

@bertoost

Also when having the container inside a listing like Wayfinder or getResources, it will not show (even childs will not be shown) if you have your page set unpublished.

I just tested this with both, Wayfinder and getResources and it works...I have setup the following test case:

- Published Resource (ID 6)
- *Unpublished Container* (ID 7)
    - Published Child Resource (ID 8)

with wayfinder and &parentId=7, I get a single menu item of "Published Child Resource" with &parentId=0 I get two menu items "Published Resource, Published Child Resource, but no Unpublished Container menu item, as expected.

With getResources it's the same, no matter if the parent is published or unpublished, the childs get returned...

maybe I didn't understand correctly what you mean?

[Mark-H]

@bertoost could you try shooting over a new PR for this one? Would be great to get this into 2.3, but I am a bit at a loss what the latest is here..

Feel free to poke me on skype if you need help with the git-fu.

[osabate]

When is this feature gonna see the light of the day? Thanks!

[vierkantemeter]

Should Bert Oost's solution work for MODX 2.2.15? I've updated the code with his, but after this I get a "error while saving document"

[degoya]

is this features still not implemented in 2.3.3?

[vierkantemeter]

The following hack will work in 2.2, 2.3 and 2.4 to hide a resource in a URL: https://github.com/Qwarble/revolution/commit/df1902d5b68e02d760842c19f3a6e647f38ff6ab

[osabate]

That's great. Are you gonna make a PR for it?

[vierkantemeter]

That's up to @Qwarble

[Qwarble]

I did PR, and it was closed. https://github.com/modxcms/revolution/pull/11167

[dssaf]

2.3.3 An error occurred while trying to save the resource.

[gadgetto]

2.4.2 an still not available :-(

[sbrin]

When this feature will be in released?

[Jako]

This should be added to the Important Feature requests.

[SnowCreative]

I just converted a client from Evolution, which has this feature, to Revolution, which doesn't. Why was this left out of Revolution?? The site needs to keep the same URLs for tracking purposes, and now I have no way of making that happen, short of hand-entering Freeze-uri for every single page that needs this.

[mrhaw]

One option if to turn off use_alias_path but that affects all folders then.

[OptimusCrime]

I agree that this issue is something we should look into. It would be nice to have in certain situations.

[muzzwood]

+1 for this. I could have used it many times.

[OptimusCrime]

Just wondering about what people want.

If we have the following relationship from first parent to parent to child like so A -> B -> C, where C is the child of B and B is the child of A. Now, if A was to ignore parent alias, would it ignore just B or B and A together? Unless it was to ignore both B and A, it would be no way to specify that C should have just its own alias.

[SnowCreative]

Same was as it works in Evolution: a checkbox "Use current alias in alias path" to apply to any container, so this would never get applied to "C" in your example, only to B or A, to control which containers get included or excluded in the URL for C (and all other children of A -> B).

[OptimusCrime]

I have the following resource Foo -> Bar.

Foo enabled, Bar enabled

• Foo uri = foo/
• Bar uri = foo/bar

Foo disabled, Bar enabled

• Foo uri = foo
• Bar uri = bar

Foo enabled, Bar disabled

• Foo uri = foo
• Bar uri = foo/bar

Foo disabled, Bar disabled

• Foo uri = foo
• Bar uri = bar

I just tested this in Evo with all the combination mentioned above. So, as far as I can tell, with the setting disabled (Do not include alias in path) all child resources will not have that alias in their uri, but the resources themselves will still have it in their alias.