• Debian 11 is approaching its end-of-life (vendor EOL date - August 31, 2026). Plesk Obsidian 18.0.80 will be the last release to support it.
    If you are running Plesk Obsidian on Debian 11, we recommend you upgrade those servers to Debian 12 using our dist-upgrade tool.
  • We plan to deprecate and remove the support for XML RPC protocol versions earlier than 1.6.9.1 in Plesk Obsidian 18.0.82. We strongly recommend that you update all existing integrations using earlier versions of the XML RPC protocol to comply with the version 1.6.9.1 specification.

Input Plesk 18.0.80 panel.ini nofun=true

nmdpa3

Regular Pleskian
Server operating system version
Ubuntu 26.04
Plesk version and microupdate number
18.0.80
Plesk’s decision to enable collectible pixel-art stickers by default as part of its anniversary 18.0.80 release was poorly conceived and completely unnecessary.

As a Plesk Partner, we provide Plesk to business customers who expect a professional control panel. We do not want promotional stickers or novelty graphics appearing in their interface, and we should not be required to manually edit panel.ini across every automatically updated Plesk server simply to remove them.

This should have been an optional feature that administrators could choose to enable—not something imposed by default and left to partners to disable after the fact. Rolling out a cosmetic gimmick across business systems without administrator consent shows remarkably poor judgment.

Please remove the stickers from the default configuration and disable them by default going forward. Administrators who actually want them can opt in.

Frankly, what were you thinking?
 
Thank you for taking the time to share your feedback. The anniversary stickers were intended as a light-hearted celebration of the 18.0.80 release. Nevertheless, your concern about keeping the Plesk interface plain is understandable. I will make sure your feedback is shared with the Product team for consideration in future releases.

Just for everyone else's reference, the stickers can be disabled by adding the following lines to the panel.ini file:

Code:
[product]
noFun = true
 
Last edited:
Thank you. Having now seen the stickers, I can say with 100% certainty that customers will “freak out” when they see them. We will receive calls from customers believing that Plesk has been compromised, and our support team will have to spend hour after hour providing unbillable technical support to explain and correct the situation.

This should be fixed immediately rather than deferred to the next release. I understand the novelty of the stickers for Plesk and its team; however, business customers will not share in that lighthearted celebration. To them, the stickers will look like an unauthorized modification or a possible security compromise.
 
Hi @nmdpa3

Thanks for the direct feedback, it has reached the product team.

To answer "what were you thinking": the intent was a small, time-limited celebratory touch for the anniversary. The miss on our side was shipping it enabled by default in partner-managed environments, and that point is taken - we are discussing it internally.

To be clear about the scope: the stickers are purely cosmetic. Nothing changes in functionality, security, or the server itself - it is UI only, and it will go away after the anniversary period.

You can already disable it today on any server by adding this to panel.ini:
[product]
noFun = true

For a fleet, this rolls out the same way as any other panel.ini setting - via your usual config automation, so there is no need to edit servers one by one manually.

One question to help me gauge the actual impact: how many of your customers have contacted you about the stickers so far - confused, worried about a compromise, or opening tickets? That number directly affects how we prioritize the follow-up on the default behavior.

Thanks again for flagging it.
 
Thank you for the clarification and for confirming that the product team is reviewing the issue.

The concern is not whether the stickers alter functionality or security; it is that they create the appearance of an unauthorized modification in a business-critical administrative interface. Customers are not expected to know that the change is cosmetic, and many will reasonably interpret an unfamiliar graphic in their server control panel as evidence that the system may have been compromised.

I also do not believe the number of support calls received to date is the correct measure of impact. Many customers may not yet have logged in or encountered the change. The problem is the unnecessary risk and support burden created by enabling it by default across partner-managed environments. Partners should not be required to deploy a configuration change across their fleets to undo an unrequested cosmetic feature.

While noFun = true provides a workaround, applying, validating, and later maintaining that setting still consumes partner time and resources. The appropriate resolution is to disable the feature by default in partner-managed and business environments, with an opt-in available for those who want it.

I appreciate that the intent was celebratory, but administrative control panels are not an appropriate place for surprise visual changes. Please prioritize correcting the default behavior now rather than waiting for the anniversary period to expire.
 
Please prioritize correcting the default behavior now rather than waiting for the anniversary period to expire.
Understood - and your point about perception in a business-critical admin interface is a fair one. Whether the change is cosmetic or not matters less than how it looks to an end customer who did not expect it. That framing is exactly what we are taking into the internal discussion.

I will not overpromise a specific change or timeline here, but we are actively collecting partner feedback on this functionality, and this thread is part of that input.

In the meantime, I can help you directly: send me a private message here on the forum with your partner account name or the specific license/server identifiers, and I will get this functionality disabled for your environments from our side right away - so you do not have to touch panel.ini across your fleet at all.

Thanks for taking the time to lay out the argument properly.
 
Thank you—I appreciate your understanding and your willingness to address this directly.

I will send you a private message with our partner account information and the relevant license/server identifiers so the functionality can be disabled across our environments from your side.

Thank you again for taking the concern seriously and helping us avoid having to deploy the panel.ini change across the fleet.
 
Thankfully we manage the panel.ini centrally for all our Plesk servers, but it's yet another useless feature we have to blacklist in there.
I think WebPros should probably prioritize security and usability over rather invasive easter eggs (personally don't mind them when they're actually hidden, and not overboard like this), especially in a time of increased CVE discoveries (see the recent cPanel CVEs).
 
Hi @Doost,

Thanks for the feedback - point taken on the defaults, and as mentioned earlier in the thread, we are collecting partner input on this functionality, and it will reach the product team.

On the security side: both panels are covered by the same security process at WebPros, and critical CVEs are addressed carefully and promptly for cPanel and Plesk alike. When a CVE is published for one panel and you do not see a corresponding Plesk release, it means the issue either does not affect Plesk or was already resolved on our side - absence of a release is not absence of attention.

That said, if you have anything specific in mind regarding the recent CVEs - a concern, an observation, or something you believe affects Plesk - I would genuinely like to hear it. Feel free to share it here or via private message, and I will make sure it gets to the right team.

Thanks again for taking the time to write this up.
 
Back
Top