Generating prefixed tables for existing domains

Not at the moment.

You need a feature that knows when new tables have been added to the master database and allows those tables to be replicated across existing domains.

That's quite a sophisticated trick. We'll file this as a feature request, but I don't see it getting in soon.

Ah -- I thought you were asking something else.

It would be a nice feature to have a screen that allowed for batch updates across all domains, however. So I'm going to add this to the "postponed" feature request list.

Right. I just added (in beta1.1) support for batch updates of configuration settings, and it is very handy.

Would be a nice to have feature here as well.

Hi Ken -

The request you thought mr2400 was initially making is definitely something that I'm going to be needing (or at least, desperately wanting) in a project that I'm currently working on. While I wouldn't be comfortable putting a specific timeline on it, I will say that there's a likelihood that I might take a crack at rolling a patch that allows for just these sorts of batch updates.

I'll drop any ideas/patches I might have into this issue as I come up with them.

Tremendous work with this suite of modules, by the way!

cheers

sam

sam-

I'd love to see a patch for this. I just released 5.x.1.1 and have started porting that to Drupal 6.

If I develop this feature, it would be for Drupal 6, then possibly backported.

I had the same question as mr2400 - I didn't know you had to manually tell it to prefix existing domains (via the domain list's tables link), so I thought it wasn't working. Perhaps this could be added to the README file (or emphasised, if it is already mentioned, as I couldn't find it).

Documentation patches are always welcome.

One place where use case documentation will save some pain: Prefixed menu tables and create/copy.

I created several sites with prefixed menu tables so that every site can have completely different menues. I set the tables to create, not copy, so that nothing would go from the source site to new sites. I could not administer new sites because they did not have administration menues.

On the second time around I created the source site with just the default Drupal installation menues, Domain Access, and a few other common modules. I then made the menu tables copy. I could administer the new sites because they copied all the administration menues.

This is a use case for separate menues. It should give people an idea of the difference between create and copy. I suspect that create is useless for menues and everyone will use copy when they know the impact of not having administration menues. One problem will be when people start changing the menues on the source site. New sites will inherit the changes.

I guess the next part of the use case is to suggest the source site should only change when the changes are needed by absolutely every new site and that you will need a way to propagate universal menu changes to existing sites where the menu tables are already copied. For menues, an update from the source to the other sites would have to copy the new entries from the source site without destroying new entries on the other sites. If the source has new entry A and the target has new entry B, add A and leave B. If both have new entry B, do you replace or preserve?

I can't really provide that level of documentation.

Table prefixing in general is a very advanced Drupal topic, and prefixing menus is a huge can of worms. Open at your own risk.

There are several tables that, if prefixed, could generally kill your site. Notably:

- session
- cache (if not done carefully)
- system
- node (you clone this and you break node access)
- node_access (would be a nightmare)
- menu_* (some of these are safe, others are not)

I deliberately opted not to bar the copying of these tables -- notice that you cannot clone the Domain Access tables at all. The price of this level of flexibility is the caveat that you _really_ need to know what the tables do before you clone them.

I would, by default, always start with 'copy.'

Hello folks,

I run into the problem that agentrickard (#1 above) and sdboyer (#6 above) mentioned and I have a suggestion for a patch.

In my case, CCK fields were added to content types, and the relevant tables were not created for existing domains, nor was the admin able to create the relevant tables by going to the table prefix page for the existing domains. I can't say that this is a good patch, I didn't read through the whole Domain project code.

I noticed that in domain_prefix.admin.inc, in the function domain_prefix_form the modules gets all the database tables and stores them in the $default variable, but then it only uses the $table_options that were last saved to list the tables for that domain. Thus, any new tables since the last save are not listed. I added a few lines of code to do a reverse lookup as well, that is to go through the $default tables and check if they are not in the $table_options array (and set them to a default ignore if they are not).

This worked in my case. Can you please review the patch and check if it's good enough to address the issue? If not, please let me know where I should be looking to cover all bases.

Cheers.

Makes senses. Needs testing.

@gsbc

The patch itself is good, and the reverse lookup is also working perfect. I did test it on different sites and with different combo of number of domains and active tables on the default domain, where as they where not loaded by already existing domains.

Altho a very short number of lines, thumbs up for this patch.
Perhaps you want others to test again before committing it to the dev version, but as far as I can see its good.

Thanks for the review! I will try to give it a test this week.

@nonsie, if you pick this up, feel free to commit if you can confirm it works.

Committed to HEAD with a few comment cleanups. Needs a backport.

Nice work!

Was that used in the last module release (6.x-2.5 )?
Because it seems it was not, and i was looking exactly for that feature to plan using the prefixes.
You said you committed in HEAD, so at least will i find it there?
thank you,
Da.

This has been in since 6.x.2.0-rc9. See the CHANGELOG.

Domain Prefix was been removed from HEAD, which is now Drupal 7. It has its own project and, frankly, needs a maintainer to patch for D7.

The (to be ported) here refers to a D5 backport, which isn't likely to happen.

K thanks,
i must investigate the reason why it isn't working for me with the 6.x-2-5, then.

Just to update this silly trouble.
All was working since the first time, the problem wasn't domain_prefix but me.
I didn't notice there were forms for the single domains to work on.

Since i figured this out reading another issue where the submitter was in trouble like me i guess it could be better explained in the README file.

Anyway, sorry for bothering you
Da.

D5 is dead.