I updated my Magento 2.4.1 installation to 2.4.2 a while ago.
Since then it works as expected. No problems.
But now I discovered that wenn I call magento setup:upgrade the update starts and after all finishes, I can't see the options in my configurable products (sizes, colors,...). They are just gone. I have no clue why.
Before the upgrade
After the upgrade
The configuration options are missing after the upgrade and the console shows me an error which was not present before.
…/static/version1623092606/frontend/Magento/luma/de_DE/configurableVariationQty.js
And I can't find a file called configurableVariationQty.js anywhere on my server. Where does it come from? Should it have been installed with the upgrade?
Does anybody have a clue what’s going on here? How can I gather more information?
If you are running production mode (see bin/magento deploy:mode:show), you need to run bin/magento setup:static-content:deploy after setup:upgrade, as well.
It might also be needed to reindex with bin/magento indexer:reindex.
Tracked it down finally.
This issue helped me find the solution:
https://github.com/magento/inventory/issues/3276
The patch, referenced in the last post (https://github.com/magento/inventory/commit/337f8b7d56d81c217d5bf2bac180b315fd6120d0#diff-669c3cc08f646d82fcfa47b2385c3301fb1ee58c863ab0c91812e9e0482d8569) helped me to solve my problem.
InventoryCatalogFrontendUi/Model/GetProductQtyLeft.php already looked like the patched version in my installation.
But I had to patch InventoryConfigurableProductFrontendUi/view/frontend/web/js/configurable-variation-qty.js in my installation.
After adding the && response.qty > 0 all worked well again.
This error was gone
and the configurable options showed up again.
Related
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.
Upgraded to Magento 2.1.9 from 2.1.8.
Steps to replicate:
Deploy in production mode
deploy:mode:set production
Set the following paths to 0 within db:
dev/template/allow_symlink
dev/js/merge_files
dev/js/enable_js_bundling
dev/js/minify_files
dev/css/merge_css_files
dev/css/minify_files
Set the following paths value to 1:
dev/static/sign
Deploy static assets:
php bin/magento setup:static-content:deploy en_AU en_US && php bin/magento c:f
Results
Go to mydomain.com/admin and see:
Inspect this, what do we find:
A bunch of 404s to static minified files, visiting these files in from CLI also confirms they actually don't exist.
I thought that it might be a locale issue, saw this article but this didn't work for me.
I have minification turned off in my settings, all caches cleared (including Varnish). Yet this issue still persists. Front-end appears fine on the other hand.
Any help would be much appreciated, otherwise I suppose I could train the client to edit the db directly!
If you have install magento2.x in your local PC then if you can try to change line #607.
Magento\Framework\App\View\Asset\MaterializationStrategy\Symlink
to
Magento\Framework\App\View\Asset\MaterializationStrategy\Copy
Open your console/terminal, and type these commands
php bin/magento setup:upgrade
php bin/magento setup:static-content:deploy
php bin/magento indexer:reindex
php bin/magento cache:flush
It's working fine.
if you can try it....
I have a dirty fix whilst I continue to look at a more permanent solution. Create a permanent redirect pointing from my custom adminhtml theme - the one that doesn't get deployed to the "Magento" theme which does exist:
rewrite ^/adminhtml/<CUSTOM_THEME>/backend/(.*)$ /adminhtml/Magento/backend/$1 permanent;
In my case I am using nginx. If anyone else is experiencing this issue I hope this will provide a temporary solution for the time being.
I want to switch to laravel 5, but have some trouble with ide - autocompletion. I'm using phpstorm.
In google, the answers always end up with suggesting to use https://github.com/barryvdh/laravel-ide-helper . But it seems like it is broken for Laravel 5.
The steps I am doing are:
Install Laravel 5
composer create-project laravel/laravel
Require ide-helper
composer require barryvdh/laravel-ide-helper
Added 'Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider',
....
'Illuminate\Translation\TranslationServiceProvider',
'Illuminate\Validation\ValidationServiceProvider',
'Illuminate\View\ViewServiceProvider',
'Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider',
Trying to generate the helper file
artisan ide-helper:generate
But it always breaks with following error:
exception 'InvalidArgumentException' with message 'There are no commands defined in the "ide-helper" namespace.' in C:\xampp\htdocs\test\vendor\symfony\console\Symfony\Component\Console\Application.php:501
0 C:\xampp\htdocs\test\vendor\symfony\console\Symfony\Component\Console\Application.php(535): Symfony\Component\Console\Application->findNamespace('ide-helper')
1 C:\xampp\htdocs\test\vendor\symfony\console\Symfony\Component\Console
\Application.php(192): Symfony\Component\Console\Application->find('ide-helper:gene...')
2 C:\xampp\htdocs\test\vendor\symfony\console\Symfony\Component\Console\Application.php(126): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Outpu
t\ConsoleOutput))
3 C:\xampp\htdocs\test\vendor\laravel\framework\src\Illuminate\Foundation\Console\Kernel.php(91): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Out
put\ConsoleOutput))
4 C:\xampp\htdocs\test\artisan(36): Illuminate\Foundation\Console\Kernel->handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
5 {main}
Maybe someone had the same issue and can help me.
I'm open for different solutions for autocompletion other than barryvdh's ide-helper.
I had the same problem and this fixed it:
Before you run php artisan ide-helper:generate command, make sure to php artisan clear-compiled and php artisan optimize as it's noted here. If this didn't fixed your problem, take a look at this and clean out PhpStorm cache by choosing this:
File | Invalidate Caches/Restart
After auto restarting, PhpStorm will index again and everything should work fine.
Sorry for my bad english.
Edited: After these steps import your Facades like this use Illuminate\Support\Facades\Auth link them inside your _ide_helper.php file like use Auth.
I ran into the same problem. These are the steps I took to fix it:
I double-checked that 'Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider' was correctly added to the providers array in config/app.php.
I executed artisan clear-compiled. Had no effect
Executing php artisan config:clear fixed the problem.
This error occur when the package ServiceProvider isn't loaded.
If you have multiple config file (like for different environment), you must ensure that the service provider is well set in all the environment you which to use the package.
config/
local/
app.php
app.php
to verify if the service provider is correctly set to your application you can dump the app config:
dd(\Config::get('app.providers'));
Try this:
php artisan ide-helper:generate
Here is an updated gist as of this month. I have tested this and it works in PHPStorm.
Also you don't have to install this through composer. Copy the gist and save it in your root folder as _ide_helper.php.
So my problem is that for some some reason installation of some plugins kills my bitnami redmine "permanently" (thin_redmine and thin_redmine2 stops after like 5 seconds).
The plugin which most recently did this is Finance Plugin from RedmineCRM. Version should be okay.
http://www.redmine.org/plugins/finance
Method I used (note that I added :migrate in the second line compared to their website (Is this the problem?)):
bundle install --without development test
bundle exec rake redmine:plugins:migrate NAME=redmine_finance RAILS_ENV=production
Am I missing or wrongly doing something? (Please note that I'm not really an expert in this field so I mainly go after how to-s.)
Are there anymore prerequirements for this (besides a very basic working redmine) e.g. I did not set up e-mail notifications, can stuff like this cause the problem?
Unfreez the gemfile. It solved the problem.
I haven't been able to find any resources on how to do this.. Anyone have any ideas or resources?!
I've tried changing the ./configure options and I'm solving things one at a time but it seems like this method could take forever.. My current error is..
checking for jpeg_read_header in -ljpeg... no
configure: error: Problem with libjpeg.(a|so). Please check config.log for more information.
I'm running Snow Leopard.
Any help would be great,
Matt Mueller
I know this is an old question- but still relevant.
I'm updating my MAMP and am keeping up to date on PHP's stable releases by using a guide I found at davidgolding.net
The Guide goes as follows:
First, run the
phpinfo()
function in a PHP script on your localhost or go to PHPMyAdmin and hunt down the configuration page. You should see a large chunk of configuration markup at or near the top:
'./configure' '--with-mysql=/Applications/MAMP/Library'
'--with-apxs2=/Applications/MAMP/Library/bin/apxs'
'--with-gd' '--with-jpeg-dir=/Applications/MAMP/Library'
'--with-png-dir=/Applications/MAMP/Library' '--with-zlib'
'--with-freetype-dir=/Applications/MAMP/Library'
'--prefix=/Applications/MAMP/bin/php5' '--exec-prefix=/Applications/MAMP/bin/php5'
'--sysconfdir=/Applications/MAMP/conf/php5' '--with-soap'
'--with-config-file-path=/Applications/MAMP/conf/php5'
'--enable-track-vars' '--enable-bcmath' '--enable-ftp' '--enable-gd-native-ttf'
'--with-bz2=/usr' '--with-ldap' '--with-mysqli=/Applications/MAMP/Library/bin/mysql_config'
'--with-sqlite' '--with-ttf' '--with-t1lib=/Applications/MAMP/Library'
'--enable-mbstring=all' '--with-curl=/Applications/MAMP/Library' '--enable-dbx'
'--enable-sockets' '--enable-bcmath' '--with-imap=shared,/Applications/MAMP/Library/lib/imap-2006i'
'--enable-soap' '--with-kerberos' '--enable-calendar'
'--with-pgsql=shared,/Applications/MAMP/Library/pg' '--enable-dbase'
'--enable-exif' '--with-libxml-dir=/Applications/MAMP/Library'
'--with-gettext=shared,/Applications/MAMP/Library' '--with-xsl=/Applications/MAMP/Library'
'--with-pdo-mysql=shared,/Applications/MAMP/Library' '--with-pdo-pgsql=shared,/Applications/MAMP/Library/pg'
'--with-mcrypt=shared,/Applications/MAMP/Library' '--with-openssl'
Copy and paste this whole chunk into your text editor and remove the single quotes (search and replace should do it). Look for the flag
--with-pdo-mysql=shared,/Applications/MAMP/Library
and replace it with:
--with-pdo-mysql=/Applications/MAMP/Library
If you don’t do this, you might end up with an error.
ld: symbol(s) not found
Finally, add the following flag to the end:
--without-iconv
After you have downloaded the latest PHP release of your choosing from PHP Sources Snapshots,
cd
to the downloaded directory in Terminal. Paste your reformatted configuration string (all of it, including the beginning ./configure command) and run it.
After the configuration phase is finished, run:
$ make
$ sudo make install
Relaunch MAMP, and you’re good to go.
The current version (1.9) of MAMP / MAMP PRO includes PHP 5.3 and is available on the MAMP download page.
This is bound to cause a lot of headaches. The simplest solution is to navigate over to the mamp website and grab the latest version of the application. Download it, hit the install button and you will find your php version has been updated to the latest version...
Hope this helps, I spent quite a bit of time fiddling about with upgrading PHP before I actually looked :S
I don't know if MAMP has changed its configuration in the last few years but none of the solutions here helped me. What I did, and what worked right away was:
Download the PHP version you want from MAMP
Unzip it and move the new PHP folder into the MAMP/bin/php folder where you will see other subfolders with names like php5.3.7
Restart MAMP
Go to the PHP panel under Server in MAMP and choose the new verion of PHP from the drop menu
Start MAMP.
reinstall whole MAMP is very safe. You dont even need to take a copy of old MAMP. the new install does it on its own. just feel free to download new MAMP and click install. only care u need to take is this
Edit httpd.conf and open up line to include vhosts.conf and copy old vhosts.conf from old MAMP folder.
Goto MAMP Download page
then choose
an update from the Heading
"Additional PHP versions for MAMP PRO 2.2"