donuthole

After you made the changes, did you refresh your permalinks by going to Settings->Permalinks and then clicking “Save Changes”? This will flush the old rewrite rules and update the permalink structure.

If it’s happening automatically, odds are that the other blog is automatically pulling your content from your RSS, and probably doing so on an automated schedule (looking for content every hour or so).

You can block that site by using htaccess to deny the IP address of the other site. You can also contact his host (in this case, WordPress.com) and make a complaint that this person is violating your copyright. Most hosts will not allow this and would take down the site.

If this code is in the WordPress loop, change the href code from "getyourgadgetsgoing.com" to "<?php the_permalink();?>" and it will put the link to the post instead.

Or the limit set in multisite is at 10MB and WordPress blocked it. You can change that in the network admin area.

Or the limit set in multisite is at 10MB and WordPress blocked it. You can change that in the network admin area.

You are displaying the raw, unformatted data from the database. To add the paragraph and other tags, you can call:

echo apply_filters('the_content',$part[0]);

echo apply_filters('the_content',$part[1]);

I ran into the same problem and thought I’d post the solution (for me at least).

I moved a bunch of individual WP sites to a network configuration and thought I had updated all of the databases to properly reflect the new configuration. On one site inside the network, I couldn’t select a user role when adding a user (same as the original poster here).

NOTE: Where ## is written, enter the blogid in question. In my case, it was blogid 22 so I would use wp_22_user_roles.

As it turns out, in wp_##_options, I hadn’t updated the option_name wp_user_roles to wp_##_user_roles so WP assumed that no roles were available for new users.

Changing the option_name value from wp_user_roles to wp_##_user_roles fixed it!

I got it all figured out. Thanks all!

I dove into PHPMyAdmin for this. As it turns out, the only references to the “main” domain name are in a few original tables. In my case, I use domain mapping with the sites as subdomains (wildcard setup) so none of my sites actually operate at site.maindomain.com — they all redirect to https://www.site.com.

In my case, I was transferring from “main” site https://www.mydomain.com to https://www.mydomainhosting.com and am using wp_ as the table prefix. I only had to update 1 to 3 entries in each of five tables:

wp_blogs, wp_options, wp_site, wp_sitemeta and wp_usermeta

I searched the database (not a single table, but the whole thing) for %mydomain% and found what changes needed to be made.

Finally, I changed the IP address at dm_ipaddress in wp_sitemeta to the new IP address. I set up all of the parked domains and email addresses, uploaded the database, and FTP’ed the files. Then, I changed the nameservers on the domains and voila — back in business with a completely seamless transition and zero downtime.

Hope this helps someone!

If you didn’t change the table prefix in your config.php, the default post and page table is wp_posts.

There are essentially two ways to do this:

1. .htaccess rule in the WordPress installation, or
2. .htaccess rule in subdomain’s document root

You can add the following line to your .htaccess file which should redirect all requests to blog.oursite.com to oursite.com/blog (put it after ReWriteEngine On):

RewriteCond %{HTTP_HOST} ^blog\.mysite\.com
RewriteRule ^(.*)$ /blog [L]

Or, you can give the subdomain blog.oursite.com its own document root on your server and then put a .htaccess file in it to redirect all traffic. (Same rule as above)

I can add a custom meta box to handle this. I was just hoping that I was missing something. It would be nice if the “sticky” option was in the same place for builtin posts and custom content types.

Thanks for the quick responses!

Sorry. I typically dive into the code. I thought you were doing some advanced programming and hit this snag.

If you didn’t do it, perhaps a plugin did? Did you try deactivating all of your plugins and check if the functionality returned? If deactivating the plugins fixes the issue, then start reactivating them one-by-one and checking until you find the problem.

If that doesn’t do it, let me know and we’ll try something else!

Thanks! That’s more or less what I thought but I figured I’d ask to be sure.

This has happened to me in the past, and whether it makes sense or not, I found that the problem seemed to be fixed when I didn’t use the latest version of jQuery on the admin screen.

For my sites, I would always use the latest version of jQuery by deregistering the jQuery that comes with WordPress and then enqueing the latest version of jQuery. Sometimes, I would have this “white text” problem in the WYSIWYG editor.

To fix it, I added if(!is_admin()) to my jQuery deregister/enqueue code so the admin dashboard still used the old jQuery and voila! Fixed.

If you’re not loading your own jQuery, also check to see if any plugins are using the latest jQuery. If so, you may need to edit the plugin.

Hope that helps!