• 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.

Question How do you use GULP on a Plesk server?

Thomas552

New Pleskian
I'm using the roots/sage theme, which uses gulp watch to compile the CSS.

It was originally developed on a local machine, so everything is setup for it to compile, but I'm trying to get gulp watch to run on the server.

Does any know how to get gulp working via Plesk command line or any other way?
 
Well, which OS and OS version are we talking about...? Are you the server admin or a customer?

Apart from Plesk being installed, your server is basically a linux distro that could also be used as a workstation, for tasks such as this.

That being said, the question to ask yourself at this point would be: is this prudent? My usual advice to Plesk admins is to keep their servers as minimal and as close to stock OS as possible, because this approach greatly simplifies regular maintenance tasks, not to mention upgrades or troubleshooting when something goes sideways. In my book, tasks like this don't belong on a server or rather they belong on a separate build instance or on a workstation.
 
Well, which OS and OS version are we talking about...? Are you the server admin or a customer?

Apart from Plesk being installed, your server is basically a linux distro that could also be used as a workstation, for tasks such as this. mybkexperience

That being said, the question to ask yourself at this point would be: is this prudent? My usual advice to Plesk admins is to keep their servers as minimal and as close to stock OS as possible, because this approach greatly simplifies regular maintenance tasks, not to mention upgrades or troubleshooting when something goes sideways. In my book, tasks like this don't belong on a server or rather they belong on a separate build instance or on a workstation.

Thanks for the reply....
 
Back
Top