Toni Ginard

Hi DarthTater,

No, it has no added functionality. It is exactly the same code as the jetpack version with a wrapper to enable it to work outside the jetpack.

Best wishes,

Toni Ginard

Hi Garrett,

Sorry for the very late reply. Do you still need the changes you requested? You can see the changes we made in our repository, where we have a modified version of the original:

https://github.com/projectestac/wordpress-google-analyticator/commits/master

Best wishes,

Toni Ginard

Hi Javier,

We have prepared a modified version of release 1.9.8.1 with support for localization. You’ll find a .pot file which can be easily updated from source code using poedit. You only need to update it every time a new version is released.

We have “gettexted” all the user messages we found in the code. It would be a good idea that you check that all messages appear when they are supposed to, because we’re not familiar with many of the features of the plugin and we could’nt test them properly.

Download link

Best wishes,

Toni Ginard

Hi Pierre,

Yes, you’re right: In the information schema there are references to all the tables in the server and it is a problem in some cases.

I had a look at it and I think we can take advantage of the fact that the latest blog accessed before the copy is the original blog, so we can get the data base this way:

$schema = $wpdb->last_used_server[‘name’];

So you can change this line:

$sql_query = $wpdb->prepare(‘SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE \’%s\”, $like . ‘%’);

by this two:

$schema = $wpdb->last_used_server[‘name’];
$sql_query = $wpdb->prepare(‘SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE \’%s\’ AND TABLE_SCHEMA = \’%s\”, $like . ‘%’, $schema);

A consequence of that is that you can remove the lines 63 and 64, because we already know the data base:

// $sql_query = $wpdb->prepare(‘SELECT TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = \’%s\”, $table);
// $schema = MUCD_Data::do_sql_query($sql_query, ‘var’);

Those changes worked for me in my development environment, using HyperDB, but the code should be tested without HyperDB. Anyway, it should work because it doesn’t rely on HyperDB but in WordPress itself.

All the best,

Toni

Hi Pierre,

Sorry for the late response. I really don’t have time to work on this…

I tried to understand how does HyperDB works, but I was unsuccessful. I even tried to examine the binary log of MySQL to reproduce the steps that it does, but I suppose that not everything is logged.

HyperDB introduces a transparent layer in WordPress that “magically” connects to the correct database when someone accesses a blog. Of course it’s not magic, but that’s the point: find out the algorism in the HyperDB code, which is not so simple as it may appear. I couldn’t find it. ??

One possible approach is as described above: do the same that HyperDB does. But another possibility to explore is allow HyperDB to do the work:

HyperDB defines a class called hyperdb that extends wpdb. After that, instead of using the original wpdb, it creates an instance of the extended class, with the same name, that replaces the original. From that moment on, WordPress works with wpdb as usual and everything is fine.

So, the second approach could be to behave as WordPress and let HyperDB connect to the correct server and database. I must say that I don’t know how to do it. I’m even not sure that it is possible! ??

Best wishes,

Toni

Hi Pierre,

Two thoughts about HyperDB:

HyperDB supports using several database servers. This patch doesn’t address that. To add support for that case would require a lot of changes and, as long as I don’t need it, I haven’t worked on it.

So this patch adds partial support for HyperDB: when there are several databases in the same database server.

Best wishes,

Toni