Jared Cobb

Hi Greg,

Thanks for the heads up about that syntax error! This is a result of the current PHP version that your hosting provider is using. It looks like your provider is still using PHP 5.3 (or older).

For a few reasons the minimum PHP version required for this plugin is 5.6. The best option is to ask your hosting provider to update to at least 5.6. As an aside, PHP 5.3 reached end of life in August 2014 and hasn’t been receiving security updates since then. It’s a good idea to upgrade for that reason as well.

I’ll definitely update the plugin so that it doesn’t completely break on activation, so thanks again for letting me know about that!

I see. Would you be willing to create an API user for me (with the group_profiles service enabled) that I could test with locally? If so, can you send it to wordpress at jaredcobb.com?

It’s possible there are scenarios in my own test data that are different than yours which may be causing a problem with the synchronization. (In which case, I’m sure you would not be the only person having problems).

The <name> will probably be unrelated to the taxonomy problem, however what does the <group_type> node look like? (The <group_type> is what should map to the Group Type taxonomy).

@blueoaks Hmm, interesting. I would be curious what the actual XML response looks like from your service. If possible, can you visit https://<username>:<password>@<subdomain>.ccbchurch.com/api.php?srv=group_profiles&include_participants=false

(Replacing <username> <password> and <subdomain>, also note the “:” between the username and password)…

If you inspect a <group> that is missing its group type in WordPress, does it have a value in the XML like so, and is it correct? Is there anything strange about the Group Type name? (Any special characters like & % # etc)?

<group_type id="123">Some Group Type Name</group_type>

• This reply was modified 7 years, 1 month ago by Jared Cobb.

Hi @blueoaks, there is now a new release (version 1.0.0) that resolves several bugs (including this one).

Please note that there are some breaking changes with 1.0.0 and there is more information here: https://github.com/jaredcobb/ccb-core/wiki/1.0.0-Stable-Release

In short, the custom post type and taxonomy slugs have been renamed in order to come closer into line with WordPress community standards.

Hi @pastortraviswalker and @blueoaks, there is now a new release which resolves several bugs and improves performance. There are now also better developer docs located at https://github.com/jaredcobb/ccb-core/wiki

Hi, I haven’t made any updates in the past couple of years however I do have a 1.0 stable release planned in the next couple of months. The stable release will improve performance and standardize several filters and actions within the plugin.

Mapping them wouldn’t be terribly difficult, however your existing events plugin probably wouldn’t be compatible with most of the data that comes along. The custom post Title and Content would probably work, but none of the other attributes would map (event start / end times, event groups, etc).

You can give it a try on a test site by changing this line https://github.com/jaredcobb/ccb-core/blob/1a6e88b47ad7d5293e88bac277e72cbc4e33a602/admin/class-ccb-core-sync.php#L682

to use your plugin’s custom post type name (instead of $this->plugin_name . '-calendar' and also on this line:

https://github.com/jaredcobb/ccb-core/blob/1a6e88b47ad7d5293e88bac277e72cbc4e33a602/admin/class-ccb-core-sync.php#L698

You may need to comment out any code that tries to set taxonomy terms as well, like this whole range:

https://github.com/jaredcobb/ccb-core/blob/1a6e88b47ad7d5293e88bac277e72cbc4e33a602/admin/class-ccb-core-sync.php#L702-L708

Again, I’d only try this on a development / sandbox site first.

In case anyone else stumbles upon this thread with a similar issue, Otto figured out that it was because I made 2 commits for my code and tags. It’s better to use 1 single commit. More details on the answer over here.

@sean just FYI, your comments got me to thinking about the JavaScript in my theme. Turns out in my case I had enqueued jquery on my own separately and for some reason the plugin was trying to add its own jquery from the google cdn also. Once I sorted out that issue it started working again. Thanks.

@esmi: Good point, thanks. I was actually just adding an aside (to this thread) as a +1 since it’s the same issue. But in the future I’ll be sure to create a new thread for my instance. Thanks!

I’m getting the same behavior in test mode.

WordPress 3.8
Striper 0.22
Testing locally on my sandbox
Stripe is in Test Mode
Using their test CC numbers

(also tried to downgrade to Striper 0.20)