How to force composer to automatically ignore warrning? - automation

I'm making shell script which will install symfony 4 on ubuntu automatically. Since I'm using apache I have to execute:
composer require symfony/apache-pack
However, that command asks me to confirm:
composer require symfony/apache-pack
The recipe for this package comes from the "contrib" repository, which is open to community contributions.
Review the recipe at https://github.com/symfony/recipes-contrib/tree/master/symfony/apache-pack/1.0
Do you want to execute this recipe?
[y] Yes
[n] No
[a] Yes for all packages, only for the current installation session
[p] Yes permanently, never ask again for this project
(defaults to n): y
And I can't use --no-interaction options since default value is "n". How can I change this command not to ask me to confirm this action, but to automatically installs this apache pack?

This does not answer the question per se, but you can get rid of your specific warning per project if you add the following to your composer.json:
"extra": {
"symfony": {
"allow-contrib": true
}
}
or, even better, you can use Composer itself to set the flag before installing symfony/apache-pack:
composer config extra.symfony.allow-contrib true
This will make possible for Flex to install contrib recipes (i.e. recipes provided by the community) automatically, without asking for permission.

Related

Magento 2.3.5 Stores > Settings > Configuration missing configuration tab and field

I recently downgraded magento from 2.4 to 2.3.5p2 due to having some known issue, but after the change my
Stores > Settings > Configuration
appear only below config
it should not appear as image above but instead as below
I have disabled elasticsearch
I have run necessary command to install
bin/magento setup:upgrade
bin/magento setup:dicompile
bin/magento indexer:reindex
bin/magento cache:clean
I have give necessary read, write, execute access
I have run composer install and update
I have check on the user role and currently its been given Administrator role, so I expect it to gain full privileges
I already check on log but there is no error appear when the admin configuration page is being accessed
Please advice or guide ways that I can check and solve this problem

How to install PrestaShop 1.7 RC0 from Composer

I've just cloned the RC0 of PrestaShop 1.7.
I've run composer install but... what to do now?
I've tried to start the server with app/console server:start but, going to 127.0.0.1:8000 i receive this error:
Front not yet implemented! Or to delete...
So, this seems not to be right way:
app/console server:stop
and try another way...
Go with the classic localhost:
Link to database cannot be established: SQLSTATE[HY000] [1049] Unknown
database 'dev-prestashop-1_7'
Ok, I've to create the database... Database dev-prestashop-1_7 created... Try again...
Table 'dev-prestashop-1_7.ps_shop_url' doesn't exist
Yes, it's normal that it doesn't exists: I've not yet created it!
But, now comes the question: how I configure PrestaShop?
How can I start the installation procedure using the composer version of PrestaShop 1.7 RC0?
Once you have downloaded the zip of prestashop, you have to unzip it in a specified repo and give it the needed permissions. Then, you acces to this repo in a chosen browser.
For example (if you are under Linux system), let's say that your repo is called prestashop_1.7 and is put in /var/html/www, so you access to localhost/prestashop_1.7.
When accessing to this URL, un install unzipper will start and when finishing unzipping, it will lead you to the installation configuration.
You enter your configuration (you have to create the database manually) and that's it!

Ignore packagist.org on composer install | update

I'm using composer internally for managing internal software dependencies. Our repository server is on our private network and we aren't using any other package from any other repository than ours.
Every time you run
composer.phar [install | update]
It checks on packagist.org repositories after check our own repository. Beyond unnecessary, it takes longer when packagist is slow (or even down) or our internet connection is having a bad day.
Is there any way to tell composer to ignore checking for packagist repositories?
Yes, and it is even documented on https://getcomposer.org/doc/05-repositories.md#disabling-packagist-org
You may try to use this command:
$ composer config repositories.packagist false
You probably want to have a look at Satis: http://getcomposer.org/doc/articles/handling-private-packages-with-satis.md
It will make your life easier if you deal with a bit more of local/private packages, because otherwise you'd have to mention EVERY repository that might host required code. And you can use Satis to grab a copy of the versions into a ZIP file that can be hosted locally as well. See http://www.naderman.de/slippy/src/?file=2012-11-22-You-Thought-Composer-Couldnt-Do-That.html#13 for some hints of how to do it (press cursor keys left/right to skip through the presentation)
For extra bonus points, you'd add packagist.org as a Composer repository to Satis, require some needed packages, and set { "require-dependencies": true } to grab their dependencies as well. In your own code, you'd only set your Satis repository and disable Packagist.

No admin button in Trac

