jk3us

WordPress has its own resizing mechanism, right? Even with non-title galleries, the thumbnails are generated directly within wordpress, why can’t this happen for tiled galleries?

Agreed, I’d rather it be just below the image or something instead of on top of it.

What would be really slick is if the plugin changed the url (either the hash or using pushState) so each image still has a unique URL that would take you to the gallery page with that image open.

I got it to work by changing the gallery options for that page to “Link thumbnails to: Image File” instead of “Attachment Page”. It would be best if it worked with both (that way if someone middle clicks a link, they get the attachment page in a new tab instead of just the image.

Same thing here, but on WP 3.3.2. If it helps, when I resize the window, my console says “galleria is undefined/galleria.resize();” on galleria-fs.js line 29. I don’t see errors before that, but it appears that it’s not getting initialized correctly.

According to liangzai’s comment, this would mess up a bunch of other things as well. I’m not going to try it until I hear success stories from others ?? I’ll just stick with the change in the code that fixes the problem for now.

since wordpress “uses prefixes in interesting ways” is it safe to simply rename all my tables with a prefix and set that in wp-config.php, or will those interesting ways cause problems with my new prefix?

@trypgirl, In another thread, one of the devs is saying that empty db prefixes aren’t supported. So, unless someone changes their mind, all of us that have used empty db prefixes without a problem until now may have to rename all of our wordpress db tables with a prefix.

yikes. That should be in the wp-config-sample.php file. It says “You can have multiple installations in one database if you give each a unique
prefix.” I assumed that since I didn’t intend to run multiple installations in the same database I could safely use an empty prefix.

It looks like a couple years ago some work was done to support empty prefixes, why was that dropped?

Edit: Also, I’ve been using the empty prefix for quite some time, and until now have never experienced a problem (that I’ve noticed).

Here is the change that introduced the problem. Before, they were effectively doing what I suggested above, checking the strlen of the prefix before trying that match.

I’ve left a comment on the ticket that seems to have introduced the problem.

You can either change line 699 as described here or just comment those lines out. I’m not sure what the side effects of either of those changes would be, but commenting them out seems to fix both of the problems linked to.

This seems to be somewhat related to this problem. If you comment out lines 699 and 700 of wp-includes/user.php (the same place that other problem occurs), you get all of your blogs back in that menu. I’m not sure what the rationale was for adding that, but it seems that little section needs some more attention ??

changing line 699 of that file from

if ( 0 !== strpos( $key, $wpdb->base_prefix ) )
       continue;

to

if ( strlen($wp->base_prefix) && 0 !== strpos( $key, $wpdb->base_prefix ) )
       continue;

makes the error go away, but I’m not sure if it changes the behavior of this section, since I’m not familiar enough with what this bit of code is doing. (I’m not sure if an empty prefix should trigger that continue or not.)

Edit: It seems like this portion of code is also causing this problem, if that helps in troubleshooting.

Also, in attachment.php, there are some broken things, like calls to printf() that don’t have a second parameter.