markp

Thanks. That’s great. ??

Thanks.

OK. I’ve found the actual cause of the problem.

In the file domain_mapping.php
/wp-content/plugins/wordpress-mu-domain-mapping/domain_mapping.php
on line 192 the code is:
$rows = $wpdb->get_results( “SELECT * FROM {$wpdb->dmtable} ORDER BY id DESC LIMIT 0,20” );

This is the line that retrieves just the 20 rows max that the settings page displays.

Changing that ’20’ near the end of that line to ‘200’ means that it will show up to 200 mappings on the settings page. Or just set it to something really high, or even try out removing
LIMIT 0,20
altogether (which works fine for me).
Which gives you a line 192 of:
$rows = $wpdb->get_results( “SELECT * FROM {$wpdb->dmtable} ORDER BY id DESC” );

This doesn’t fix the domain search problem (it simply doesn’t work), but as long as you have the full list you can use your web browser’s ‘find text in page’ function to find the site you are interested in.

Of course, your fix may get overwritten should this plugin get updated.

Cheers,

Mark

Of course, if you have thousands of mappings and very low memory limits in php or mysql then you may crash the page.
Cheers,
Mark

The workaround is to look at the relevant database table itself, for example in phpMyAdmin. The table name is
wp_domain_mapping
where ‘wp_’ is your specific table prefix for your WordPress network installation. As such, in an alphanumerically sorted list of tables, it comes somehwere after each of the wp_nn_tablename tables (where ‘nn’ is each separate website’s number).
Mark

I have exactly the same problem.

Plus the search function above the list doesn’t work, so I can’t try to find what records there might be that don’t appear on the list.
Cheers,
Mark

I note that this is the same complaint as another thread
https://www.ads-software.com/support/topic/resize-of-images-does-not-work-as-expected?replies=3

Same here: NextGen Gallery 1.9.13 on WordPress 3.5.1 Network with a perfect ‘plugin check’ result on the gallery management homepage within WordPress admin.

The resized (to 800 x 600 images appear to be jpegs at 100% quality rather than the specified 85%).

This is a new install of NextGen Gallery as of yesterday.

Same here: NextGen Gallery 1.9.13 on WordPress 3.5.1 Network with a perfect ‘plugin check’ result on the gallery management homepage within WordPress admin.

The resized (to 800 x 600 images appear to be jpegs at 100% quality rather than the specified 85%).

This is a new install of NextGen Gallery as of yesterday.

I don’t have a problem seeing the images on the site. The only problem I have is that the path in the ‘Link URL’ field in the ‘Add Media’ screen is the long path that includes blogs.dir. It should be the short path. See my first post.

I can’t see how the domain is going to affect whether we have blogs.dir in the uploaded files path.

When I create a new site it always creates it in the form
sitedomain.networkdomain.tld
I can’t stop it from appending networkdomain.tld
so I immediately correct it to
sitedomain.tld

for ‘Fileupload Url’ I have:
https://sitedomain.networkdomain.tld/files
which is the original subdomain that, when you set up a new site, it gets set to and then I change the ‘Domain’ (with ‘Update siteurl and home as well’ checked) immediately after to ‘sitedomain.tld’, under the ‘info’ tab of the same page.

FYI
I have no value against ‘Upload Url Path’.
‘Upload Path’ is ‘wp-content/blogs.dir/33/files’.

I haven’t kept any debug edits in the core files – it is all straight up original WP.

Actually I’m not sure which line of this code
the function
wp_get_attachment_url
in the file
/wp-includes/post.php
is giving me the wrong url.
$url = $uploads[‘baseurl’] . “/$file”;
or
$url = apply_filters( ‘wp_get_attachment_url’, $url, $post->ID );

The first gives me the longhand URL, but is the second line supposed to change it to the short URL?

OK. The function
wp_get_attachment_url
in the file
/wp-includes/post.php
is returning a value of
https://domain.tld/wp-content/blogs.dir/33/files/2012/11/file.jpg
instead of
https://domain.tld/files/2012/11/file.jpg

when I manually override (by a quick hack) the value that is passed back from this function then that is the value I see in the ‘Link URL’ field.

Doing some further debugging in that function I find that it is the value of
$uploads[‘baseurl’]
that is incorrect and that
$uploads = wp_upload_dir()
I look at this function shortly and see where it is getting it’s values.

I’m afraid I don’t exactly know when it started. I would estimate that it was early 2012 – but I wouldn’t like to guarantee it.

I think that I need to trace where this pre-defined path is coming from in the system.

Thanks Ipstenu. That’s good news on the one hand, but bad news in that it looks like nothing is going to be done.
Cheers,
Mark

Peter, you are a star! Thanks. I’ll get the updated plugin when it becomes available (although I feel quite comfortable that my server meets the new minimum requirements anyway!).