I'm going to research a little more but I think the per site visibility settings make no sense. I was not familiar with how multi-site worked but now that I created a multi-site drupal installation to test I saw that each site has its own administration so you would have to enable the module on each site and configure the pageears for each site independently. There is not a shared administration to manage pageears for all sites in one place so it seems the feature makes no sense.

Even in the case the same person is the admin of two sites in a multi-site installation he would have to go to pageear admin of both sites to manage the pageears for each of them.

It makes no hurt to keep that feature by now so it would be there until I have it clear but probably it would be dropped.

I would like your help to decide if this really makes no sense or otherwise and explanation on how it could make sense and how I could implement it.

Thanks in advance.

Comments

danreb’s picture

danreb commented

You can't control the settings in one configuration in a multi site drupal install because each instance of drupal site used their own unique database (one datanbase per site), unless you create or move the configuration settings outside a drupal database, (maybe this will work).

Great work manfer.

manfer’s picture

manfer commented

So I would have to provide users with the possibility to use some kind of multi-site configuration (some kind of configuration form with a checkbox "use pageears for multi-site", user, password and name of a database), move the pageears table to that database (if it does not exist yet)... And if they decide to deactivate it then move pageears configured for that site from the outer database table again to that site drupal database...

Or even the first with its pageears table in its drupal database and others sharing it, providing (user, pass and database).

Anyway it looks going too far: dealing with security implications of user and password (probably it couldnt be done with a form and that data shouldnt be saved on database, so users would have to do a file edition similar as on drupal instalation with settings.php), moving data from table to table...

I think it is better to drop that feature. Many many things to think about and code and I don't know if even anyone would benefit of that feature.

Thanks danreb to clarify.

manfer’s picture

manfer commented
Status: Active » Fixed

Dropped on dev version.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.