There are many reasons for this, so first check that MySQL/MariaDB is running properly, that you are using the correct credentials and that the the appropriate
user@localhost has access.
Also check you aren’t using
bind-address in your
my.cnf file if accessing from outside of the
localhost. These are things you will find with a google search.
Apart from this one other reason why
127.0.0.1 will work and
localhost will not work is if you are using something other than the default
socket=/var/lib/mysql/mysql.sock location in your my.cnf.
If that is the case, you’ll need to update the relevant
default_socket= parameter in
php.ini (for each driver) to match that socket – see the entries under
[mysqld] sections for the socket parameter. This is more likely to occur if you are using MariaDB for example.
Unfortunately you can’t do this the same way as an apache configtest, but there are a few sites out there to validate .htaccess files:
I use this one:
Just a good idea to check before deploying and nuking your site!
Here’s a pretty nice combination of parameters for command line grep using egrep (which supports regex):
egrep -rHnC1 "bprajb" .
This will search in the current directory recursively through all files that match the word “praj” (regex boundary b tags) and return the file name and context (1 line either side of the match) with line numbers.
For example here’s the resut with the matching word highlighted as well on the terminal.
You can add the following to your
.vimrc file to force the vim background to match the terminal background (e.g. black):
highlight Normal ctermbg=None
Here’s one method of comparing strings by case in MySQL. You can use the md5 function to hash the string and compare to its lower case value.
This example is for checking for usernames that are not lower case in moodle.
select username, md5(username), md5(lower(username)) from mdl_user where deleted = 0 and suspended = 0 and md5(username) != md5(lower(username));
If the md5 hash when the string is lower cased is different to the current md5 hash you will get a result.
If you find that your global $_SESSION variable is empty there can be several reasons, here are a few:
session.save_pathis invalid (does not exist) or is not writable.
session.cookie_secureis set to true but you not using a secure site (SSL/https).
session.cookie_domainis set to a domain that does not match your site – very common if setting up a dev or test environment from a production site with a public domain.
I’ve had this issue on OSX Mavericks and Yosemite on soapUI 5.x versions. Here’s a fix that disables the browser in soapUI which seems to cause it to hang.
/Applications/SoapUI-5.2.0.app/Contents/ (adjust to suit your version).
vmoptions.txt and add line:
/Applications/SoapUI-5.2.0.app/Contents/java/app/bin (adjust to suit your version)
soapUI.sh and uncomment line:
You can find the session.save_path through php info or using the command line:
php -i | grep save_path
Once you have that, you clear PHP sessions by going into that path and clearing out the relevation session files.