I'm managing multiple shopware 6 shops with a lot of plugins installed. The backend only allows to update one plugin which is quite time consuming because the updates done in 2 steps:
the update is loaded (loader circle)
the backend is relaoded (html reload)
why is there no "update all plugins" button (like e.g. in wordpress ;-) )?
best,
Roman
I'm expecting an gui or a cli command which allows to download and update all plugins with pending updates at once.
Not excactly what you're asking for but you can pass multiple names to the cli command:
./bin/console plugin:update PluginName1 PluginName2 -n
You can also pass an empty string like this and it will update all plugins:
./bin/console plugin:update "" -n
The -n will skip the interaction to confirm the update for the given plugins.
To do that the plugins have to be present in the new version you want to have. I'd recommend to use composer to manage the plugins. Shopware has it's own registry where you can get all plugins via composer. You can find the configuration in your Shopware account. After you've bought a plugin you'll get a bearer token and can require your plugins like this:
composer require store.shopware.com/pluginname
So you will still have two steps to get the plugin and afterwards update it, but it's much more convenient than doing it in the administration.
Edit: Added the -n flag as suggested by tinect below.
Related
Context
I will rely on a component shipped with Gcloud SDK CLI.
For migration purposes and other reasons, I want to know which version of the cloud-sdk starts shipping this component and avoid the "install the latest version".
My issue
In the official changelog: https://cloud.google.com/sdk/docs/release-notes, there are no references to the component I am looking for.
Tries
I have tried to run this command naively
for gcloud_version in 390.0.0-alpine 391.0.0-alpine 392.0.0-alpine 393.0.0-alpine; do
echo "---> ${gcloud_version}"
docker run --rm -ti google/cloud-sdk:${gcloud_version} gcloud components list
done
Unfortunately, every list do not show the component I am waiting for (even the latest version of gcloud, 393 at the time of writting).
Discovery
However, when I run gcloud components install MY_UNLISTED_COMPONENT it works ...
Not a very reliable way to find out which version has the component I want.
Do you know if:
this is an issue?
I can report this somewhere?
It is relevant to do it?
Thanks for your help!
From #DazWilkin
It would be helpful if you included the name of the public albeit unlisted component in your question. The Release Notes includes a "Send Feedback" option and you may want to provide this feedback there.
it's reasonable to expect it to be documented. I encourage you to send feedback via the release page and to consider filing an issue on Google's public Issue Tracker.
I've developed a sylius based site on a local server. I want to deploy it in production on my OVH server.
In the Sylius Sylius Cookbook, I did not find any particular procedure. So I followed the normal procedure.
Upload my code to the production server with a "git clone" of my git repository
Install my vendor dependencies "php composer install"But this step does not work because it never ends. At the end, I always have something like this:
Executing script cache:clear
[Symfony\Component\Process\Exception\ProcessTimedOutException]
The process "'/usr/local/php7.3/bin/php' '--php-ini=/usr/local/php7.3/etc/php.ini' './bin/console' --ansi cache:clear" exceeded the timeout of 20000 seconds.
I even tried "composer clearcache" before. It hasn't changed anything.
I am now trying "COMPOSER_PROCESS_TIMEOUT = 50,000". The "composer install" was sent 12 hours ago and is still not finished ...
Has anyone ever had this problem or know how to find a solution?
Is there a special step to do when working with sylius?
Because I really don't know what to do.
UPDATE:
My main lead at the moment is that the problem would come from sylius because I am trying to create a new install of sylius with the symfony 4 structure like this
composer create-project sylius/sylius-standard
Same result:
Executing script cache:clear
[Symfony\Component\Process\Exception\ProcessTimedOutException] The
process "'/usr/local/php7.3/bin/php'
'--php-ini=/usr/local/php7.3/etc/php.ini' './bin/console' --ansi
cache:clear" exceeded the timeout of 20000 seconds.
I tried to run composer create-project with the --no-scripts flag and run php bin/console cache:clear separately after that. The bug reappears with the second command.
You should first check that you are setting permissions right for your var folder, as per symfony install instructions.
You might also just be running out of resources on that server. Had the same issue on my last 1.7 project. The problem came from the cache:clear's warmup (probably because sylius has tons of dependencies and I added a bunch more). You might wanna try editing the composer.json "scripts" to:
"scripts": {
"auto-scripts": {
"cache:clear --no-warmup": "symfony-cmd",
"assets:install %PUBLIC_DIR%": "symfony-cmd"
},
Or, as you did per your update, run the install with the --no-script flag followed by bin/console cache:clear --no-warmup (do make sure you are installing the assets after that).
Cache will then be generated on your first visit to the website instead of being generated thru warmup.
This is a problem not just with the install, you'll have to use this workaround each time you wanna clear cache. My project is in production and working well using this, just gotta remember to visit the website once you did so that a random user doesn't have longer loading because the cache hasn't been generated yet.
I worked all day to get Xampp running and install TYPO3 on it. Now I'm logged in the backend, but many admin modules are not displayed, such as Templates, Access etc. - There must be something I've done wrong, but I've got no idea. these are the modules shown Missing: View, Info, Functions, Template, Access, Backend Users, Log, DB Check, Configuration, Reports.
Most backend modules are shipped as extensions, which can be installed, uninstalled, activated and deactivated.
If you installed TYPO3 by using the traditional installation method (extracting the TYPO3 source package), go to ADMIN TOOLS → Extensions and make sure, the missing modules are activated. For example, "Log" is provided by the system extension belog and "Templates" by tstemplate. You can activate/deactivate extensions by clicking on the icon left-hand-side of their title.
If you installed TYPO3 by using PHP Composer (see documentation), make sure all packages are included in your composer.json file. For example typo3/cms-belog, typo3/cms-tstemplate, etc. You can add/remove packages with the following composer commands on the command line (for example typo3/cms-belog):
composer require typo3/cms-belog
composer remove typo3/cms-belog
In the unlikely event that this does not solve your issue, review file typo3conf/PackageStates.php. This file contains a list of all extensions (system extensions, as well as community extensions), currently available in your TYPO3 system.
It could also be that your admin user, who may have been migrated from an older version, is not a newly introduced system maintainer.
https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.0/Feature-82266-BackendUsersSystemMaintainers.html
If that is the case, you can easily create an new "system maintainer user" from the install environment. Maintenance > Create Administrative User
I had the same problem. The required extension were also present in PackageStates.php but still the backend menu options like Admins Tools, Extensions, Maintenance were not visible.
The reason was that that admin user was not listed as a System Maintainer
To make a backend user a System Maintainer do the following
Login with admin password to /typo3/install.php
Setting > Manage System Maintainers
select and save backend users you want as System Maintainers
Now go to backend at /typo3/ and you should see the "Admins Tools" menu options
You can use https://get.typo3.org/misc/composer/helper to figure out the missing extensions. If you simply want to install all extensions, klick on TYPO3/FULL and copy and paste the code to your console.
composer require "typo3/cms-about:^9.5" "typo3/cms-adminpanel:^9.5" "typo3/cms-backend:^9.5" "typo3/cms-belog:^9.5" "typo3/cms-beuser:^9.5" "typo3/cms-core:^9.5" "typo3/cms-extbase:^9.5" "typo3/cms-extensionmanager:^9.5" "typo3/cms-feedit:^9.5" "typo3/cms-felogin:^9.5" "typo3/cms-filelist:^9.5" "typo3/cms-filemetadata:^9.5" "typo3/cms-fluid:^9.5" "typo3/cms-fluid-styled-content:^9.5" "typo3/cms-form:^9.5" "typo3/cms-frontend:^9.5" "typo3/cms-impexp:^9.5" "typo3/cms-indexed-search:^9.5" "typo3/cms-info:^9.5" "typo3/cms-install:^9.5" "typo3/cms-linkvalidator:^9.5" "typo3/cms-lowlevel:^9.5" "typo3/cms-opendocs:^9.5" "typo3/cms-recordlist:^9.5" "typo3/cms-recycler:^9.5" "typo3/cms-redirects:^9.5" "typo3/cms-reports:^9.5" "typo3/cms-rsaauth:^9.5" "typo3/cms-rte-ckeditor:^9.5" "typo3/cms-scheduler:^9.5" "typo3/cms-seo:^9.5" "typo3/cms-setup:^9.5" "typo3/cms-sys-action:^9.5" "typo3/cms-sys-note:^9.5" "typo3/cms-t3editor:^9.5" "typo3/cms-taskcenter:^9.5" "typo3/cms-tstemplate:^9.5" "typo3/cms-viewpage:^9.5" "typo3/cms-workspaces:^9.5"
I'm using latest Jenkins (v 1.590) LOL, but Jenkins official site say: 1.588. I'm 200% sure that I did see 1.589 and 1.590 few days back on Jenkins official download site(when I wanted to upgrade Jenkins to newer version).
This is what I see at the bottom of my Jenkins instance page.
Page generated: Nov 19, 2014 12:07:51 PMREST APIJenkins ver. 1.590
Now, the issue I'm facing is: Since I upgraded few of the plugins and Jenkins itself recently, some of the jobs are missing (I see this can happen during upgrades but upgrading to latest Jenkins should fix it and I'm two steps ahead of what Jenkins has on their official site, right):
I go to Manage Jenkins, Manage Plugins, Go to Available tab, check mark bunch of plugins to install (Artifactory, Maven project plugin etc ) and restart Jenkins using Jenkins GUI interface (which happens automatically once plugins are downloaded/installed in Jenkins GUI). After the restart, I do the same to see whether the plugin is now showing under "Installed" tab or not, but to my luck, it's still showing under "Available tab" and is NOT listed under "Installed" tab. If I open an existing job's configuration OR create a new job, the features available due to installed plugins are NOT visible i.e. if I installed Maven Project Plugin, I don't see an option to create a Maven style(2/3) project job while creating a new job.
I see valid .jpi files for respective plugins in plugins folder in JENKINS_HOME and there are some .pinned files as well. I have tried this a couple of times but the plugins are not visible once installed. Installation doesn't give any error during the whole operation.
Jenkins system log file (upon Jenkins restart) is attached (NOTE: Use slow download button to see/download this log file).
Download at SpeedyShare
or
[code]http://speedy.sh/x6vd8/Jenkins.System.Log[/code]
Issue was with the plugins permissions and expanded folders.
If you see under the plugins folder, you'll see .jpi or .hpi files (Jenkins jpi and Hudson hpi).
If I have awesomeplugin.jpi then there will be a folder called awesomeplugin.
Using Slav's hint, I ran bunch of checks and found out of 70+ plugins that I had installed, few of them somehow got "root" and "root" as their owner and group for their .jpi files and corresponding folder.
Now, The best solution one can try (the safest approach) is to chown -R yourvalidjenkinsuser:yourvalidgroup * and chmod -R 755 * as root. Before doing this, stop/shutdown jenkins.
I went even a step further, I first took backup of config files / whole jenkins JENKINS_HOME folder. Then I went to plugins folder and remove all .jpi corresponding folders using root account or as the owner of those folders (NOTE, I didn't delete the .jpi files). Then, I ran the above two commands (chown/chmod) and started Jenkins.
OUTCOME:
when I'm going to Jenkins > New item (to create a new job), Shenzi, all different types of jobs options are showing up (which included the Maven2/3 type job which I found got missing and few others like "Multi-configuration project" and Multijob Project job type.. all were missing and now they are showing up.
OK, I also checked one of the old job, went to its job's configuration and Shenzi!! I now see all the features there i.e. (Promoted Job plugin feature "Promtoe builds when.." check box. This feature which I configured sometime back, got missing but now it's showing up again.
Few of the Maven jobs that I created in past with Maven Release Plugin and Release Plugin POC work had bunch of steps in it. I found there was nothing in the Build step (after this whole mess), but after the above solution, I now see everything is back. I can see the configurations and build steps populated as they were set.
I hope this can help someone facing similar issue.
Still, I don't know why my Jenkins version is 1.590 (which Jenkins updated recently in automatic fashion) and Jenkins site today says, their latest Jenkins artifact is version 1.588 (seems like a mystery).
When you say "valid .hpi files", did you actually test that they are valid? You should be able to rename them to .zip and extract as a valid archive. An issue I face a lot is the network layer filtering system that we have in the office. It intercepts Jenkins's calls sometimes with the filtering system's login page, instead of whatever internet resource was being loaded.
If your .hpi files are not valid zip archives, open them in a text editor, and see if they are in the form of an html page/response of some kind.
We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?