oit-ai-web
My feedback
3 results found
-
19 votes
An error occurred while saving the comment oit-ai-web
supported this idea
·
-
5 votes
Thank you for your input! We will consider this functionality in upcoming releases if it is popular. Everyone, please continue voting for this feature if you consider it important.
--
IG
-
3 votes
Thank you for your input. We will consider this functionality in upcoming releases if it is popular. Everyone, please continue voting for this feature if you consider it important.
—
IG
We're running a web hosting service in the public sector for our university (hosting campus sites). We need to be able to proactively review, test, and install additional features per our change process and data security requirements.
For example: The SiteJet Builder extension takes customers to an external, third-party platform where they build their site. And while the site content (including files) is copied back to Plesk to be served locally, it's also backed to an external CDN that we have no insight into or control over.
So under our data security policies, we would not have offered that extension to our users.
However, Sitejet was pushed as a "core" feature and auto-installed, which caused confusion and forced us to make an urgent change to blacklist and remove it.
As a result, our confidence and trust in Plesk as a vendor that can work with common cross-industry business requirements has weakened.
None of these new, auto-installed extensions can be considered "core", and it's not reasonable to ask server administrators to know in advance that they need to update their server configuration files to block new extensions from being installed.
Instead, finding ways to communicate, showcase, and highlight new products in the ecosystem would be better.
Along with the feature showcase and offering demos, extension behaviors also should be better-documented, especially in regards to their security. If an extension shares data with a third-party, that needs to be clearly communicated and defined.