SUGGESTION: See when portal preference overrides are stored in database

[Nick Straguzzi, modificado 12 Anos atrás.]

So there I was, having deployed my custom Control Panel theme plugin. Now all I needed to do was tell Liferay to use it. I set control.panel.layout.regular.theme.id in my portal-ext.properties file to the ID of the new theme and happily restarted the server.

Nothing happened.

I double checked the property key. I triple-checked the theme ID, ensuring it was in the proper themename_WAR_warname format. I quadruple-checked that portal-ext.properties was being loaded. I restarted the server a dozen times, looked in the Portal Admin->Properties portlet to be sure the correct value was being picked up, and even had a coworker come over to my desk and verify that I every last ASCII character had been typed correctly. I spent all day on Google and the forums, reading one thread after another. Nothing.

Perhaps 15 minutes before committing ritual harikari in frustration, I remembered several months ago that one of our team's leadership was looking at the Portal Settings page in Control Panel and exclaimed, "Wow, you can even change the admin console's theme!" She changed the value in the DDLB, watched as the CP changed to Classic, and then immediately switched it back to the default CP theme. To cut to the chase, that brief switchover had basically hard-coded the value of control.panel.layout.regular.theme.id in the database, and of course at that point nothing I did in portal-ext.properties could trump that. I erased the value in the portalpreferences table, and all was once again right with the world. Relieved, I put away my tanto for another day.

I started this thread for three reasons.

(1) To preserve the sanity and lifespan of Liferay developers -- if you are having a similar problem with any Liferay property setting, CHECK YOUR DATABASE.

(2) To propose that control.panel.layout.regular.theme.id be added to the list of properties that can be overridden via a hook. That wouldn't have solved my particular problem, but it's still good practice.

(3) To propose, beg, beseech the Keepers of Liferay to PLEASE, for the love of all that is good and holy, add an option called "(use portal default)" to every DDLB that can trigger this behavior. This way, we can tell at a glance what Control Panel fields have the potential for causing this maddening level of confusion. In fact, I would recommend that the field also specify what that default is. Thus, in the Default Control Panel Theme DDLB on the Portal Settings->Display Settings pane, the values one would see are:

Use portal default (Control Panel)
Override to: Control Panel
Override to: My Custom Theme

One would choose the first if you want the portal to decide, the second if you always want to use the CP theme no matter what, and the third if you want to use your custom theme no matter what. Thoughts?

Exasperatedly (but happy that this problem is finally resolved),
Nick

[Milen Dyankov, modificado 12 Anos atrás.]

I had a similar issue with another property (don't remember which one) some time ago and also spent quite some time figuring out what's going on.
As for your propositions, I suggest to

• post them in Suggestions and Feature Requests category. My experience shows there is better chance to discuss on the subject with a Liferay employee.
• create "Improvement" issue(s) in http://issues.liferay.com. Put a link here and I'll be one of the first to vote for it.

[Nick Straguzzi, modificado 12 Anos atrás.]

Thank you Milen. I've opened a JIRA issue here: [http://issues.liferay.com/browse/LPS-24962]

[David H Nebinger, modificado 12 Anos atrás.]

There are actually many properties that, once Liferay is started, are pushed into the database and come from there forever.

Granted you had a difficult time tracking down your problem, but likewise I do all of my reconfig in the control panel itself. If my site changed how it looked because one of the ops guys mistakenly changed my properties file, I'd be quite upset...

I think the best suggestion would be that Liferay add comments to the properties file indicating that the property is read from the database after first Liferay launch; that might have been the best indicator for you to figure out that the property was now set in the database rather than in the properties file.

[Nick Straguzzi, modificado 12 Anos atrás.]

David, I appreciate the suggestion but I have to disagree that that would be sufficient. In most real-world scenarios, including mine, Liferay is meant to be used and administered by numerous people. Even with the reminder that some configuration settings may get "locked" in the database, it's just way too cumbersome to have to check the DB every time to see if someone, somewhere, sometime might have once changed (and restored) any particular setting. Worse, even though I might be quicker to check the DB after this ordeal, what happens if I get hit by a bus and someone else, less familiar with the vagaries of Liferay, has to take over?

I really think the only way to handle this properly is to have some sort of visual indicator in the Control Panel. Exactly what that indicator should be is certainly open to discussion -- maybe just a simple icon by the label that tells the user that the setting is coming from the DB (with an HTML "title" tooltip explaining the icon)? Even if the admin has to go into the DB manually and remove the field (rather than be able to do interactively so from the CP), that's still a big step forward to making Liferay more usable in the real world.

Cheers,
Nick