mfioretti

Hi @sasiddiqui : yes, the issue was due to SSL, and it may be partly due to misconfiguration of my own browser. However, the coordinator decided to change the requirement, so I have stopped using the plugin for that website. Will take it into account for future projects, thanks.

OK, now it is clear, thanks

Also, when you say “add this filter”, assuming it is a solution, WHERE, exactly, should it be added? In which PHP file??? Thanks

any news on this? I have a very similar problem, and am at my wits’ end…

Update: the problem appears only with https links. If we force navigation with http, things work

Hello @kerry7 ,

if “the only place you see Apache is on the panel of my server” it means you are using a hosting service, with such a configuration that the only way to solve your problem is to ask the support staff of that provider, not here. Sorry I cannot help more.

I confirm this solution works, because I have found what the problem was: the httpd package I have installed on CentOS does NOT have /var/www/html as DocumentRoot. So the settings suggested by @diondesigns WERE present, but applied to the wrong folder!

Add the following to your Apache configuration, just above the virtualhost section. Then reboot Apache and see if things are working properly.

<Directory “/var/www/html/wordpress”>
Require all granted
</Directory>

YES, this let me load the wp-admin/install.php, which in turn loads wp-admin/setup-config.php . THANKS. Seems ok. Right now I cannot proceed with the installation, but tomorrow will do it, and mark this as resolved if there are no other problems. Thanks again!

The path is correct. I know this because I see it in the server error log:

AH01630: client denied by server configuration: /var/www/html/wordpress/example/wp-admin/install.php

that is, /var/www/html/wordpress/example/wp-admin/install.php IS the correct absolute unix path to that file

Also, I have run these commands (on centos, “apache” is the httpd user) from the wordpress root folder and restarted the server, but nothing changes:

chown -R apache:apache .
find . -type f -print0|xargs -0 chmod 644
find . -type d -print0|xargs -0 chmod 755

also, in case it matters, selinux is set to permissive.

This page, as I understand it:

https://wordpress.stackexchange.com/questions/67840/where-does-the-media-library-live-in-the-database

seems to confirm what I wrote before. If wp shows in media library what is written in wp_posts and wp_postmeta, it seems certain that if you upload an image in blog 1 (=write its path, data etc) in the wp_posts, wp_postmeta tables of database 1, when you open the media library of blog 2 it won’t display those images. Unless its own tables too have been somehow updated… Seems a job for wp-cli, if it is possible…

“it is logical to believe both sites would first need to have identical settings related to thumbnails and cropping”

Yes! I had forgotten this detail, but yes, all sites would certainly have identical values for such settings, this is not a problem at all (not for me at least). Wrt this:

do not know how WordPress would act during the registration process instigated by ‘Add From Server’ if the upload being registered already had its corresponding thumbnails in place… there is no reason to believe a previous registration in a different database would be corrupted.

I have two comments:

1. The “Add from Server” plugin carries a big “not updated in 2 years, may no longer be supported” notice, so I’ll try that as very last chance..
2. After thinking a bit about what you said, **I** expect/imagine that, if there is some problem in a scenario like mine (=each wp install has its own separate database) is not due to “database registration” itself (When php code of blog 1 writes anything to database 1, it has no idea at all of the existence of database 2, and no way to interact with it), nor to file permission issues (it’s always the same user, the http server, that accesses the UPLOAD folder) but at one of these things:

1. outside all the wordpress blogs, that is http-level caching behaving strangely, or inefficiently, if it has to cache two urls which are actually the same file
2. wp code that creates thumbnails crashes/misbehave if they already exist
3. wp code of the media library crashes/misbehave when you open the media library, and there are files on disk, never registered in its own database (because uploaded the first time, by another blog, that is registered in another database)

So, at the moment I expect that if there is any problem is in case 2.3 above, that is NOT seeing in media library of blog 1 stuff that is not registered/listed in its corresponding database. And going with “Add from server” doesn’t seem a future-proof thing to try, not first at least. Must have a look at the media library code and db structures, like the get_media_item functions, I guess?

(of course, I will just go ahead, set up everything, see what happens and report, at some point. But I need a couple of free days for this and related stuff, which won’t happen until I release other things. So now I can just prepare myself, asking and studying, 5 minutes at a time)

Yes, I agree. In MY own case I am oriented towards independent blogs instead of multisite install because, short version, unless there ACTUALLY IS some performance penalty, I prefer it. Longer version:

1. I will do this on a VPS of which I am root, so I can customize it any way it is needed/I prefer
2. so far, nobody (even in other places) has told me that using seven different wordpress installs each with its database, wrt 1 multisite+1db, the seven websites would be slower for users (also because, due to #1 I will be able to manage/consolidate caching, page compression and similar at the httpd server level, ie use less plugins in wordpress
3. this is only my own (strong) feeling, but here it goes: wordpress plugin and themes are, in general, tested more in single installs than in multisite ones, so it is less likely to happen into bugs/untested situations if you stick to single installs
4. Robustness: due to #1 again, I can do manual updates, i.e. check if something goes wrong, only on one blog and then: if it’s OK, I do the same thing on all the others with wp-cli, automatically; if it goes bad, I only have one broken blog to fix

Does it make sense? If I overlooked something, please let me know

FIY:

interesting info, related to a part of this problem, is now coming into this other thread:

https://www.ads-software.com/support/topic/one-vps-seven-blogs-what-is-better-one-or-many-mysql-databases?replies=6#post-7070816

OK, to sum it up, we have 3 combinations (because number 4 is NOT possible, is it?):

1. 7 wp installs, 7 databases
2. 7 wp installs, 1 database
3. 1 multisite, 1 database
4. 1 multisite, 7 databases

and:

1. silkalns reports no performance difference between #1 and #3
2. leejosepho reports no problem with #2</>

Is that correct?

Thanks

By the way, let me elaborate on my original question:

I am wondering how much the difference in performance will be, of having 7 databases instead of one with seven sets of wp tables. Thoughts, optimization tips?

One can have one single database with seven sets of wp tables in two ways: first is going multisite, second is using seven different worpdress installs, ALL pointing to the same database, but each using a different table prefix.

Silkalns’ answer refers to the first case only, doesn’t it? I mean, maybe the answer is the same EVEN in the second case, but not necessarily. Or not?