I've installed Trac .10.5, configured the trac.htpasswd file, and am able to log in and view/create tickets.
The problem is that I am currently unable to administer ticket components such as the versions that appear in the drop list on New Ticket.
From command line, I issued the following command:
trac-admin /foo/bar/trac/ permission add myusername TRAC_ADMIN
User "myusername" is listed in /foo/bar/trac/conf/trac.htpasswd, and I am able to successfully log in with that account.
Is there another step I'm missing in order to get access to a system configuration area? (for instance, setting up version numbers)
EDIT:
I discovered that version .10.* and below do not have web admin capabilities installed by default. http://trac.edgewall.org/wiki/WebAdmin
I downloaded the plugin source:
svn export http://svn.edgewall.com/repos/trac/plugins/0.10/webadmin/
Then ran setup.py, which generated a dist/TracWebAdmin-0.1.2dev-py2.6.egg file.
I then issued
easy_install TracWebAdmin-0.1.2dev-py2.6.egg.
Here's the output:
Processing TracWebAdmin-0.1.2dev-py2.6.egg
removing '/usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg' (and everything under it)
creating /usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg
Extracting TracWebAdmin-0.1.2dev-py2.6.egg to /usr/lib/python2.6/site-packages
TracWebAdmin 0.1.2dev is already the active version in easy-install.pth
Installed /usr/lib/python2.6/site-packages/TracWebAdmin-0.1.2dev-py2.6.egg
Processing dependencies for TracWebAdmin==0.1.2dev
Finished processing dependencies for TracWebAdmin==0.1.2dev
My trac/conf/trac.ini file has this section:
[components]
webadmin.* = enabled
I restarted the httpd server (trac uses Apache), and still have no Admin button.
Help greatly appreciated.
You're a bit too hastily seeking advice. Quoting my recent replies to trac-users mailing-list here:
This is most probably a permission issue and will continue with any more
recent Trac environment. Do something like
trac-admin permission add TRAC_ADMIN
to grant full permission to an admin user account, that is usable for
administration tasks. As known elsewhere, you should create a less
privileged account for your regular work to just use Trac.
But please note: Because you've got Python2.6, go for Trac-1.0, don't dare to use anything before this current stable version for a new project, really. Trac-0.10 has been abandoned long ago and 0.11 is unchanged since 2010 too.
You'll have no luck on almost any issue you may encounter, and you miss
a truck-load of great features that have been introduced. Trac 0.11 had
major API changes in many respects, 0.12 went for full i18n support, if
you care for that, and 1.0 is just on the edge, supporting the new db
access API as well as retaining compatibility code for not-yet-updated
plugins (quite a lot to be honest).
I had a similar issue with 0.11.x (minus the plug-in installation), and it turned out that the user account I was logging into via the shell was not the user account that owned the installation. This meant that the changes I was making did not have the right permissions - it is a requirement that all trac-admin changes are made by the installation owner.
Let's say the user that installed Trac was "jim", and I'd logged in as "bob" to use trac-admin in interactive mode. Reapplying a pre-existing permission to a will cause Python to throw an error and kick you off trac-admin. You have to remove the permission first, then reapply it as the other shell user.
The solution was to:
log back in as "bob" via the shell (e.g. "ssh -l bob trac.url.com")
trac-admin path/to/my/project
permission remove TRAC_ADMIN
exit (trac-admin)
exit (ssh)
log in as "jim" via the shell (e.g. "ssh -l jim trac.url.com")
trac-admin path/to/my/project
permission add TRAC_ADMIN
exit (trac-admin)
exit (ssh)
Now when you log into Trac as via a web browser, hopefully you should see the Admin button top right.

Apache is "Unable to initialize module" because of module's and PHP's API don't match after changing the PHP configuration

