Collin Donahue-Oponski

Also, for faster response, please email us directly at help@cfwhiteboard.com, as we don’t seem to get notifications about new posts in this forum.

Hey @gerrynichecreative,

I think the first 3 points there would be accomplished using most any membership management plugin that you can find with WordPress. CF Whiteboard works with many membership management plugins out-of-the-box, but if you happen to find one that doesn’t work with it, I’m happy to figure out how to make it work with the plugin you choose.

As for #4, CF Whiteboard would allow her clients to track their workouts through your website or through the CF Whiteboard mobile apps, but doesn’t email all of the results to her. She would need to check back on her website or mobile app to see the results that were entered.

CF Whiteboard is designed for a coach with a group of athletes following the same workout programming from day to day. It’s very much focused on being a group workout tracking system. It’s not impossible to use for individual programming, but the user experience will suffer as that’s not what it was designed for.

I suppose it would help to know the comment being generated:

<!-- WP Super Cache is installed but broken. The constant WPCACHEHOME must be set in the file wp-config.php and point at the WP Super Cache plugin directory. -->

I had the same idea. What about this – can you add a Custom CSS Class column on the Class model? Then we can specify a CSS class that will be added to the container of each class. Then we can manipulate the background-color or text color using CSS.

I realize it could conflict with other styles, such as your handling of multiple classes per time block… but… in our current situation we only offer one class per time block as we only have one classroom. So the whole schedule is one solid color, and it’s difficult to scan for the class you want. What do you think?

References:

is_page

$accepted_args parameter of add_filter

Just noticed this message – Thanks so much for the kind review!

Hi,

Thank you so much for tending to this issue.

I’m a little embarrassed right now — I might have been thinking incorrectly when I sent this issue over (about how script versions are handled), and I’m afraid I’ve caused you to make a change that doesn’t significantly affect the end result.

Your changes include:
– Checking for a pre-registered version of the script before registering your own
– Changing the priority of your action hook to 120

The first change is a nice touch. Regarding changing the priority:
A developer who notices a version conflict can “solve” the problem by enqueuing their version of backbone before jetpack’s version. So when you change the priority of your action hook to 120, what you’ve really done is made it so that, by default, JetPack will defer to someone else’s version of backbone. Is that what you want to do? I’m thinking that, if anything, you would want to change the priority to 99 so that only someone who wants to intentially override JetPack’s version could do so. At least that way, it’s more likely that the conflicting plugin will break instead of JetPack. If the developer even notices, then they will be aware of the potential conflict, they can still find a way around it if needed (enqueue with priority < 99), and they will probably be more careful to test against JetPack in the future.

Any thoughts? Am I understanding this correctly?

Thanks again for your time.

Looking forward to it. Thanks so much for being so responsive!

That would be awesome, thank you!

I haven’t tried it with the content filter on my site, because I only needed the title filter for now. You could try a simple filter for testing:

add_action('wp', 'my_attach_test_filters');
function my_attach_test_filters() {
    add_filter('the_title', 'my_test_filter');
    add_filter('the_content', 'my_test_filter');
}
function my_test_filter($content) {
    return "Filtered: " . $content;
}

I can’t imagine it breaking anything, because the normal blog output would have these filters applied. But to avoid the chance of breaking anything, you could offer it as an option: apply_filters=”true” with the default as “false”.

The only reason I can think of is the same reason title filters exist in the first place. Sometimes themes or plugins want to modify or add to the title or content before it is output. I believe there are even default WP filters (to do things like replace ™ with ™) according to the last example of the apply_filters docs.

The code I posted might not be the best solution. It might be better to use apply_filters directly… maybe you wouldn’t have to hardcode every filter since you already have the $field variable with the name of the field. Here’s a list of filters: https://codex.www.ads-software.com/Plugin_API/Filter_Reference

You could probably get pretty far by doing a str_replace(‘post’, ‘the’, $field) and passing that as the $tag for apply_filters.

My temporary fix is to change this (in tpg-get-posts/inc/tpg-gp-process.class.php):

switch ($field) {
					case "post_title":
						$wkcontent = ($short_title)? $this->shorten_text($st_style,$st_len,$wkcontent,$this->ellip): $wkcontent;

to this:

switch ($field) {
					case "post_title":
						$wkcontent = ($short_title)? $this->shorten_text($st_style,$st_len,get_the_title(),$this->ellip): get_the_title();