Dragons Eye

Either the wp-config.php will exist in the same folder that WordPress was installed to, or it may be located one level above your install folder.

If you have access to the server backend by use of an FTP client (“File Transfer Protocol” client), once logged into your FTP session, you can navigate to find the wp-config.php – and then select to “edit” it as a text file downloaded to your local computer. Once you have added the two lines I mentioned, simply save it – and then upload it to replace the original file on the server.

The only other means I could help, is if you had access to any kind of database manager (like PHPMyAdmin, for example) on the server your website is hosted on. Then here is where you would find the entries for your site’s urls – and make the changes to the contents of those database fields.

If this is your website, or you have the authority or responsibility to access the “control panel” features of the server (IE: Being able to log into the server backend control panel), then here is where you will need to access the database manager, so that you can make the corrections in the database records.

Do you have the “wp-cli” package also installed and running on your “live server”?

It sounds like your live server is missing the package, as it needs to be installed separately (because it is not included within the standard WordPress releases).

That is a completely different software, not WordPress.

You need to seek technical support from XenForo Ltd, the publisher of your software platform.

– Jim

Very interesting.

I accessed your site at: https://www.katranci.org/wp-includes/wlwmanifest.xml
And got the expected XML page displayed. So, I did not see any access problems there.

Not sure I fully understood your question, but sounds to me that perhaps your best source of help is with the theme’s author (if this is not you, that is).

Wasn’t Yandex technical support or the FAQ’s any help either?

On another note:

If you are using another’s theme, beware that any coding changes or customizations to it are likely to get overwritten upon the next update.

– Jim

Do you still have access to the server backend from an FTP-client?

If so,

You can hard-code your domains within your “wp-config.php” file like in this tutorial:

Changing The Site URL

This should override whatever you have changed in the database, as the wp-config file’s constants are defined first, before any values are read from the database.

I generally prefer to hard-code my site’s domains within the wp-config file anyway, as this helps prevent just the sort of mishaps like you have described, AND this also provides a certain level of hacking protection as well as a bit of a loading speed improvement.

– Jim

Have you checked under the WordPress settings for permalinks?

Also,

Perhaps by creating a category called “galleries” so that you have those gallery-pages given to that category, and then ensuring that you have the “slug” for galleries being created?

https:// www .example. com/%category/? ? ?/

slug: galleries

– Jim

If you have a dedicated development system that is off-line,
( Especially if it is on something like XAMPP, WAMP, or similar )

This would be where you could test out perspective themes. I would suggest paying attention to themes that declare they are mobile-responsive (like a majority of the free WordPress-authored themes). You can fully test them out by resizing your browser window while you are displaying the pages.

If you wish to make minor modifications to any of the style sheets so as to fine-tune the appearance, of course you should create a “child theme” of the theme template you wish to use.

Personally,

I have had good luck with, and taught myself a lot about mobile-responsive design by using Twenty-Fourteen. So here may be a good start?

– Jim

Actually Milan,

It’s fairly easy to do. The other point you made about setting the CSP header in .htaccess or other server .conf files: It’s best to actually use WordPress’s “header” function to set the CSP header.

I have a functioning example of this AND the way to modify the HTML output BEFORE it is sent to the browser. It works like a charm!

I am currently using this code by “including” it within my theme’s “functions.php” file.

I would be more than happy to share the coding with you, if you wish to provide me some means of contact to get it to you? (I will probably need to write a few technical specs. to go with it, so that you understand how the code works.)

Once you understand the concept, applying it is very simple (along with a few REGEX’s like using “preg_replace()”, etc.)

BTW: My coding example also optimizes HTML pages, so that they load a little faster too!

Please let me know if you are interested in my solution.

– Jim

Hi, “kingmaico”.

Thanks for the reply, and thanks for the informative link. That info would be good for a future project of mine, but not quite for this case (yet). I may have to go and do some recoding and customization of the plug-in, myself. There are a few other things about it that I wish to change, like making it more user-friendly and customizable (as far as styling, etc.). The few fields I wanted to add were going to be droplists where the data would be fed from entries stored in the database, so as to be updateable and expandable (like certain user-desired choices, if they did not already appear in the list).

Again,

Thank you for the feedback. I will look a little more into the other option you suggested.

– Jim

Are these accompanied by E-NOTICE/E-WARNING ERRORS?

Okay. Thanks for that.

Well then,

His other problem may have to do with the numeric format, IE the “base notation”. A normal MD5 hash output is in base-16 (otherwise known has hexadecimal). The password fields in the database table for users are not in hexadecimal format. – This may be where his problem is.

I am unsure what base-numerics are used to encode the passwords, but I DO know they are not the hexadecimal notation that MD5 and other hashing-functions output.

If we are talking installing WordPress, WordPress does not install SQL, MySQL, MS SQL, or any database server because it was written to be installable on any server that has at least one of the supportable database servers already installed.

If you did not have any database servers or subsystems installed already, WordPress will not install, because it expects you to have already created the database and its user with password in order for WordPress to begin installation.

If you just have the basic WordPress package that comes in a “zip” or “tar.gz” file, all you need to do is extract the contents of the archive file into the folder you want to install WordPress (be sure to have the option “create sub-directories” enabled in your archive manager). The only thing: You need to create and edit the “wp-config.php” file before you being the installation.

https://codex.www.ads-software.com/Installing_WordPress

One of the best, short tutorials on installing WordPress!

He may need to set up an alias for his second install if he is wanting this second installation to be independent of the first one. That will need to be done by setting up an alias for that new folder in the httpd.conf file.

If one needs to run two or more different, independent installations of WordPress (rather than a “Multi-Site” install), one would need to create the other “virtual domains” through the use of the “alias” directive in the httpd.conf (Apache config file) for each instance.

For example:

your “DocumentRoot” may be set to something like:

/home/<user>/htdocs

Then, you have WordPress install 1 in a folder called: “WordPress_1”,
you would create an alias for it:

Alias /WordPress_1 “/home/<user>/htdocs/WordPress_1”

Then,

Alias /WordPress_2 “/home/<user>/htdocs/WordPress_2”

etc. . . .

Of course, each installation would have its own database and user pair.

Then,

To go to WordPress 1 -> https://localhost/WordPress_1
WordPress 2 -> https://localhost/WordPress_2

So, the answer would be with configuring the server system for more than one (virtual) domain, so that each installation can be treated separately in its own folder – on the same machine.

You could also do that with each having its own assigned localhost IP address too!

I am assuming you then re-installed and tested each plug-in, one-by-one afterward?

Also, if you were using BB Press too, I found that it is very important to install BuddyPress first, and THEN BB Press. I ran into a similar headache just a short bit ago.

The current value I have for this key is:

a:1:{s:13:”administrator”;s:1:”1″;}

So this is the correct value for this user’s privilege-level if he is an “administrator”, at least for a Multi-Site installation.

I believe the password field contains the MD5 hash of the login id AND the password together (no spaces in between). I know JOOMLA created password hashes this way as a means of making sure that the login ID and the password were correctly-matched.

So, maybe try hashing the login AND the password for the password field?