php -v gives this
PHP Warning: PHP Startup: memcache: Unable to initialize module
Module compiled with module API=20060613
PHP compiled with module API=20090626
These options need to match in Unknown on line 0
PHP Warning: PHP Startup: memcache: Unable to initialize module
Module compiled with module API=20060613
PHP compiled with module API=20090626
These options need to match in Unknown on line 0
bogus test name tests/
ps. i've upgraded from php 5.2 to 5.3. before this everything worked okay.
When you update the version of PHP (especially when going from version X.Y to version X.Z), you must update the PHP extensions as well.
This is because PHP extensions are developped in C, and are "close" to the internals of PHP -- which means that, if the APIs of those internals change, the extension must be re-compiled, to use the new versions.
And, between PHP 5.2 and PHP 5.3, for what I remember, there have been some modifications in the internal data-structures used by the PHP engine -- which means extensions must be re-compiled, in order to match that new version of those data-structures.
How to update your PHP extensions will depend on which system you are using.
If you are on windows, you can find the .dll for some extensions here : http://downloads.php.net/pierre/
For more informations about the different versions, you can take a look at what's said on the left-sidebar of windows.php.net.
If you are on Linux, you must either :
Check what your distribution provides
Or use the pecl command, to re-download the sources of the extensions in question, and re-compile them.
just
pecl uninstall module_name
then
pecl install module_name
Your problem is within the php5-dev package. I guess you went from php5.2 on an older linux version to php5.3. I did the same thing, and when I managed to install php 5.3 there was a conflict with php5-dev. For some reason it doesn't get upgraded to the new version. Dunno why is that and I don't care, however this makes your extension compiled with the older API version, while php ofc is with the newer api version. What I did to solve this problem was:
I removed php5-dev with
sudo apt-get remove php5-dev, then I ran sudo apt-get autoremove to get rid of the leftovers that were giving me the trouble, and after that I just installed php5-dev again.
sudo apt-get install php5-dev.
Once that was done, I removed my memcache with sudo pecl uninstall memcache and installed it again sudo pecl install memcache. Now both the module and the php had the same api version so I knew right away that I had the issue solved :)
Hope it helps.
It's possible that the modules are installed, but your PHP.ini still points to an old directory.
Check the contents of /usr/lib/php/extensions. In mine, there were two directories: no-debug-non-zts-20060613 and no-debug-non-zts-20060613. Around line 428 of your php.ini, change:
extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20060613"
to
extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20090626"
Then restart apache. This should resolve the issue.
I struggled with this issue for a long time and found out that when you run configure, just pass it the path to the correct php-config tool.
In my case, it was
./configure --with-php-config=/usr/local/zend/bin/php-config
... If you're unsure, run a locate php-config on your machine and find the right one amongst the different versions installed.
Hope this helps somebody in the future.
PS. My default php-config was set to 20090926 which is PHP 5.3. The one I manually entered as a param for ./configure was for PHP 5.4 (2010...)
I had this part enabled in my php.ini
extension=php_memcache.dll
[Memcache]
memcache.allow_failover = 1
memcache.max_failover_attempts=20
memcache.chunk_size =8192
memcache.default_port = 11211
After commenting these lines composer was installed in my windows 10
I had a similar issue after upgrading from PHP 5.5 to PHP 5.6. The phpize and php-config libraries being used to compile the phalcon extension were still the ones from PHP 5.5. I had to run the command below:
sudo apt-get install php5.6-dev
There will be a long stacktrace, the key information I saw was this:
update-alternatives: using /usr/bin/php-config5.6 to provide /usr/bin/php-config (php-config) in auto mode
update-alternatives: using /usr/bin/phpize5.6 to provide /usr/bin/phpize (phpize) in auto mode
I hope this helps someone.
Before you phpize, make sure to update your path ($PS1) to point to the new PHP! phpize uses your environment, and if you still have vestiges of your old PHP in your path or other parts of the environment, things will get hairy!
I'd the same error even after recompiling the modules.
But I solved it you just have to specify the absolute path of your phpize.
Here is the one that works with php 5.5. Download xampp 1.8.3 from here and download memcache dll from here
In my case in php.ini
[CLDbg]
extension=php_cl_dbg_5_3_VC9.dll
clport=6000
I removed Codelobster which support different PHP version, so need to update to:
[CLDbg]
;extension=php_cl_dbg_5_3_VC9.dll
;clport=6000
This problem has just happened to me and has been solved simply by increasing
memory_limit from 32 M to 64 M
You can adjust the value on the file where php.ini exists
locate php.ini
then choose the right file and search for memory_limit and after modifying it
you must reboot the apache
/etc/init.d/httpd restart
All the best.
In my case, I used lnmp to install php with version 5.4.45. But maybe because I installed php5-dev after lnmp (which I guess is not necessary if you installed lnmp), my phpize and php-config both point to older version tools than php.
I solved this by change the soft link of /etc/alternatives/phpize and /etc/alternatives/php-config to /usr/local/php/bin/phpize and /usr/local/php/bin/php-config.
Hopes this is helpful.
What worked for me was simply to do the following:
open the php.ini file.
Under the DYNAMIC EXTENSIONS heading, comment out the following line as
;extension=php_java.dll
Restarted Apache and all was fine