Closed frogabog closed 6 years ago
I think an extra should do this, not core. Uberbar solves the needing to look through trees at all. I believe moving away from resource ids is on the roadmap. — Sent from Mailbox for iPhone
On Fri, Jan 31, 2014 at 2:56 PM, Frogabog notifications@github.com wrote:
Could we view the ID of whatever we're viewing as a page in the manager, somewhere on the page itself? Perhaps in the title area in parentheses? Example: If you've navigated elsewhere through the resource tree for any purpose, fetching an ID can prove to be a little awkward having to go back and re-open the tree to see them.
Working reasons aside, it'd just be nice to immediately know what the ID is every time the resource is opened. It would do wonders for ID association for developers, because after a while you'd remember the ID as well as the title/name just because you see it every time you open it.Elements need this less, but they too may as well show the IDs. Why not?
Reply to this email directly or view it on GitHub: https://github.com/modxcms/revolution/issues/11096
I agree with JP.
I dont agree. Ids are an important way to communicate the exact resource used in snippets. If you have lots of resources with similar or even identical names, a unique identfier is extremly important.
While answering a support call, knowing the id makes it easier for both sides to be sure they are talking about the same thing.
Form customization still has the option to display the id or not. Unfortunatly this setting is no longer having any effect.
+1 for bringing this feature back and setting the default to 0.
Creative freedom!
Cheers pepebe
Glad for the company Pepebe! While I can get the ID from the url, and I can get it in the tree, I still find myself wishing for a nice big ID in the resource every time I need to fetch it. Also agreed, when it comes down to locating a resource, it's easy to change the id in the url and load the page in question right up. I like IDs!!! It's seriously one of the best features in MODX, I think.
I've also been wondering what this meant for a long while, cuz I'm scared of the idea of moving away from IDs. How will we make links? How would all our old sites with [[~id]] work at all? What's up with that JP?
"I believe moving away from resource ids is on the roadmap. —"
Sometimes when on a chat or a phone call with a client I'll need to ask them for the Resource ID, they can never quickly relocate the ID in the left-hand file tree and for some reason clients avoid the URL bar.
I think for these types of non-technical clients having the ID displayed at the top of the Resource editor would be useful. Maybe this could also be switched off as a system setting?
I still want to know what this is meant to mean...
"I believe moving away from resource ids is on the roadmap. —"
JP?
+1 for not removing the ID. it's a real handy way to ID which page a client is referring to when they're logged into the Manager or doing some training.
Sometimes I fall back on figuring out the Resource ID from the address bar.
Forgabog - are you proposing that the ID gets added to the title above the TV tabs as per mockup?
What @eladnova suggested is exactly what I had in mind. A clear and useful way clients can spot the Resource ID.
I'd also say this can be optionally switched off, similar to how the "tree_show_resource_ids" works in the Access Policies.
@adamwintle Every Resource in MODX has to have a page title, right? I was just wondering if the ID number in the screenshot was affected when/if someone hides the field with Form Customization.
Yes, eldanova, that is pretty much what I have been yearning for. Although some clients can get wordy with page titles, even fetching it from the tree can be difficult at times. It would have to show up there, regardless of title length, rather than get pushed off and out of the view if the title is very long.
I think doing something like this would go a long way towards helping the clients understand MODX linking actually. Doing something slick like making a link tag when clicked would also be nice. WordPress users are used to grabbing a "shortcode" from a page while editing. Why can't we provide similar linking assistance for MODX users?
I have zero hesitation to lobby for adding the Element/Resource IDs in the titles. Where it is above the tabs should further not be affected by any Form Customization, at least not that that I'm aware, as I don't think the displayed value above the tabs is subject to FC rules. Anyone fancy putting together a PR?
Should this be done with or without a system setting for toggling the behavior?
Please do it with a system setting, because we personally don't want to show it to our clients.
System setting would be fine with me.
Note: there are already permissions "tree_show_element_ids" and "tree_show_resource_ids". It makes sense to use permissions for that instead of a setting and would be wise then to add a permission "form_show_resource_ids" or something like that.
Good catch. I think that makes sense as well.
This would be a nice addition. Maybe it could be added to MODX 3? If needed I would like to help getting this feature in MODX 3.
Isnt there an id there today? Seem like noone has complained since we rolled out the new design (version 2.3?). In favor of closing this.
There isn't. See the screenshot posted earlier in this issue.
You are right, my bad. I thought perhaps the ID was added after the 2.3 redesign.
Could we view the ID of whatever we're viewing as a page in the manager, somewhere on the page itself? Perhaps in the title area in parentheses?
Example: If you've navigated elsewhere through the resource tree for any purpose, fetching an ID can prove to be a little awkward having to go back and re-open the tree to see them.
Working reasons aside, it'd just be nice to immediately know what the ID is every time the resource is opened. It would do wonders for ID association for developers, because after a while you'd remember the ID as well as the title/name just because you see it every time you open it.
Elements need this less, but they too may as well show the IDs. Why not?