You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Plone 4 when I uninstall pas.plugins.ldap from the control and reinstall the add'on, I can no longer set the memcached server url. I always see a notification "Feature not available" in the field.
What (probably) happens (with some debugging assistance from @mauritsvanrees):
The memcached server settings are made available through component in the Plone component registry. Installation of the component is done in the install-base profile, which is installed through a metadata.xml profile dependency in the default profile (one for Plone 5, one for Plone 4)
However, upon installation the quickinstaller monitors changes to the componentregistry and registers the component to the default profile (it doesn't see which profiles do what). So when you uninstall pas.plugins.ldap default, the default profile is uninstalled, the component is removed, but install-base profile is still installed. When you Install pas.plugins.ldap again, install-base is still 'installed', so the componentregistry.xml from that profile is not processed again.
Workaround:
in the ZMI in portal_setup import the install-base profile from pas.plugins.ldap, which will add the component.
The memcached property is already stored in the plone registry. Why is access to the memcached setting done through a persistent component when the only place the value is queried is in cache.py cacheProviderFactory function, where you could also query the registry directly instead of going through the component (which then queries the registry). Then we could remove the component alltogether.
The text was updated successfully, but these errors were encountered:
fredvd
changed the title
Uninstalling/reinstalling pas.plugins.ldap removes CacheSettingsRecordProvider (and disables Memcached)
Uninstalling/reinstalling pas.plugins.ldap removes CacheSettingsRecordProvider (and disables Memcached in the control panel)
Dec 14, 2016
The memcached property is already stored in the plone registry. Why is access to the memcached setting done through a persistent component when the only place the value is queried is in cache.py cacheProviderFactory function, where you could also query the registry directly instead of going through the component (which then queries the registry). Then we could remove the component alltogether.
Perhaps historical reasons - this should be refactored. In past persistent components were considered as a good idea and today this idea changed into more or less a bad idea.
Symptom:
In Plone 4 when I uninstall pas.plugins.ldap from the control and reinstall the add'on, I can no longer set the memcached server url. I always see a notification "Feature not available" in the field.
What (probably) happens (with some debugging assistance from @mauritsvanrees):
The memcached server settings are made available through component in the Plone component registry. Installation of the component is done in the install-base profile, which is installed through a metadata.xml profile dependency in the default profile (one for Plone 5, one for Plone 4)
However, upon installation the quickinstaller monitors changes to the componentregistry and registers the component to the default profile (it doesn't see which profiles do what). So when you uninstall pas.plugins.ldap default, the default profile is uninstalled, the component is removed, but install-base profile is still installed. When you Install pas.plugins.ldap again, install-base is still 'installed', so the componentregistry.xml from that profile is not processed again.
Workaround:
in the ZMI in portal_setup import the install-base profile from pas.plugins.ldap, which will add the component.
The memcached property is already stored in the plone registry. Why is access to the memcached setting done through a persistent component when the only place the value is queried is in cache.py cacheProviderFactory function, where you could also query the registry directly instead of going through the component (which then queries the registry). Then we could remove the component alltogether.
The text was updated successfully, but these errors were encountered: