Page view permissions

[Gregory Smirnov]

Hello guys,

 

I was not aware of the speed problem in Hierarchy::Children() that Gordon mentioned in his notes about speed:

 

3) Traversing the SiteTree is expensive when rendering menus, with multiple repeated queries, for the gory details see https://github.com/silverstripe/silverstripe-framework/issues/2979 - note a technique to identify repeated SQL queries is included here.

 

Could you kindly elaborate on SiteTree permissions CanViewType and CanEditType. When do you use them?

 

We produce content for the public and it does not make sense to make it NOT visible to anyone. Probably this functionality may be moved into extension and disabled in yaml config by end users?

This way many sites will get performance boost out of the box.

 

Gregory

 

[Nicolaas Thiemen Francken - Sunny Side Up]

after a quick read through issue 2979 it seems to me that this would be super worthwhile fixing.  I am not sure if this has been done yet.

it would involve two pull requests:

• https://github.com/silverstripe/silverstripe-framework/issues/2979
  
• https://github.com/gordonbanderson/silverstripe-cms/tree/ISSUE2979
  

This would significantly reduce the number of queries for any menu with hierarchy. Is there any way this can be included in 3.2?

Nicolaas

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Nicolaas Thiemen Francken
  www.sunnysideup.co.nz

  phone: +64221697577

[Gordon Anderson]

hi

Late at night my time (Thailand) so not about to do any (re)analysis but from memory the field CanViewType, if set to 'Anyone' mitigates the above scenario to a certain extent.  However this needs to be set manually per page by the content administrator which is far from ideal.  For a brochure-ware website where all content is visible, this seems like the right setting.  Perhaps a module or pull request (if former not possible) to allow the default to be configurable would be good, leaving the existing behavior as the default.  In the current scenario an SQL statement could be used to update the field 'CanViewType'.

I guess the other option here for now is to use static publishing.

Regards

Gordon

[Gordon Anderson]

hi

Just re-reading your email Gregory I had not considering the editing site, but I would probably leave that for now if only a small number of editors, the public side of the site is more important.

Nicolaas, the pull requests for that bug are against 3.1.3 so would need rebased/retrofitted against 3.2 and also tested more thoroughly.  I managed to get the tests to run locally for me against MySQL and pass, but it took a couple of hours on my laptop, and I guess other scenarios such as Postgres, Windows etc need checked.  I am not familiar with the Travis setup unfortunately.  My programming time is somewhat fractured at the moment, though I am working towards fixing that, having just found a legal option to freelance in Thailand which would allow me normal office hours blocks of time to code,

Regards

Gordon

[Nicolaas Thiemen Francken - Sunny Side Up]

I just had a look through the changes:

https://github.com/silverstripe/silverstripe-framework/commit/99ad4f8edc2e94fe96aff5a45bc408b941873416

adding a cache to Hierarchy::children()

https://github.com/silverstripe/silverstripe-framework/commit/bb0fb3d378d5fa8a2a152fa22e2f80c1458fab54

adding a new method in Hierarchy to support caching.

https://github.com/silverstripe/silverstripe-cms/commit/3fcfbdb187814a7a6cd0ad24683833932b1b0b29

adding a cache to SiteTree::canView

https://github.com/silverstripe/silverstripe-cms/commit/5fdc2f1210745a98ad02c023582885e74aaa5610

adding a cache to SiteTree::Link

https://github.com/silverstripe/silverstripe-cms/commit/410cfb06c05c698aabc20fe174cebc4620bc7ee9

adding a cache to SiteTree::canView

All in all, while being deeply rooted into the core functionality of Silverstripe, they are also fairly trivial.  The problem of course are situations where "caching" is not appropriate (e.g. when you are editing in the CMS). 

I am sure some will argue that this caching should take place on a "deeper" level (i.e. DataObject::get() caching stuff).

Does anyone else have any ideas on this?

Nicolaas