goborobo

its not even 99.99%.
Its 100%. That file is never wrong ??

My suggestion for revised wording:

“If you are certain that you have entered the username and password corrrectly, and are able to connect to the db by other means, check the db hostname.”

Your suggestion:

“Talk to your host to learn what the values need to be or stick to static HTML”.

“…or stick to static HTML” ? (Luser?)

its not even 99.99%.
Its 100%. That file is never wrong ??

The instructions did not explicitly suggest checking the localhost parameter.
And whooami’s statement (quoted) is incorrect.
The documentation would be improved with the removal of 99.9%.
But hey, you know better right?

Life is short. I generally accept statements like 99.9% as an indication that there would be little point in considering a probability of .01%.
However, may I suggest that the documentation might include a parenthetical adviso along the lines:
“If you are certain that you have entered the username and password corrrectly, and are able to connect to the db by other means, check the db hostname.”
But this is trivial and I’m not an argumentative person so in parting let me just say:
I love WordPress.
Thank you to everyone who has made it a reality.

And the answer is:

Not 100% of the time. My host requires:

localhost:/tmp/mysql5.sock

for MySQL5.

Always excellent support and great hosting: icdsoft.com

I thought I wrote the description of the problem clearly:

How could I have logged in by control panel and web page for two different users if I didn’t have the details right?

I’ve tried them both in the config file, and they both have superuser permissions.

OK, let’s be clear about this:
There is a clear problem with the WordPress install because:

1. I can login to the MySQL db as Master User from my host control panel.
2. I can login to the MySQL db from a web page as an authorized User.
3. The login line in PhpMyAdmin shows either user @localhost after I’ve logged in.

Putting either of these user settings into wp-config.php returns the error:

“This either means that the username and password information in your wp-config.php file is incorrect or we can’t contact the database server at localhost”

Permissions?

thanks.

Futher to this I post the following from my hosting support (ICDSoft.com – highly recommended)
Although phpBB is not installed on your site, there were many other users on the same server that were using phpBB, and once they got infected, the worm tried to overwrite all world-writable files on the same machine. This is why your pages have been defaced.
There are many script installations, which advise the users to set 777 permissions to some of the files. This is because SuExec is not a part of a standard web server and in most cases, all scripts on the server (no matter which user is their actual owner) are executed with the permissions of the web-server user. So, if these scripts need to write something to some file, they should that file will need world-writable permissions. This is not the case with our hosting environment – with us all scripts are executed with the specific permissions of their owner, so any files that need to be written to, can just have owner-writable permissions.
Currently, there is no way of telling whether you had files with world-writable permissions on your account. In order to prevent further defacements, we have set 775 permissions to all world-writable files when the worm hit us.
However, world-writable permissions on your files are the _only_ way that a script running as another user can damage your files. There is no hole in the SuExec wrapper that we use – we have carefully reviewed the worm’s code (it is coded in Perl), and we are quite familiar with its course of action and it signature.
You should not worry about your WordPress installation – there is actually no security hole in the urldecode() function, it is the specific way that its output was later used, that caused the vulnerability in phpBB. google-hilite.php is also not related to this.
Do we accept this as gospel? Is there some file in a default installation of WP that has permissions set to 777? Because I personally would never set permissions on a website to that.
In any event, it would appear that this attack come into my WP scripts via another user’s phpBB scripts.

This is not correct. The site I referred to (hammondgallery.com) is not using phpBB. It is using Gallery and WordPress. The WordPress wp-config.php file was overwritten by a version (8?) of the worm in question. The default file permissions were set to 664. I changed them to 644. There is no mention of setting file permissions in the installation documentation that I have read. Whether or not this is a security issue remains to be determined.
The vulnerability that was exploited by this version of the NeverEverNoSanity worm may in fact have something to do with the PHP function urldecode. If you read this bug report at phpBB.com (https://www.phpbb.com/phpBB/viewtopic.php?f=14&t=240513), you will note that the suggested fix removes the function in question.
Getting back to the WordPress files:
The script google-hilite.php (wp-content/plugins/) uses the urldecode function in fact, and as I am reading, the worm in question is using google to get at vulnerable sites.
I suggest getting in touch with photomatt on this one as he wrote the script.
In the meantime I suggest that anyone concerned about this does the following:
1. Back up your site IMMEDIATELY.
2. Set permissions on wp-config.php to 644.
It may be possible to set the wp-config.php permissions to be more restrictive, but I haven’t attempted this.

Afraid this worm may prove more extensive than just wordpress. There is an alert for this for phpBB as well.
My WP affected secion: https://www.hammondgallery.com/wordpress
Fortunately I backed the site up only yesterday. But I have another site using phpBB. Apparently I must now update to the latest versions of WP and phpBB on these sites and then hope the ISPs have got some other means of keeping this out.

I don’t think the problem is unique to the nightly upgrade. I had this problem when I installed WP about two weeks ago. I ignored it and the installation continued without any obvious problems.
In the first error you mention I notice that mySQL generates the error at ‘)’ – the end of the value list. It appears that there are 5 values for this table while only 4 are given. I don’t have the db structure up in front of me, but if the 4th or 5th field is set to NOT NULL, this might cause the error. You could try putting a 5th value into the statement.
In the second case, first check that the field names used in the upgrade-functions.php statement correspond to the fields in the corresponding table, and second that the values in the list conform to the specified datatype.

OK, maybe these are not contradictory statements but they have confused me so perhaps you can explain:
The first post in this thread states “It lets a blogger indefinitely leave a post on top of their WordPress blog”
The next post states: “a sticky will stick on top of a current day only.”
current day or indefinitely?

I could suggest removing the category in mySQL but then there is the question of the db table relationships. Which suggests a volunteer opportunity for creating an ER chart for WP. ??

There are two contradictory assertions at the beginning of this thread. Read about them in this thread .
Which statement is correct?

Thanks. I determined that just before I read your post and realized that I had not asked the right question:
How can I force a post to persist at the top of the listings without having to change the creation date? For example, if I create, say, a yearly schedule of events under an “Events” category. Is it possible to force that post always to appear as the first entry in that category. Can this be done by putting a category/subcategory link within a link tag?