Hey guys, need a little feedback. When our users are on a non-domain mapped blog such as example.mydomain.com and they create pages or posts with images, those images are stored as example.mydomain.com/files/2009/08/image.png or similar.
The issue is that when the user maps the blog to their personal domain, the images no longer work. While domain mapping works and the user can use their personal domain that is mapped to us, It turns out that if I attempt to navigate to the original sub-domain URL such as example.mydomain.com, it does not resolve correctly to the mapped domain, I believe this is also the reason images are having issues as they aren't resolving correctly. When attempting to navigate to a domain such as example.mydomain.com that has been mapped to example.com, the url goes to:
Catchable fatal error: Object of class WP_Error could not be converted to string in /home/producti/public_html/wp-content/plugins/all-in-one-seo-pack/aioseop.class.php on line 285
Deleting All in One SEO, simply makes the error goes away and take the user to the registration page...
Hey guys, need a little feedback. When our users are on a non-domain mapped blog such as example.mydomain.com and they create pages or posts with images, those images are stored as example.mydomain.com/files/2009/08/image.png or similar.
The issue is that when the user maps the blog to their personal domain, the images no longer work. While domain mapping works and the user can use their personal domain that is mapped to us, It turns out that if I attempt to navigate to the original sub-domain URL such as example.mydomain.com, it does not resolve correctly to the mapped domain, I believe this is also the reason images are having issues as they aren't resolving correctly. When attempting to navigate to a domain such as example.mydomain.com that has been mapped to example.com, the url goes to:
Catchable fatal error: Object of class WP_Error could not be converted to string in /home/producti/public_html/wp-content/plugins/all-in-one-seo-pack/aioseop.class.php on line 285
Deleting All in One SEO, simply makes the error goes away and take the user to the registration page...
I'm thinking this might be a propagation issue, it's been 24 hours, but might want to just give it another 24 just to be safe... I'm seeing one that is resolving correctly....so that is telling me I'm jumping the gun.... let's give it a day and see if that makes a difference...
When comparing a working vs non-working blog, I went to the site admin > blogs > edit screen for each blog and looked at the very first field which is "Domain" .... the working blog had userdomain.mydomain.com and the non-working domain had the mapped domain (ie no sub-domain) such as userdomain.com in this field..... changing this to the original sub-domain blog url fixed the issue....
No clue how these changed.... maybe via the old domain mapping plugin? No clue.... will have to pay attention and make sure there's not something else I'm inadvertently doing to cause the domain name to change in edit screen.....
Just to be clear, the "Domain" field on edit screen should always have the original sub-domain.mydomain.com url in it, correct? What about for something similar like "File Upload", should these all be the original sub-domain url on the blog edit screen?
No clue how these changed.... maybe via the old domain mapping plugin?
That's possible. Note that our plugin only aims to be compatible with the domain mapping plugin Donncha coded. I'm afraid we can't offer compatibility with other domain mapping plugins.
Just to be clear, the "Domain" field on edit screen should always have the original sub-domain.mydomain.com url in it, correct? What about for something similar like "File Upload", should these all be the original sub-domain url on the blog edit screen?
Yes, everything in the blog edit screen and the blogs list should have the original domain (check siteurl, home, file_uploadurl).
The plugin should take care of changing the addresses that it needs to at the front end of the system. This makes it simple to remove the plugin by just deleting it and the system will resort back to it's original working state (but without the mapped domains). Changing those values makes un-installing the plugin a lot more difficult.
So, how can I stop this from happening. File uploads from within the sub blog goes to wrong place, and if I'm using the wpmu domain mapping, it goes to newsite1.com/files, but it's non existent.
A little more info... Oddly, the "mysite_com" is my db name. I copied the old db to a new db, and now that is what is showing up i.e. http://newsite1.mysite.comnew_db_name.
Network settings suggest:
wp-config
$base = 'new_db_name';
define( 'DOMAIN_CURRENT_SITE', 'www.mysite.com' );
define( 'PATH_CURRENT_SITE', 'new_db_name' );
--------------------------------------------------------------------------------------
And for htaccess, it suggests:
RewriteEngine On
RewriteBase new_db_name
RewriteRule ^index\.php$ - [L]
# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]
------------------------------------------------------------------------------------------
However, the above makes the site totally inaccessible. So, I am using:
wp-config:
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'www.mysite.com' );
define( 'PATH_CURRENT_SITE', '/' );
--------------------------------------------------------------------------------------------
And htaccess:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
</IfModule>
The end result is that the site is operational, but I have the subdomain naming problem, and files for subblogs wont upload correctly.
I've tried every possible combination for the wp_config and the tables, but no luck.
BTW, is wpmu. 3.1 , domain mapping, and has buddypress 1.8 on it.
Just frustrated at this point, so any ideas would be greatly appreciated. Thank you!
"$base = '/';" and "define( 'PATH_CURRENT_SITE', '/' );" is how it should be, unless you have very specific reasons for not doing that (such as a blog that's sourced at the root but visible under a child directory).
With these settings, is it a clean install, or did you preserve the database data? If you preserved the db data, then you may need to go thru and find/replace the "new_db_name" or "old_db_name" with the "/" to ensure that the URLs are valid. Otherwise, they were stored in the system incorrectly, and the only way around that will be a fresh db install.
thanks for everyone's help. I discovered some extra garbage in the wp-config that originally thought belonged there (new to wpmu). I had tried partially editing and it blew things so I gave up and went on to other things.
Eventually I went back to it and commented it all out, and voila. so again, thanks for your help!!!
Responses (16)
Erstwhile founder — 15th October 2009 #
Hiya,
This is with our Domain Mapping plugin correct? I believe you mentioned using another plugin earlier today.
Thanks,
Andrew
Member — 15th October 2009 #
You are very observant! I switched over to your plugin earlier today.....
Erstwhile founder — 15th October 2009 #
Can you provide us the subdomain url and mapped domain for one of the blogs?
Thanks,
Andrew
Member — 15th October 2009 #
Andrew,
I'm thinking this might be a propagation issue, it's been 24 hours, but might want to just give it another 24 just to be safe... I'm seeing one that is resolving correctly....so that is telling me I'm jumping the gun.... let's give it a day and see if that makes a difference...
T
Member — 15th October 2009 #
When comparing a working vs non-working blog, I went to the site admin > blogs > edit screen for each blog and looked at the very first field which is "Domain" .... the working blog had userdomain.mydomain.com and the non-working domain had the mapped domain (ie no sub-domain) such as userdomain.com in this field..... changing this to the original sub-domain blog url fixed the issue....
No clue how these changed.... maybe via the old domain mapping plugin? No clue.... will have to pay attention and make sure there's not something else I'm inadvertently doing to cause the domain name to change in edit screen.....
Just to be clear, the "Domain" field on edit screen should always have the original sub-domain.mydomain.com url in it, correct? What about for something similar like "File Upload", should these all be the original sub-domain url on the blog edit screen?
Erstwhile founder — 15th October 2009 #
Hiya,
That's possible. Note that our plugin only aims to be compatible with the domain mapping plugin Donncha coded. I'm afraid we can't offer compatibility with other domain mapping plugins.
Thanks,
Andrew
Developer — 15th October 2009 #
I've got a sneaky feeling it's the ahem "other" domain mapping plugin:
From: http://wpmututorials.com/simple-multi-site-plugin-e-book/
Erstwhile founder — 15th October 2009 #
Yeh, that would be the problem then.
Thanks,
Andrew
Developer — 15th October 2009 #
Yes, everything in the blog edit screen and the blogs list should have the original domain (check siteurl, home, file_uploadurl).
The plugin should take care of changing the addresses that it needs to at the front end of the system. This makes it simple to remove the plugin by just deleting it and the system will resort back to it's original working state (but without the mapped domains). Changing those values makes un-installing the plugin a lot more difficult.
Member — 25th February 2011 #
I am having a similar and confusing problem. Here's
what happens in "Site Info" when I create a sub blog on my site;
Main site: mysite.com
subblog: newsite1.mysite.com
Under site info, the new sub blog is created as:
domain; newsite1.mysite.com
Path; mysite_com/
As a result, the new sub blog address becomes:
http://newsite1.mysite.commysite_com/
I can correct the domain by clearing the "path" to
just the "/" and the domain will resolve correctly,
but then I end up with problems for the "uploads", etc. under "Site Options"
Those become the following:
Siteurl; http://newsite1.mysite.commysite_com/
Home; http://newsite1.mysite.commysite_com/
Upload Path; wp-content/blogs.dir/10/files
Fileupload Url; http://newsite1.mysite.commysite_com/files
So, how can I stop this from happening. File uploads from within the sub blog goes to wrong place, and if I'm using the wpmu domain mapping, it goes to newsite1.com/files, but it's non existent.
thank you for your help!
Sales & Support Lead — 26th February 2011 #
Hiya clickdaddy,
In the future, we'd recommend opening up a new thread for this. These older ones can get overlooked.
You'll want to check a few different areas for this.
Make sure you have this in your wp-config.php:
define( 'DOMAIN_CURRENT_SITE', 'mysite.com'; );
define( 'PATH_CURRENT_SITE', '/' );
Then open up your database and tell us what you have in your wp_site table
In the wp_options table, what values do you have for option names: home and siteurl
All of these should match up. You may need to add an additional '/' at the end of the values.
Let us know.
Member — 26th February 2011 #
Hi masonjames,
the wp-config is correct.
DB as follows:
wp_site: id; 1 Domain; http://www.mysite.com. path;/
wp_options: Siteurl; http://www.mysite.com home; http://www.mysite.com
I added trailing "/" to wp_options values, but to no avail. would this cause the problems with the "files"
directory structure also?
thanks, Barry
Member — 27th February 2011 #
A little more info... Oddly, the "mysite_com" is my db name. I copied the old db to a new db, and now that is what is showing up i.e. http://newsite1.mysite.comnew_db_name.
Network settings suggest:
wp-config
$base = 'new_db_name';
define( 'DOMAIN_CURRENT_SITE', 'www.mysite.com' );
define( 'PATH_CURRENT_SITE', 'new_db_name' );
--------------------------------------------------------------------------------------
And for htaccess, it suggests:
RewriteEngine On
RewriteBase new_db_name
RewriteRule ^index\.php$ - [L]
# uploaded files
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]
------------------------------------------------------------------------------------------
However, the above makes the site totally inaccessible. So, I am using:
wp-config:
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'www.mysite.com' );
define( 'PATH_CURRENT_SITE', '/' );
--------------------------------------------------------------------------------------------
And htaccess:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
</IfModule>
The end result is that the site is operational, but I have the subdomain naming problem, and files for subblogs wont upload correctly.
I've tried every possible combination for the wp_config and the tables, but no luck.
BTW, is wpmu. 3.1 , domain mapping, and has buddypress 1.8 on it.
Just frustrated at this point, so any ideas would be greatly appreciated. Thank you!
Member — 27th February 2011 #
"$base = '/';" and "define( 'PATH_CURRENT_SITE', '/' );" is how it should be, unless you have very specific reasons for not doing that (such as a blog that's sourced at the root but visible under a child directory).
With these settings, is it a clean install, or did you preserve the database data? If you preserved the db data, then you may need to go thru and find/replace the "new_db_name" or "old_db_name" with the "/" to ensure that the URLs are valid. Otherwise, they were stored in the system incorrectly, and the only way around that will be a fresh db install.
Member — 1st March 2011 #
thanks for everyone's help. I discovered some extra garbage in the wp-config that originally thought belonged there (new to wpmu). I had tried partially editing and it blew things so I gave up and went on to other things.
Eventually I went back to it and commented it all out, and voila. so again, thanks for your help!!!
Sales & Support Lead — 1st March 2011 #
Woo hoo! Glad to hear it. Thanks for letting us know :)
Become a member