If you make a View that contains Field.module fields (for display, not for Sort or Filter criteria), the views_handler_field_field
class loads every entity within the view and then just pulls out the needed values for display.
As far as I know, this architectural decision was made to avoid the MySQL JOIN limit on tables (61). However, most views won't get near to that many JOINs. We may be able to get a major efficiency improvement on field listings if we intelligently determined how many JOINs were going to be used, and only resort to loading all entities if nearing the limit.
There may be other problems with some fields that assume that they get the entire node, which may need to be adjusted. Let's do some research on if this is possible and/or worth it from a performance perspective.
Recent comments
Thanks. I've now tested this on a localhost and what you say holds true: the user whose permission has been removed for the given content type no longer has creation and editing rights for that...
Status of existing content after role permission removal
I finally found the PHP controle in my CPANEL and Reset the PHP to vwersion 7.3. Using this version I was able to clear the update caches but I am still unable to run update instite of the...
Update Problems
OK so looking a the results of running update.ph[ it calls for a specific version of PHP. My host company is providing a 8+ version of PHP. One now wonders if therre is a general limit on PHP...
Update Problems