Trying to initiate local Wordpress i got the message :
Votre serveur utilise la version 5.6.18 de PHP mais WordPress 5.2 nécessite au moins la version 5.6.20.
How can I solve the problem
Thanks and Regards
After a few failures I finally managed to make php-7.4.24 and php-8.0.10 run - and it's very easy!
Go to the PHP Windows Download Page.
Get the x86 Thread Safe version(s)
UnZIP to a (in my case) php-7.4.23 and php-8.0.10 folder
Add this lines to httpd_uwamp.conf around line 166:
Define {PHPMODULENAME} {PHPMODULENAME}
<IfDefine php8_module>
LoadModule php_module "{PHPPATH}/{PHPAPACHE2FILE}"
</IfDefine>
<IfDefine php7_module>
LoadModule {PHPMODULENAME} "{PHPPATH}/{PHPAPACHE2FILE}"
</IfDefine>
<IfDefine php5_module>
LoadModule {PHPMODULENAME} "{PHPPATH}/{PHPAPACHE2FILE}"
</IfDefine>
Start UwAmp.
It will find the new php versions and ask if you want to install, say yes, and choose the production ini
Code sample is from this link
You can update PHP version within the control panel of uWamp.
also you can install manually any version that you want and uWamp will recognize.
uWamp screenshot
As a note, you might simply copy over an existing php_uwamp.ini file into the new PHP folder to retain the customizations you have. Please bear in mind that when switching to a new MAJOR version (v7 to v8) the .ini may have changed.
After manually upgrading php to version 7.4.9 in uWamp there is a warning in phpMyAdmin. This is caused by a too old version of phpMyAdmin in uWamp. After upgrading phpMyAdmin to version 4.9.5 the warnig in phpAdmin has been gone.
Related
I moved from using Docksal to Acquia ADS (Lando) which automatically upgraded my Drush from 8 to 9. My local site works fine but I can't get Drush 9 to "see" my Drupal 8 site. The aliases seem to have been created and added to the drush/sites folder and running drush site:alias does show them. However running drush status shows my Drupal root as /app. My Drupal root is /app/docroot. My alias files do have this as their root (for local). I'm not sure why Drush doesn't use the alias files it knows about. I've tried:
drush #self(or #local) list and I get some commands and this statement at the end:
[NOTE] Drupal root not found. Pass --root or a #siteAlias in order to see Drupal-specific commands.
Doing drush #local(or #self) cr returns:
In BootstrapHook.php line 32: Bootstrap failed. Run your command
with -vvv for more information.
With -vvv:
Exception trace: at
/app/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:34
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook()
at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:27
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize()
at
/app/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at
/app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:289
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at
/app/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at
/app/vendor/symfony/console/Application.php:1005
Symfony\Component\Console\Application->doRunCommand() at
/app/vendor/symfony/console/Application.php:255
Symfony\Component\Console\Application->doRun() at
/app/vendor/symfony/console/Application.php:148
Symfony\Component\Console\Application->run() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:118
Drush\Runtime\Runtime->doRun() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:49
Drush\Runtime\Runtime->run() at /app/vendor/drush/drush/drush.php:72
require() at /app/vendor/drush/drush/drush:4
drush status:
PHP binary : /usr/local/bin/php
PHP config :
PHP OS : Linux
Drush script : /app/vendor/drush/drush/drush
Drush version : 10.2.2 <-- Had 9.0.0 but currently trying 10, same issue
Drush temp : /tmp
Drush configs : /root/.drush/drush.yml
/app/vendor/drush/drush/drush.yml
/app/drush/drush.yml
Drupal root : /app
self.site.yml:
local:
root: /app/docroot
uri: example.lndo.site
Can someone please point me in the right direction?
Figured it out. No matter how many ways you try to tell Drush where to look to find your Drupal root, none of it will matter until you edit your composer.json file. Turns out the key to making Drush 9+ work is changing the name in composer.
My composer.json file name went from:
"name": "drupal/drupal",
to:
"name": "drupal-composer/drupal-project",
I don't think this feature was documented anywhere so I'm posting it here in response to my own question in case this helps anyone else.
I realize that this is an older question, however with Drupal 8 recently reaching end of life, and the high probability of many people (like myself) scrambling to upgrade now that clients have realized the risks of using EOL software, I want to take a moment to explain why #r00t's answer works.
r00t is correct that changing the "name" value in composer.json fixed the issue, however, the value that is set is not limited to drupal-composer/drupal-project. This seems to stem from the package webflo/drupal-finder and the way it works.
webflow/drupal-finder is a requirement of drush/drush, so it's going to be included even if you haven't added it manually. It's also a requirement of a couple of others that you may or may not have installed, like palantirnet/drupal-rector (which as a side note, is really helpful for this upgrade).
Within the code for drupal-finder is a method that looks for the install path of Drupal core based on a few items within your composer.json file.
Here is the code from DrupalFinder::isValidRoot()
foreach ($json['extra']['installer-paths'] as $install_path => $items) {
if (in_array('type:drupal-core', $items) ||
in_array('drupal/core', $items) ||
in_array('drupal/drupal', $items)) {
$this->composerRoot = $path;
// #todo: Remove this magic and detect the major version instead.
if (($install_path == 'core') || ((isset($json['name'])) && ($json['name'] == 'drupal/drupal'))) {
$install_path = '';
} elseif (substr($install_path, -5) == '/core') {
$install_path = substr($install_path, 0, -5);
}
....
Which is telling drupal-finder that if the "name" value is drupal/drupal then the install path of the site is at the base of the project, however if it is not drupal/drupal then use a value from extra.installer-paths to find the site install.
I'm still not aware if this is documented anywhere on either webflo/drupal-finder or in drush/drush, but understanding why it was an issue helped me out tremendously.
TL;DR:
If your site's docroot lives next to your vendor folder, change the name in composer.json to anything that isn't drupal/drupal. If your vendor folder lives inside your docroot, drupal/drupal will work for you.
It's the first time I work with Symfony and Oracle, I have a problem to connect a Oracle11g database to WAMP, I have tried a lot of tutorials but no one work.
I have enabled the php_pdo_oci extension in WAMP. I have downloaded the Oracle client 32bit: Version 11.2.0.4.0, put the files in c:\instantclient_11_2 and add it to PATH.
I have configured parameters.yml and config.yml but when I try to do a request I get the error:
"CRITICAL - Uncaught PHP Exception Doctrine\DBAL\Exception\DriverException: "An exception occured in driver: could not find driver" at ...\vendor\doctrine\dbal\lib\Doctrine\DBAL\Driver\AbstractOracleDriver.php line 76"
I'm on Windows 7 Pro 64, WAMP 32.
Try to install pdo_oci8 driver and configure your paramaters.yml like this :
parameters:
database_driver: oci8
database_host: hostname
database_port: '1521'
database_name: dbname
database_user: username
Steps to install php_oci8_11g.dll
First, i have moved to a 64bit version of WAMP.
-Download the "Instant Client Package - Basic" for Windows.Choose your version(64 bit) for me.
-Unzip it to c:\instantclient_11_2
-Edit the PATH environment setting and add c:\instant_11_2 before any other Oracle directories (to be sure put it on the begin of the variable)
-Restart your computer for environment variables to effect
-Now go to your php.ini file and add/uncomment the line
extension=php_oci8_11g.dll
-Save php.ini file
-Download the actual Thread Safe OCI-DLLs from pecl.php.net choose your version (I'm using PHP 5.6 so i get the 2.0.12)
-Unzip OCI-DLLs Zip file and copy all files from this folder to Extensions directory of PHP (php/ext)
-Restart WAMP
After installing Yosemite and a new version of MAMP
and when I'm trying to execute
domain/app_dev.php/es/venues/3/show
This route is rendering a form containing a language type field, so it's requiring ICU.
being 'es' the locale i get errors. If I changed it to 'en' there's no problem.
The errors are:
[1/2] ResourceBundleNotFoundException: The resource bundle
"/Users/a77/Documents/DEV/UVox
Com/vendor/symfony/icu/Symfony/Component/Icu/Resources/data/lang/root.php"
does not exist.
[2/2] Couldn't read the indices [Languages] from
"/Users/a77/Documents/DEV/UVox
Com/vendor/symfony/icu/Symfony/Component/Icu/Resources/data/lang/es.res".
The indices also couldn't be found in the fallback locale(s)
"root.res".
My symfony version is 2.5, I'm running the MAMP PHP 5.5.10.
I updated dependencies via composer, including "symfony/intl": "*",
I have followed several webs in order to install icu and intl via pecl. But still get the error. I don't know how to check if the installations or the configs are ok. Maybe you can let me know how to test both via terminal and let you know what is the result...
This is because you are trying to get resources only for language es. But now (from the moment of importing to Symfony icu data) you need to get language resources via language and country codes es_ES.
You may not be able to just simply activate intl.so after the Yosemite update. I solved the issue installing intl.so following an excellent article by Danilo Braband http://dab.io/posts/getting-started-with-symfony-on-yosemite.html
Solved updgrading to Symfony 2.5.6
I have problem with my server configuration. I use Apache 2.216, PHP 5.3.3 and wordpress 3.4.2 with Shopperpress. Time to time I receive error "client denied by server configuration: path/to/file" in apache log file. It is path to _tbs.php file, but it is not problem in rights of file, because this file is called 12 times on page for getting thumbs of photos and there is error only several times. I think that it has no connection to concrete photo, because once this photo is displayed corectly and next time same photo produce error.
Do you have any idea what can be reason?
Thank you for all advices.
Viktor
I think thats a problem by the configuration of MaxClients or MaxRequestsPerChild.
Try to restore the default configuration and try it again. If that not works, reinstall Apache and purge the old configuration.
You have given very little information. It is not clear under what conditions do you work (OS, installed modules, Log entrys,...).
WordPress 3.4.2 is very old and safety-relevant. Please update WordPress and your WP-Plugins.
Go to you VHOST-file and replace:
Deny from all
Allow from 127.0.0.0/255.0.0.0
with:
Require all granted
This cause for old Config-Files and newer Apache-Version. Since Apache 2.4.3 a new security feature is added.
I've troubles with Drupal 6 and (maybe) mod_rewrite:
if I go to http://127.0.0.1/drupal/node/115/edit?destination=admin%2Fcontent%2Fnode and then I save the node, I don't get redirected to admin/content/node, but it directs me to node/115 :-(
Why??
In my .htaccess I uncommented: RewriteBase /drupal (because my drupal path is /var/www/htdocs/drupal)
My server is running Apache 2.2.4 on Slackware 12
Any help I'll be appreciated :D
It does look like a configuration problem, because this normally works. You can debug it by adding some dsm() dumps in includes/common.inc/drupal_goto() : this is where the destination parameter is processed.
Note that if some module traps your form submission, for instance by declaring a _validate or _submit handler, it can very well change the redirection information: check whether you can reproduce this without contrib modules enabled.