Answered Set default template if parent of parent of parent == 123

I see, it's possible to solve task 'set default template if parent == 123' via http://rtfm.modx.com/revolution/2.x/administering-your-site/customizing-the-manager . (just limit resource/create as modResource.parent == 123 in http://mydomain.com/manager/?a=security/forms/profile/update&id=1 ).

Is it possible to solve similar task of setting default template if parent of parent of parent == 123 without any plugins?.. How?

If not, what is the recommended way to do that?..

I can create custom plugin based on this code
https://gist.github.com/fomigo/2344301

Is it good idea or there are better ways?..

Thank you.

Don't thank me until it works.

I say thanks because of you spend your time and try to help me, I appreciate it.

About my solution (I think, it's nice):

I combined https://gist.github.com/fomigo/2344301 with http://rtfm.modx.com/revolution/2.x/administering-your-site/customizing-the-manager (I created some resource/create sets for some templates and set default childDefaultTemplate for them).

In my documents structure in Modx:

(Hotels Page, id 123, for example, as root of data tree) -> ExampleCity -> ExampleHotel -> ExampleVideo

First I set childDefaultTemplate of 123 page to City template.
Next I created ModX resource/create set for City template where set childDefaultTemplate to Hotel template.
And next I created ModX resource/create set for Hotel template where set childDefaultTemplate to Video template.

So it works, I think, it's most universal way to do that...

I thought, may be exists way to set condition just in modx without plugin in form here: https://www.youtube.com/watch?v=iJB_IXg7NNc#t=217

for example, for resource/create video:
constraint: parent of parent of parent
constraint value: 123

but now I think, my way will work faster and more universal, than I suggested before...

Also I suggest to include https://gist.github.com/fomigo/2344301 in modx by default, it's very useful... And may be create childDefaultTemplate as system field for every document... (not as TV)

Here is something else to look at: https://forums.modx.com/index.php?topic=27158.0.

It could be modified to create an InheritGrandparentTemplate plugin.

Adding any of this to MODX is not likely to happen, imo. The key philosophy of MODX (especially Revolution) is to avoid loading down the MODX core with stuff that many people will not use. That's why not even Wayfinder or getResources are part of the core.

BTW, if there is a resource field you're not using for anything (e.g., introtext or description), it could be used to hold a child or grandchild Template ID -- that would be very fast and easy.

You can also create extra Resource fields by extending the modResource object with ClassExtender or by creating your own custom resource class.

I suspect that what you're suggesting will be easier in MODX 3.0.

>

Adding any of this to MODX is not likely to happen, imo.

Revo is much better than Evo (ability to store many objects in tree, ExtJS for admin etc.) but it has (as Evo) bad design. Really, I'm sure, such functionality as give us Wayfinder or getResources should be included in ModX, not as Wayfinder or getResources but as a part of ORM. I need normal ORM like Doctrine (afaik it's the best in PHP world) http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-objects.html#by-simple-conditions and normal template system (like Twig with ability to extends another templates) http://twig.sensiolabs.org/doc/tags/extends.html ... .

May be it's very hard to add such features... But really I do not understand reasons why ModX3 can't use Symfony as core?.. A Drupal 8 and new phpBB (not sure about phpBB) did .

Symfony looks much better (use namespaces ), recommended way is use composer to install packages...

So I will be happy if ModX3 will use Symfony + ExtJS (it's really powerful system, but may be if Modx update it (extJS3 -> ExtJs5), it will work faster) with same features as now + normal ORM + normal template system...

I used ModX Evo in 2007-2008, it was good CMF for 2007, next used Django (Python) but I'm still loyal to ModX for small sites... But today after Drupal 8 I'm going to say goodbye to ModX... I like old toys, may be sometimes I will use it (until Drupal 8 creates good Ajax-based admin).

Me a little sad that my favorite cms lags behind in development but I do not see ability to change situation here (afaik modx 3 will not use Symfony)...

P.S.
Also using Doctrine give ability to use PostgreSQL, which is better than MySQL. At least, I like it some more (ability to use full joins wihout such things as described in https://stackoverflow.com/questions/4796872/full-outer-join-in-mysql ). And it's for free, no need any time to implement it from ModX side...

P.P.S. Hope, I do not started new holy war...

Not with me.

Nope, no wars here. Occasional differences of opinion, but I have no fear of saying that when editing in the command line I use vi (or vim), and that I despise ExtJS and Smarty, and that I am not overly fond of the scss/compass/grunt/bourbon/whatever pile of ... stuff ... along with all of their dependencies one is supposed to install on one's working machine just to do CSS.

You will find nothing but agreement, even from the core developers, that MODX needs more databases, and needs a new framework. However, as far as the philosophy behind MODX itself, aside from the decisions on its inner parts, adding more and more features built-in probably won't get a lot of traction. See, MODX means "MODular, eXtensible", so the concept of having a core product, with lots of APIs and events to allow insertion of custom code easily installed as modules, won't change much.

My personal take on the core and installable modules is that there needs to be more uncoupling of some of the features that are now part of the core, not more hard-coded implementations of currently separate modules. For example, you spoke of Wayfinder, but pdoMenu, part of the pdoTools package, is much better - faster and more flexible. Likewise pdoResources is better than getResources.