James Collins

Hi,

Thanks for the suggestion.

I have recently been discussing this with Typekit’s support engineers, and they had this to say:

It is possible to load Typekit asynchronously, but doing so will create a notable flash of unstyled text in all browsers, which you won’t be able to control. For that reason, we usually don’t advise it.

I’m continuing discussions with them, and if we can come up with a workable solution I will be (most likely) adding it to the plugin.

James

The problem with that is that not all plugins (that create their own db table) will obey that DB_COLLATE define.

The best bet is to reinstall from scratch (including deleting your MySQL database). Then when creating a new MySQL database, set its default character set to UTF8 as well:

CREATE DATABASE dbname DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

That way any table created in that database should be created as UTF8.

Did you end up finding a way to do this?

I’d like to be able to do the same thing without having to create actual template files in my theme’s directory.

We are also seeing the same problem.

I followed these instructions: https://forums.ronaldheft.com/viewtopic.php?f=5&t=851

by adding the domain as an authenticate domain, but that didn’t seem to help at all.

Does anyone have a solution?

Thanks.

The contents of that wp_sitemeta record is a PHP array that has been serialized (https://php.net/manual/en/function.serialize.php) so that it can be stored in the database.

For example, if you have 3 usernames that are allowed to be site admins, this is stored in a PHP array with 3 elements, which is serialized before being stored in the database.

If you look at the source of the get_option() function (https://core.trac.www.ads-software.com/browser/trunk/wp-includes/functions.php#L274), you’ll see that you can use the pre_option_* filter to override/customise the value for an option.

For example, the following code will cause get_option('medium_size_w') to always return 222:

add_filter( 'pre_option_medium_size_w', 'my_override_medium_size_w' );
function my_override_medium_size_w($size) {
   return 222;
}

You can use similar code to override the other image sizes too.

If you put this in your theme’s functions.php file, you’ll be able to force specific image sizes for all sites that use that theme.

I suspect it wouldn’t work in mu-plugins, because the plugin needs to create at least one MySQL table during activation.

In plugins with network activation is the way to go.

As Andrea suggested, performance of this could potentially be an issue.

Perhaps you could store this array in a transient that expires every 24 hours or so? That would effectively mean that the loop and switch_to_blog() calls would only have to be called once per day.

Another option could be to hook into the save_post hook (https://codex.www.ads-software.com/Plugin_API/Action_Reference#Post.2C_Page.2C_Attachment.2C_and_Category_Actions), and construct/add to this array each time a post is published with the ‘_EventStartDate’ postmeta value. You would probably store the array in wp_sitemeta.

Yeh that’s how I would do it.

1. Get the list of blogs.
2. Loop over each blog, switch to it, get the post(s) from that blog. Add the post(s) to an array.
3. When finished looping over all blogs, sort the array however you like.
4. Then loop over the sorted array and echo your content.
5. Then restore to the original blog.

You’d be better off using these 2 functions:

https://codex.www.ads-software.com/WPMU_Functions/switch_to_blog
https://codex.www.ads-software.com/WPMU_Functions/restore_current_blog

We are also having issues with Shutter Reloaded and Google Chrome.

Clicking on an image makes the loading graphic display, but the large
image is never shown.

Sometimes this happens when clicking the first image, but normally it is the second or third image that “hangs”.

I’ve been able to reliably produce the error on Google Chrome for Windows v4.1.249.1059 (44723) and v4.1.249.1064 (45376).

Google Chrome for Mac (v5.0.342.9 beta) does not have this problem.

Does anyone have any idea how to fix this?

Thanks.

As per https://core.trac.www.ads-software.com/ticket/13090#comment:1, this sounds like a mod_security issue.

Ron, were you able to solve the problem?

@tiameg,

That problem also a symptom of AWeber updating their tracking code (and the plugin needing to be updated accordingly)

We do have plans to fix this problem in the next version of the plugin – I will update this thread once we have done so.

@gvwriter, AWeber has changed the formatting of the embed code, and they now display the JavaScript Snippet version by default.

You need to look at the “RAW HTML Version” rather than the “JavaScript Snippet”.

We have plans to improve the plugin so it supports the JavaScript snippet, but for now only the HTML version is supported.

You can do this by adjusting the AUTO_INCREMENT value on the wp_wpsc_purchase_logs MySQL table.

To do this, you need to run the following MySQL query against your WordPress database (via something like the MySQL command line or phpMyAdmin):

ALTER TABLE wp_wpsc_purchase_logs AUTO_INCREMENT = 8500