Japh

You could also check the wp-config.php file for your installation. Look at the line like:

define('DB_HOST', 'localhost');


If yours is the same as above, and says “localhost”, then yes, you can simply copy the wp-config.php and change the prefix.

Another way to do this would be to use WordPress Multisite, which allows you to run a single WordPress installation that creates multiple sites. You can then install the Domain Mapper plugin and run different domains for each sub-site. This is called Creating A Network, and you can read about it in the Codex.

Is there a particular reason you need to use the same table_prefix? It would be better to use a different prefix if you’re able to.

Hey there,

What happens if you login at https://www.17bcars.com/glamis and go to the Settings -> General and change “WordPress address” and “Site address” to https://www.glamistrips.com/

That might fix it for you. I suspect what’s happening is when you try to login, WordPress redirects you.

Please backup your database before making this change though. If it doesn’t work, you may not be able to login from either location

I hope that helps!

Try making sure your permalinks are correct. I noticed when I go to your “Welcome” post, the URL looks like this: https://exploringmystery.com/uncategorized/postname%/

Looks like a malformed permalink pattern to me. Perhaps that will help resolve the problem for you.

Do you have a php.ini file somewhere? It may be that fastcgi is “timing out” because PHP is timing out. So changing the max timeout in php.ini could help.

Yeah, that would certainly be worth a try. If the timeout is set very small, anyway. If the timeout is already fairly big, then the problem isn’t a short timeout, but rather a long-running process.

See what the timeout is, and if it’s less than say, 120 seconds, increase it and see how you go.

Don’t forget to put it back once your import has succeed though, because having a really long timeout when you don’t need one can mask other problems.

Is your server *nix or Windows? Running Apache or IIS?

It might be worth contacting your hosting provider for assistance with troubleshooting. They’ll be able to access everything more easily and are probably used to this sort of thing.

Oh great, my pleasure! I missed that, so I’m glad I included the extra explanation ??

Try this:
<?php get_post_meta(get_the_ID(), 'blurb', TRUE); ?>

Most WordPress loop functions like “the_content()” and “the_title()” directly output the information, instead of returning it for use in other functions. Most of them also have a “get_the_content()” and “get_the_title()” alternative for use in these situations instead.

So for example, you can do <?php the_title(); ?> to output the post’s title, or <?php echo get_the_title(); ?> (With “the_xxxx()”, you don’t need to echo, they do that bit themselves).

I hope that makes sense ??

Hello can you please clarify what version of WordPress you are running? Is it the latest (3.2.1)

Also, does your theme (or possibly any of your plugins) use the TimThumb script? You can find some information on the recent exploit of the previous TimThumb version and how to fix it here: https://markmaunder.com/2011/08/01/zero-day-vulnerability-in-many-wordpress-themes/

I hope that helps you.

Have you checked in the error logs on your server? They may shed some light.

Obviously an error is occurring, but for some reason isn’t displaying, but it’s more than likely still being output in an error log file somewhere. Try checking the php error log, and also the apache error log file.

@lamenteinc: Have you tried updating to the latest version of the plugin? The author has implemented a fix in this version that has sorted the issue for me. Hopefully it works for you too ??

Hey Olederer, have you tried clicking into the text box in the widget? The WYSIWYG editor then opens up for you, and you save that HTML back into the widget.

If nothing happens when you click in the text box on the widget, see if you can disable other plugins and see which one might be conflicting.

I have a work around for the moment. I added the following method to your “WYSIWYG_Widgets_Admin” class:

function preload_dialogs()
{
    ?>
    <div id="preloaded-dialogs" style="display:none;">
    <?php do_action('tiny_mce_preload_dialogs'); ?>
    </div>
    <?php
}

And then replaced this line:

add_action('admin_print_footer_scripts', 'wp_tiny_mce_preload_dialogs');

With this line:

add_action('admin_print_footer_scripts',array(&$this,'preload_dialogs'));

It’s probably not perfect, as I’m just working around the fact that the ‘wp_tiny_mce_preload_dialogs’ function can’t seem to be called.

Maybe it’ll help you work out the problem though, or give someone else a temporary fix ??

Hi Danny,

I’m also having this problem in WordPress 3.2. I even tried turning off all other plugins and reverting to the WordPress Twenty Eleven theme.

So this problem seems to at least appear on a WordPress installation updated to version 3.2, with standard theme and no other plugins.

Hopefully it won’t be too tricky to fix ??