Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$template->childTemplates not updated when template is deleted #802

Open
adrianbj opened this issue Jan 29, 2019 · 10 comments

Comments

Projects
None yet
4 participants
@adrianbj
Copy link

commented Jan 29, 2019

Short description of the issue

If you delete a template that has been added to another template's childTemplates array, it is not removed from this array

Expected behavior

It should be automatically removed.

Actual behavior

It isn't removed.

Optional: Screenshots/Links that demonstrate the issue

Your screenshots/links go here.
image

Steps to reproduce the issue

  1. Add template to childTemplates array for another template
  2. Delete the added template from the system
@ryancramerdesign

This comment has been minimized.

Copy link
Contributor

commented Feb 4, 2019

Unless it's resulting in a visible error somewhere (?), this one is expected, and not a problem. When references are encoded (rather than existing in their own DB column), it's not necessary (and sometimes not practical) that they be removed until the next time the value holding them is modified and/or saved.

@adrianbj

This comment has been minimized.

Copy link
Author

commented Feb 5, 2019

I don't remember if I came across an error, but I probably did or I wouldn't have noticed this discrepancy. In a couple of my modules I do checks on whether there a template has childTemplates and I believe these would be incorrect with the current behavior. I use modules from other devs that also do this check.

I noticed in ProcessPageListerPro.module there is:

if(empty($template->childTemplates)) continue;

Maybe I am misunderstanding something, but won't this return false rather than true in the situation I have described. It seems to on my isolated tests. Maybe there are some other checks in there that I haven't noticed that are taking care of updating the childTemplates property?

@ryancramerdesign

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

The line(s) you mentioned in Lister/ListerPro are just optimizations to skip over an additional check if the value happens to be empty. There are many instances where ProcessWire core as well as both core and 3rd party modules keep track of these kinds of settings in encoded values. All configurable modules and fields work in this way as well. The childTemplates setting on templates is just one of potentially hundreds. Settings like this are adjusted at the time the object that encodes the setting is saved. It wouldn't be practical or efficient otherwise. When we need a setting that is automatically adjusted in the manner you described, we reserve a dedicated DB column or table for it, which is what enables it to be efficiently managed in that way.

@adrianbj

This comment has been minimized.

Copy link
Author

commented Feb 14, 2019

So if a module author want to get an accurate result for whether a template has a particular template in its childTemplates, what is the recommended way to check this? Do we need to check the childTemplates property and then do an additional check to see if each of the returned IDs are actually valid templates?

@ryancramerdesign

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2019

So if a module author want to get an accurate result for whether a template has a particular template in its childTemplates, what is the recommended way to check this?

Maybe something like this below (?)

function templateHasChildTemplate(Template $template, Template $childTemplate) {
  return in_array($childTemplate->id, $template->childTemplates); 
}
@adrianbj

This comment has been minimized.

Copy link
Author

commented Feb 14, 2019

Ok, sorry, I guess that was the wrong question because in your example the template has to exist or the function will throw an error.

I am talking about a situation where you want to know if a template has any childTemplate restrictions and currently it will return the IDs of templates which may no longer exist and the count will be wrong.

I guess I am talking a relatively uncommon need. I just don't like that there is incorrect data stored.

@adrianbj

This comment has been minimized.

Copy link
Author

commented Feb 20, 2019

@ryancramerdesign - I have actually come across an error with this. This line: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/PagePermissions.module#L849 causes a:

PHP Notice: Trying to get property 'useRoles' of non-object

Note that the notice doesn't show for superusers so that might confuse you at first.

@adrianbj adrianbj reopened this Feb 20, 2019

@adrianbj

This comment has been minimized.

Copy link
Author

commented Mar 13, 2019

@ryancramerdesign - actually, it's possible for the error to show for superusers. I am seeing this with Tracy's RequestInfo panel - it makes a call to see if the page has addable() permission and if you have one of these deleted childTemplates, it gives you that "Trying to get property 'useRoles' of non-object" error.

@Toutouwai

This comment has been minimized.

Copy link

commented Mar 13, 2019

I believe my suggested fix in #543 would resolve this issue too. Specifically this addition:

if(!$template) continue; // childTemplates may contain IDs for templates since deleted
@netcarver

This comment has been minimized.

Copy link
Collaborator

commented Mar 14, 2019

@ryancramerdesign Bumping this for your consideration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.