I am trying to finish converting a Drupal | 9.3 site and update The Webform Module for Drupal using Composer. A warning appears in Drupals admin-interface that using auto-update has a good chance of failing.... manual update MIGHT work.... and using composer is the recommended way plus, long term... no Composer, not much chance of updating compex modules.
***At bottom of this post, details with the commands and output I received using Composer are viewable.
I'm on shared hosting and the host investigated through cPanel and on to the upstream wholesale provider. "proc_open" is disabled server-wide as it can potentially traverse the entire server skel, a potentialy security risk to other hosts on the shared server. "proc_open" cannot be enabled for just one host on this system or any system that isn't in a dedicated environment.... all alternatives ^$up the cost of operation BIG.
Does anyone know if there is in fact a workaround? All options/feedback greatly appreciated. I know I'm not alone in this. Has anyone successfully done the manual update to Webform 6.2#beta? Long term, manual updates for Drupal Modules are going to become more and more difficult sans composer....
DRUPAL WEBFORM
6.2.0-beta2 released 15 February 2022
Works with Drupal: ^9.2
Install: $ composer require 'drupal/webform:^6.2#beta'
Thank you!
############# #various command/output #################
Lock file op#drupal/webform 6.2.0-beta1
Writing lock file
Installing dependencies from lock file including require-dev
Nothing to install, update or remove
2 package suggestions were added by new dependencies, use composer suggest to see details.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
41 packages you are using are looking for funding.
Use the composer fund command to find out more!
Scaffolding files for drupal/core:
Copy [web-root]/sites/default/default.services.yml from assets/scaffold/files/default.services.yml
Copy [web-root]/sites/default/default.settings.php from assets/scaffold/files/default.settings.php
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
[Symfony\Component\Process\Exception\RuntimeException]
The Process class relies on proc_open, which is not available on your PHP installation.
TRIED THIS AS WELL
[user#server web-services]$ composer update drupal/webform --with-dependencies
Loading composer repositories with package information
Updating dependencies
Package "drupal/webform" listed for update is not locked.
Nothing to modify in lock file
Installing dependencies from lock file including require-dev
Package operations: 0 installs, 0 updates, 1 removal
Removing drupal/webform 6.2.0-beta1
Deleting modules/contrib/webform - deleted
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
41 packages you are using are looking for funding.
Use the composer fund command to find out more!
[Symfony\Component\Process\Exception\RuntimeException]
The Process class relies on proc_open, which is not available on your PHP installation.
Related
I am trying to use Composer to update a Drupal module. After reading a lot, I am presuming that proc_open is disabled in my shared hosting env. If that is the case, can it be enabled for just one hostname or is it server-wide?
"The Process class relies on proc_open, which is not available on your PHP installation."
From the host: Cpanel states the shell php is system wide so we cannot edit it for just this site. (this comes directly from a ticket they used at cPanel)
The module I was trying to update is for Drupal, Webform latest stable version. Not recommended to update with GUI or Manually....
I understand that proc_open is a potential security risk to other hosts but is there ANY workaround short of a dedicated server? Upping the co$t of doing business by a LOT :)
$ composer require 'drupal/webform:^6.2#beta'
./composer.json has been updated
Running composer update drupal/webform
Loading composer repositories with package information
Updating dependencies
Lock file op#drupal/webform (6.2.0-beta1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove
2 package suggestions were added by new dependencies, use `composer suggest` to see details.
Package doctrine/reflection is abandoned, you should avoid using it. Use roave/better-reflection instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
41 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Scaffolding files for drupal/core:
- Copy [web-root]/sites/default/default.services.yml from assets/scaffold/files/default.services.yml
- Copy [web-root]/sites/default/default.settings.php from assets/scaffold/files/default.settings.php
Installation failed, reverting ./composer.json and ./composer.lock to their original content.
[Symfony\Component\Process\Exception\RuntimeException]
The Process class relies on proc_open, which is not available on your PHP installation.
We are building Node.js microservices. For some reusable components we have created a utils folder. This folder is outside the actual microservices package. When we run the microservices, we can refer to that code using require(../../utils/logger) and it works like a charm.
However when trying to create the docker image for my microservices
project the container gives me an error saying:
Error: Cannot find module '../../Utils/logger
which makes a lot of sense as we are building the docker image inside the microservice project.
There are few architectural decisions which needs to be taken here:
We move the utils code into each microservice as required.
Pro: Microservice remains self sustained completely and no code level dependency on any other package.
Cons: Maintenance of cross cutting concerns and the changes would be cumbersome.
2.Create a private npm module and inject dependency into the microservice package.json file. Not sure if that would work.
Any suggestions on this are highly appreciated.
Best,
- Vaibhav
Don't use require(../../utils/logger), use npm packages
You should avoid using same files for microservice with symlink or requiring from one folder, because it destroys Loose coupling.
Loose coupling is a design goal that seeks to reduce the
inter-dependencies between components of a system with the goal of
reducing the risk that changes in one component will require changes
in any other component. Loose coupling is a much more generic concept
intended to increase the flexibility of a system, make it more
maintainable, and makes the entire framework more "stable".
Simply put, you can't have different version of your logger file, but you can have different version of your logger npm package.
Implementation details for using npm modules as reusable components for Node.js microservices:
Chose naming convention for packages. My advice is scoped packages. Example: #vaibhav/logger
Chose npm registry. There are such options:
2.1. npmjs.com and public packages. It's free, but your packages should have only universal code without any business-valuable details.
2.2 npmjs.com with private packages. It's fast, but not free.
2.3 verdaccio your own npm registry server. It's free simple Node.js solution, which should be install as server in your infrastructure.
2.4 nexus. Universal private registry with npm and docker support.
If you use 2.3 or 2.4 solution, then you need to choose ip or link for your server. My advice is use link. Example https://your-registry.com
If you use 2.3 or 2.4 solution, the you need to chose install approach in your .npmrc file inside your microservice. There are two options:
install all required packages from your registry. The .npmrc file will looks like registry=https://your-registry.com. Your registry should be able to cache public packages.
install only your package from your registry, install other packages from public registry. The .npmrc file will looks like #vaibhav:registry=https://mycustomregistry.example.org
Define processes for package development, publishing and updating the package version in microservice package-lock.json file. In our projects we define processes in this way:
We use GitHub flow for package development. There are only master branch for publishing and feature branches for development. Master branch can be updated only with pull requests from developers or commits from CI server.
We use Jenkins as continues integration server for autoupdating version and publish after merging pull request. Jenkins runs npm version command for update version, then publishes new commit to master branch and then publishes to npm registry. Jenkins checks some our rules and use npm version with patch or minor param. Updating major version is breaking change, which we do manualy.
We don't have 100% automated process for updating the package version in microservices. We automate only opening pull requests with new package version in package-lock.json file. Developers should check build status and press merge button manually.
Its not part of your question to elaborate how to deal with shared libraries in Microservice-Ecosystems and what to avoid there, but if you like, you should read this up to get you at least a list for pros and cons of "sharing".
Beside that, you can create a library container which only offers this library to be mounted.
version: "2"
services:
shared:
image: me/mysharelib
m1:
volume_from:
- shared:ro
m2:
volume_from:
- shared:ro
while your mysharedlib image looks more or less like this
FROM busybox
COPY bin/busyscript.sh /usr/local/bin/busyscript
WORKDIR /your/lib/folder
VOLUME /your/lib/folder
CMD ["busyscript"]
and your busyscript is just a dummy like this
#!/bin/sh
#set -x
pid=0
# SIGTERM-handler
term_handler() {
if [ $pid -ne 0 ]; then
kill -SIGTERM "$pid"
wait "$pid"
fi
exit 143; # 128 + 15 -- SIGTERM
}
# setup handlers
# on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handler
trap 'kill ${!}; term_handler' SIGTERM
echo "Started DW php code"
# wait forever
while true
do
tail -f /dev/null & wait ${!}
done
As you see, m1/m2 ... m10 mount the library which and it is truly shared across all microservices.
Alternatives:
You can for sure use an private NPM packages or simply package the shared lib into the microservice m1..m10 during image build time.
What describe above especially suits you well when you want to replace the shared library in the stack with very little overhead and want to ensure the library is in-sync for all container instancs
I'm used to deploy code depending on Composer (PHP's NPM cousing), that sports .json and .lock files. The first one describes the package and your version constraints, and the second one lists exactly what was installed. Always there's a lock file and you run composer install you're sure to receive the same set of packages; running composer update will re-read the json file, install new versions, and update the lock file.
That's awesome for production deployment, since you don't need to checkout your dependencies to your versioning system and you're sure to have the exact same set of dependencies in production as you have in development.
My question is: how to best automate deployment of NPM-dependent code? Is it possible to achieve a method similar to Composer? I've noticed that npm install only installs what's first available in the package.json file. After the first run, i.e. if you change a version constraint you must manually npm update that package - and that would render automate deployment useless, as there's no way to check in to versioning "update this package here to a new version"...
npm shrinkwrap is a analog of composer.lock file. It will generate a npm-shrinkwrap.json, that have all deps with version in it, so you can use it to deploy to production env. Also you can try a various libs from npm to lock versions or search for updates of it without changing packages.json.
I am struggling around a wrong usage of composer, for sure.
I set up this repository: https://github.com/alle/assets-merger
I forked the project and was just trying to make it a kohana-module, including all the dependencies.
As for it would need the YUI comporess JAR, I was trying to make just that JARfile as a dependency, and I ended to declare it in the composer.json file (please, look at this).
Once I need to add my new package to a project I add it in the require section as follows:
...
"alle/assets-merger": "dev-master",
...
But the (latest) composer update command says:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for alle/assets-merger dev-develop -> satisfiable by alle/assets-merger[dev-develop].
- alle/assets-merger dev-develop requires yui/yuicompressor 2.4.8 -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
And my story ends here.
How should I configure my composer.json in the https://github.com/alle/assets-merger repository, in order to include it as a fully satisfied kohana-module in other projects?
Some things I notice in your composer.json.
There is a version of that CSS minify available on Packagist which says it is just a copy of the original Goole-Code hosted files, but with Composer: natxet/cssmin. It is version 3.0.2, but I think that shouldn't make a difference.
mrclay/minify is included twice in the packages with the same version. It also is available on Packagist. You will probably already use that (version 2.2.0 is registered, and because you didn't turn of Packagist access, it will be generally available for install unless a version requirement or conflict prevents it).
You are trying to download a JAR file (which is a java executable without and PHP), but try to get PHP classmaps out of it. That will fail for sure.
You did miss the big note in the Composer documentation saying that Composer cannot resolve repositories mentioned in sub packages, only in the root package. That means that whatever you mention in your alle/asset-merger package will not be used if you use that package anywhere else. You'd have to duplicate these repositories in every package in addition to adding the package name itself as "required".
What this means is that you probably avoided missing mrclay/minify because it is available on Packagist, you might as well have added the cssmin by accident, but you definitly did not add YUICompressor.
But you shouldn't add this in the first place, because it is no PHP software. You can however add post-install commands to your projects. All your Composer integration does is download the JAR file. You can do that with a post-install or post-update command. See the documentation here.
I have just installed laravel 4 using composer in my linux os. While it was downloading and installing all the packages it also gave me a lot of suggestions. It asked me to install
symfony/config
symfony/yaml
symfony/dependemcy-injection
symfony/class-loader
symfony/validator
doctrine/dbal
symfony/expression-language
doctrine/annotations
ext-phpiredis
ext-curl
ext-gmp
paer-pear/PHP_Compat
ext-intl
graylog2/gelf-php
raven/raven
doctrine/couchdb
ruflin/elastica
ext-amqp
ext-mongo
aws/aws-sdk-php
rollbar/rollbar
Should I install these things. And if I have to then how would I install them? Thanks in advance. :D
You don't have to install them for Laravel to function any differently. You should only install them if you explicitly plan on using them. The install directions are usually found on the project's github page.
All of those packages can be found on http://www.packagist.com where you will easily be able to find them, see install directions, usage, etc...
To install them, usually you'd just add the appropriate line, usually found in the documentation, to your composer.json file, run composer update and they should automatically be made available to your project.
You got suggestions for both PHP library packages (PHP code) and PHP extensions (C code).
You should only install the PHP libraries if you know you want to use them. The suggestion feature of Composer allows any developer of a package to let Composer announce on update that there might be more software that enhances the library, but is entirely optional. The description next to the package name might have details on why the package could be installed. For example, a library for FTP and HTTP access might want to use existing FTP or HTTP clients, and will announce both as suggestions. If you decide you don't need FTP access, you only require the HTTP client to be used.
You cannot install PHP extensions via Composer. Installing them usually requires some kind of administrator access to the server, and depends on which OS is installed and whether or not it allows to install these extensions as a regular software package, or needs to have the PECL install toolchain available. If a PHP library suggests a PHP extension, then this extension also is completely optional, and you probably will know that if you need that feature (like access to MongoDB), you need the PHP extension as a prerequisite, but are likely to already have it installed (which would skip this suggestion from the list because it is fulfilled).