PHPBB3-13867 - Profile field types need an enable/disable mechanism

[javiexin]

Issue in the tracker: https://tracker.phpbb.com/browse/PHPBB3 ... lter=10292

If an extension defines a new Profile Field type, it needs some kind of mechanism to enable, disable and purge data of this particular Profile Field type, to avoid cases of left profile fields based on no-longer existing profile field types that break the forum completely.

A mechanism similar to the one of notifications, adding enable, disable and purge methods to the profile field type manager class, that would be called from the ext class of the extension, seem like the most appropriate way forward.

What do you think? Is this the right approach, or is there any other alternative?

For background, you may see https://www.phpbb.com/community/viewtop ... #p14087536
Thanks to VSE and david63 for their already provided help.

-javiexin

[MattF]

Well, you could also look at how captcha plugins do it too.

You can see how Derky Sortables Captcha does it in their ext.php file in its own self contained way:
https://github.com/Derky/Sortables-CAPT ... op/ext.php

[javiexin]

Thanks for the pointer to this new useful example VSE.

I have almost all the problem clear now. Most things can be handled from within the extension itself (inactivate fields on extension disable, delete field on extension removal, activate fields on extension enable), with one exception: in file includes/acp/acp_profile.php (line 688), all existing profile fields, active or inactive, are referenced. That creates the break of the forum when trying to access the type_collection with the disabled key, when the extension is in the disabled state, regardless of the status of the profile field itself.

As I see it, the problem is that there is no profile_field_type table (or equivalent) where you may indicate if a type is active or inactive.
I can probably figure out a way to "cheat" the core, but will be definitely something that could be broken in certain corner cases.

I'd rather discuss a more complete (and error free) option, even if the core needs some minor changes.
Thanks again,
-javiexin

[javiexin]

Finally, I have implemented a self-contained workaround, that you may see here:
https://github.com/javiexin/multiselpf/ ... er/ext.php

However, this is still not 100% error free, and there are traces of what is being done, and corner cases where the forum may be forced to break.

So, I would kindly ask for a definite fix. If you want, I can try to make a proposal for it (patch), although it would require DB changes (an additional column in the profile_fields table) and fixing in a couple of core files. I would need some guidance on the dependencies for such a migration file.

Best regards,
-javiexin

[javiexin]

Ok, I have submitted a pull request solving this issue: https://github.com/phpbb/phpbb/pull/3656

The mechanism used is similar to the one used for notifications. The profilefields/manager class adds methods to be called on extension disable, purge and enable steps. The use from extensions is extremely simple, almost identical to the one used for notifications.

To make it work, finally, it has NOT required any database (structure) change. It uses config_text entries to save information on the disable step, to be read on the enable step to revert those changes. In a disabled state, all profile fields of this type are set to "inactive". In the re-enable step, only those fields that were active on the disable state are re-activated. During the purge step, all fields of this type, regardless of the status (active/inactive) are removed. All of these activities are logged.

Besides this, there is a small change required in includes/acp/acp_profile.php to avoid listing the profile fields from disabled types (that actually make the forum break).

Hope this is ok and approved.
Regards,
-javiexin