gtvracer

The reason the administrator is not in the list is because it was coded to exclude it. I modified my code and the administrator now shows up in the roles check list.

wp-content/plugins/ultimate-member/includes/admin/core/class-admin-navmenu.php::_wp_template()::155
– modified
-pre:
<?php $options = UM()->roles()->get_roles( false, array( ‘administrator’ ) );
-post:
<?php $options = UM()->roles()->get_roles( false );

Found the problem. In UM’s class-shortcodes.php::load() method, I needed to add this:

// adding this bit of code because $template will be null otherwise..
$template = $post_data[‘template’];

$this->template_load( $template, $args );

Otherwise, $template is uninitialized when calling template_load() and nothing shows up, as the file name to the php file cannot be constructed.

This is in UM version 2.0.43

You should try to solution I posted earlier, by taking control of wp’s cron process yourself.

Yes, I did, you have to setup a cron job to force woocommerce to check to see if it needs to update it’s subscription status. Basically, WP’s automatic cron’ing mechanism isn’t doing (don’t ask me why).

Here’s the php code:

<?php
/**
* WordPress Cron Implementation for hosts, which do not offer CRON or for which
* the user has not set up a CRON job pointing to this file.
*
* The HTTP request to this file will not slow down the visitor who happens to
* visit when the cron job is needed to run.
*
* @package WordPress
*/

ignore_user_abort(true);

if ( !empty($_POST) || defined(‘DOING_AJAX’) || defined(‘DOING_CRON’) )
die();

/**
* Tell WordPress we are doing the CRON task.
*
* @var bool
*/
define(‘DOING_CRON’, true);

if ( !defined(‘ABSPATH’) ) {
/** Set up WordPress environment */
require_once( dirname( __FILE__ ) . ‘/wp-load.php’ );
}

/**
* Retrieves the cron lock.
*
* Returns the uncached doing_cron transient.
*
* @ignore
* @since 3.3.0
*
* @return string|false Value of the doing_cron transient, 0|false otherwise.
*/
function _get_cron_lock() {
global $wpdb;

$value = 0;
if ( wp_using_ext_object_cache() ) {
/*
* Skip local cache and force re-fetch of doing_cron transient
* in case another process updated the cache.
*/
$value = wp_cache_get( ‘doing_cron’, ‘transient’, true );
} else {
$row = $wpdb->get_row( $wpdb->prepare( “SELECT option_value FROM $wpdb->options WHERE option_name = %s LIMIT 1”, ‘_transient_doing_cron’ ) );
if ( is_object( $row ) )
$value = $row->option_value;
}

return $value;
}

if ( false === $crons = _get_cron_array() )
die();

$keys = array_keys( $crons );
$gmt_time = microtime( true );

if ( isset($keys[0]) && $keys[0] > $gmt_time )
die();

// The cron lock: a unix timestamp from when the cron was spawned.
$doing_cron_transient = get_transient( ‘doing_cron’ );

// Use global $doing_wp_cron lock otherwise use the GET lock. If no lock, trying grabbing a new lock.
if ( empty( $doing_wp_cron ) ) {
if ( empty( $_GET[ ‘doing_wp_cron’ ] ) ) {
// Called from external script/job. Try setting a lock.
if ( $doing_cron_transient && ( $doing_cron_transient + WP_CRON_LOCK_TIMEOUT > $gmt_time ) )
return;
$doing_cron_transient = $doing_wp_cron = sprintf( ‘%.22F’, microtime( true ) );
set_transient( ‘doing_cron’, $doing_wp_cron );
} else {
$doing_wp_cron = $_GET[ ‘doing_wp_cron’ ];
}
}

/*
* The cron lock (a unix timestamp set when the cron was spawned),
* must match $doing_wp_cron (the “key”).
*/
if ( $doing_cron_transient != $doing_wp_cron )
return;

foreach ( $crons as $timestamp => $cronhooks ) {
if ( $timestamp > $gmt_time )
break;

foreach ( $cronhooks as $hook => $keys ) {

foreach ( $keys as $k => $v ) {

$schedule = $v[‘schedule’];

if ( $schedule != false ) {
$new_args = array($timestamp, $schedule, $hook, $v[‘args’]);
call_user_func_array(‘wp_reschedule_event’, $new_args);
}

wp_unschedule_event( $timestamp, $hook, $v[‘args’] );

/**
* Fires scheduled events.
*
* @ignore
* @since 2.1.0
*
* @param string $hook Name of the hook that was scheduled to be fired.
* @param array $args The arguments to be passed to the hook.
*/
do_action_ref_array( $hook, $v[‘args’] );

// If the hook ran too long and another cron process stole the lock, quit.
if ( _get_cron_lock() != $doing_wp_cron )
return;
}
}
}

if ( _get_cron_lock() == $doing_wp_cron )
delete_transient( ‘doing_cron’ );

die();
// end php code

Then I setup a crontab job that calls a script, which in turn runs the php script.

Hope that helped.

I’m running WordPress 4.4, Woocommerce 2.4.12 and Woocommerce Subscriptions 1.5.25.

I noticed that on many subscriptions, the last renewal should have happened in Nov, with last payment in Oct. These have the ‘Next Payment’ column still set to some Nov date. Any idea why subscription renewals did not occur automatically? It is now Dec 17.

Thanks.

Ok, it gets stranger. Between the time the $.ajax() is called and response received, something is issuing a request to reload the home page. So what I end up getting as a response is the XML for the home page, not the JSON structure that was supposed to have been received.

So know, I would want to know what action or callback is getting triggered for a non-admin user that is causing this during checkout, but not for the admin.

I dug around further, but doesn’t make much sense. Down in woocommerce/includes/class-wc-ajax.php, line 319, it makes a call to wp_send_json(). As a non-admin user, the response is actually correct, and has the fragments element. wp_send_json() calls “echo wp_json_encode( $response );”, so you’d expect the $.ajax() call gets this JSON structure, right? But no….

It gets basically a copy of the XML of the checkout page and nothing that was supposed to have been echo’ed from wp_json_encode(). In both admin and non-admin cases the blog_charset for the header() is UTF-8. I don’t see any difference between the two scenarios, but the fact is, $.ajax() doesn’t get the JSON object back when calling it as a regular user.

Any ideas?

After trying out all solutions like checking for errors on console (none found), expanding WP memory to 96M, editing .htaccess to allow access to admin.php, making sure site and home URLs are the same in WP settings, I found out why my checkout spinner kept spinning.

Go to your WP’s post database and check for conflicting Checkout post/pages. I had another from a different ecommerce package and that was hosing woocommerce. Cleaned out the database and the spinner is now gone.

Hope that helps someone else…