• Sorry for the post length…

    First off a little introduction:
    I am currently working for a university who is attempting to switch a portion of their site (and course pages) over to wordpress-mu. They also want to be able to easily create new blogs and have all the options and pages saved between the old and new one.

    For that reason I have been working on a mu plugin to clone a blog (while, yes, it looks like WPMU-dev has one that would do the job all companies seem to be more willing to try it themselves and fail a time or two before purchasing one – this is no different).

    So far I have successfully got a plugin (my first WP plugin) up and running which is capable of cloning a selected blog (along with all pages and posts) to a new address, and displaying it correctly. However, the next part of the puzzle is proving to be a challenge.

    When I attempt to modify, create, or delete a page (or post, or attachment – though they are all stored in the same db table) through the administrative interface the server gets caught up in an infinite loop. Upon doing some digging there I found that the server is actually dispatching these two events until timeout:
    “clean_post_cache” and “clean_object_term_cache”

    Where the entire list of event calls looks like so (with a LOT of calls cut out to make it easier on the eyes):

    muplugins_loaded
    plugins_loaded
    sanitize_comment_cookies
    setup_theme
    load_textdomain
    load_textdomain
    auth_cookie_valid
    set_current_user
    init
    widgets_init
    load_textdomain
    auth_cookie_valid
    auth_redirect
    _admin_menu
    admin_menu
    switch_blog
    switch_blog
    switch_blog
    switch_blog
    admin_init
    load-post.php
    admin_action_edit
    update_post_meta
    updated_post_meta
    update_post_meta
    updated_post_meta
    posts_selection
    dbx_post_advanced
    posts_selection
    do_meta_boxes
    do_meta_boxes
    do_meta_boxes
    admin_xml_ns
    admin_enqueue_scripts
    admin_print_styles-post.php
    admin_print_styles
    admin_print_scripts-post.php
    admin_print_scripts
    wp_print_scripts
    admin_head-post.php
    admin_head
    adminmenu
    admin_notices
    submitpost_box
    post_submitbox_misc_actions
    post_submitbox_start
    media_buttons
    wp_print_scripts
    posts_selection
    edit_form_advanced
    dbx_post_sidebar
    in_admin_footer
    admin_footer
    admin_print_footer_scripts
    wp_print_footer_scripts
    admin_footer-post.php
    shutdown
    muplugins_loaded
    plugins_loaded
    sanitize_comment_cookies
    setup_theme
    load_textdomain
    load_textdomain
    muplugins_loaded
    plugins_loaded
    sanitize_comment_cookies
    setup_theme
    load_textdomain
    load_textdomain
    auth_cookie_valid
    set_current_user
    init
    widgets_init
    load_textdomain
    posts_selection
    template_redirect
    switch_blog
    switch_blog
    get_header
    suffusion_document_header
    wp_head
    wp_enqueue_scripts
    wp_print_styles
    wp_print_scripts
    suffusion_before_page
    suffusion_before_begin_wrapper
    suffusion_after_begin_wrapper
    suffusion_page_header
    auth_cookie_valid
    set_current_user
    init
    widgets_init
    suffusion_after_begin_container
    get_footer
    suffusion_before_end_container
    suffusion_page_footer
    suffusion_document_footer
    wp_footer
    wp_print_footer_scripts
    shutdown
    load_textdomain
    posts_selection
    template_redirect
    switch_blog
    switch_blog
    get_header
    suffusion_document_header
    wp_head
    wp_enqueue_scripts
    wp_print_styles
    wp_print_scripts
    suffusion_before_page
    suffusion_before_begin_wrapper
    suffusion_after_begin_wrapper
    suffusion_page_header
    suffusion_after_begin_container
    get_footer
    suffusion_before_end_container
    suffusion_page_footer
    suffusion_document_footer
    wp_footer
    wp_print_footer_scripts
    shutdown
    muplugins_loaded
    plugins_loaded
    sanitize_comment_cookies
    setup_theme
    load_textdomain
    load_textdomain
    auth_cookie_valid
    set_current_user
    init
    widgets_init
    load_textdomain
    auth_cookie_valid
    auth_redirect
    _admin_menu
    admin_menu
    switch_blog
    switch_blog
    switch_blog
    switch_blog
    admin_init
    load-post.php
    admin_action_editpost
    check_admin_referer
    update_postmeta
    updated_postmeta
    update_postmeta
    updated_postmeta
    update_postmeta
    updated_postmeta
    pre_post_update
    edit_term_taxonomy
    edited_term_taxonomy
    delete_option
    deleted_option
    clean_term_cache
    set_object_terms
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    .
    .
    .
    clean_post_cache
    clean_object_term_cache
    clean_post_cache
    shutdown

    (these event calls were found by adding a few lines – for file output – to the wp-includes/plugin.php file)

    After finding this out I thought that it may have something to do with the database items not being updated in the cloned set of tables, so I went through and added a significant amount of code to get all of those up and running and at this point I can’t find any place which I believe to be the problems in the database (I am just very lost and confused as to why this problem would be happening).

    If you need to see my code I can post a copy of it.

    Any help or insight is greatly appreciated.

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter amath

    (@amath)

    Well, I understand that bumping is frowned upon here (as it takes the post off the “no-replies” feed), but it has almost been three days with no reply so I am going to assume there won’t be one.

    For anyone who was interested in this, I have found out some additional information on where the problem is being caused from. It has to deal with the wp_#_options table in the database. If you make an exact clone of it the cloned blog will function exactly as the original did up until you try to make an edit to the posts/ pages/ media, at which point it will go into the infinite loop (as stated above). I found this out by cloning every other table (from the host blog) except the options table and then running it and the clone worked fine (but didn’t have all the options I wanted cloned).

    As I stated before, I would post code if anyone asked. Well, I have since then posted it elsewhere, so as to reduce the amount of typing and Ctrl+C, Ctrl+V I have to do in a single day I will just link to it:
    Thread.

    Hopefully someone has some insight as to which options require what to make a blog run correctly.

    amath,

    I don’t have answers, but am wondering if you discovered anything with this. I’m facing precisely the same problem. That is, I have cloned a blog and restored it under another domain, and as soon as I attempt to update a page on the destination blog I encounter a lengthy delay followed by a max execution time error. It appears to be triggering clean_post_cache and clean_object_term_cache repeatedly.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Cloned Blog causing infinite loop on post/ page creation’ is closed to new replies.