dameer

I’m facing the same problem, WC javascript doesn’t get available thru the DOM. Tho, there’s something I’ve noticed…

Your AJAX loaded template should have wp_head() and wp_footer(). All of WC templates use get_header(‘shop’) and get_footer(‘shop’) while there’s actually no ‘header-shop.php’ and ‘footer-shop.php’ files included.

Of course, you could create these two and let ‘header-shop.php’ be the one-line-of-code PHP page, like so
wp_head();
…and ‘footer-shop.php’ another file containing only
wp_footer();

That’s how WC required javascript gets loaded but there’s another problem: WordPress will automatically insert default META and LINK into your ajax content DIV. Even if you strip those down with

remove_action('wp_head', 'wp_print_styles');
remove_action('wp_head', 'wp_generator');
...
// all available by WP

…there will be a couple of more inserted by WC.

So, I guess the only proper method to make things work properly is to make WC javascript available to the DOM once enqueued.

Still not fixed … anyway, I guess authors forgot to wrap it up with an “if” clause at line #13…

if( get_option( 'indypress_formlist' ) ) { // here's the hack ...
    foreach(get_option( 'indypress_formlist' ) as $slug) { //we don't care about forms added by plugins
...
    }
} // end if clause

The problem relies in fact that foreach loop always throws an error if first param evaluates to null.

Hopefully it helps, great plugin!

I’m performing some test on that subject…

require_once( ABSPATH . 'wp-admin/includes/file.php' );
$overrides = array( 'action' => 'wp_handle_upload' );
$file = wp_handle_upload( $_FILES[ 'entryImage' ], $overrides );

…where ‘entryImage’ is supposed to be input type=”file”. Does it make any sense to ya?

No need for core files hack. Future posts can’t be treated as normal posts hence the fact they are not published. I had to modify 404.php template file because WP automatically redirects future post details request to 404.php. Something like this worked for me…

// put all of your future posts in separate category
// permalinks must be set to custom, /%category%/%postname%/
// ...otherwise you'll have to find the way to extract category and post slug
$cat_future_id = 4; // ID of future posts category
    // explode URI
    $arr_path = explode( '/', $_SERVER[ 'REQUEST_URI' ] );
    // get category slug from ID
    $future_name = $wpdb->get_var( "SELECT slug FROM $wpdb->terms WHERE term_id=" . $cat_future_id );
    if( $arr_path[ 1 ] === $future_name ) {
        // query_posts() or new WP_Query() will not work
        $wpq = "SELECT * FROM $wpdb->posts WHERE post_name='" . $arr_path[ 2 ] . "' AND post_status='future'";
        $post = $wpdb->get_results( $wpq );
        if( $post ) {
            foreach( $post as $pos ) {
                // do whatever is required
            }
        } else {
            // post not found, empty or error
        }
    } else {
        // display regular 404 error text
    }

Hopefully it does make sense. Just to repeat that this code must be used on ‘404.php’ template file!