PaulMorris

How about calling the new plugin something like:

“Liberation for Jetpack”
“Data Liberation for Jetpack”
“Unlinking for Jetpack”
“No Strings Attached for Jetpack”

These are mostly tongue in cheek, of course. I am glad that you are working on Slim Jetpack and its successor. Please let us know about the new plugin when it’s available. Thanks!

I have the same question. Now that the markdown plugin has been merged into Jetpack I would rather see it added to Slim Jetpack than use the official Jetpack (which is more than I need). Thanks!

More info: The problem still occurs when using the (non-legacy) [wp-stripe] shortcode, even with “Enable SSL for modal pop-up?” set to yes.

-Paul

It’s working now. I’m not sure why or how.

I tried applying the workaround to bug 19378 that’s posted in comment 6 of this page:
https://core.trac.www.ads-software.com/ticket/19378

Since it looked related. It didn’t seem to have an effect immediately, but maybe that’s what did it?

Sounds like it might be an issue with rewrite rules for URLs. Maybe try going to your Settings –> Permalinks page which will refresh the rewrite rules / settings.

I tried creating a completely fresh test install of WordPress, and setting up the custom role, capabilities, and post type from the functions.php file (no plugins used), to see if this would correct the problem.

It didn’t. I got the same behavior with the preview button, while everything else worked as it should. This leads me to believe it may be a bug in WordPress rather than something I am doing wrong.

I hate to have to resort to this, but I think I will have to try hiding the preview button with CSS, hopefully just for those custom users. The new code I used is below.


// Register Custom Post Type
function my_custom_post_type() {
$labels = array(
'name' => 'Wiki Pages',
'singular_name' => 'Wiki Page',
'menu_name' => 'Wiki Pages',
'parent_item_colon' => 'Parent Wiki Page:',
'all_items' => 'All Wiki Pages',
'view_item' => 'View Wiki Page',
'add_new_item' => 'Add New Wiki Page',
'add_new' => 'New Wiki Page',
'edit_item' => 'Edit Wiki Page',
'update_item' => 'Update Wiki Page',
'search_items' => 'Search wiki pages',
'not_found' => 'No wiki pages found',
'not_found_in_trash' => 'No wiki pages found in Trash',
);

$rewrite = array(
'slug' => 'wiki',
'with_front' => false,
'pages' => true,
'feeds' => true,
);

$args = array(
'label' => 'wpage',
'description' => 'Wiki pages',
'labels' => $labels,
'supports' => array( 'title', 'editor', 'revisions', ),
'taxonomies' => array( 'category', 'post_tag' ),
'hierarchical' => false,
'public' => true,
'show_ui' => true,
'show_in_menu' => true,
'show_in_nav_menus' => true,
'show_in_admin_bar' => true,
'menu_position' => 25,
'can_export' => true,
'has_archive' => true,
'exclude_from_search' => false,
'publicly_queryable' => true,
'rewrite' => $rewrite,
'capability_type' => 'wpage',
'map_meta_cap' => true,

);

register_post_type( 'wpage', $args );
}
// Hook into the 'init' action
add_action( 'init', 'my_custom_post_type', 0 );

// set up custom role and custom capabilities
if ( is_admin() && '1' == $_GET['reload_caps'] ) {

if ( get_role( 'wiki_author' ) == null) {
add_role('wiki_author', 'Wiki Author', array(
'read' => true,
));
}

$administrator = get_role('administrator');
$editor = get_role('editor');
$wiki_author = get_role('wiki_author');

$wiki_author->add_cap( 'upload_files' );

foreach ( array('publish','delete','delete_others','delete_private','delete_published','edit','edit_others','edit_private','edit_published','read_private') as $cap ) {
$administrator->add_cap( "{$cap}_wpages" );
$editor->add_cap( "{$cap}_wpages" );
$wiki_author->add_cap( "{$cap}_wpages" );
}
}

More clues: if I give the custom role the capability to “edit_posts” then everything works fine. Without it, preview does not work as described above (even though the custom role has the capability to “edit_wiki_pages”).

I don’t think it can be done. I went with this compromise:

/one-two/ — for custom post type
/one-two/groups/ — for custom taxonomy
/onetwo/ — for regular pages

Then the URLs all at least make some sense, even if I’m asking for confusion by using both a hyphenated and a non-hyphenated slug.

This works because slugs for custom taxonomies and custom post types can have “/” in them, so the slug for the custom taxonomy is: “one-two/groups”. See:
https://mondaybynoon.com/20110520/revisiting-custom-post-types-taxonomies-permalinks-slugs/

I have also seen this problem. Thanks for the tip on the fix! (Although I’m using the in-line version…)

1.4.2 working great, thanks!

Awesome! 1.4.2 is working perfectly with both the inline form and the iframe modal form. No tweaking required.

Thanks Noel and hmoore71!

Looks like I might make my weekend deadline afterall. ??

-Paul

I decided to try a new start for a new day. I re-installed WP Stripe 1.4.1 from scratch, then edited stripe-functions.php to include both these lines (to fix the problem with it not working when not logged into wordpress).

add_action(‘wp_ajax_wp_stripe_charge_initiate’, ‘wp_stripe_charge_initiate’);

add_action(‘wp_ajax_nopriv_wp_stripe_charge_initiate’, ‘wp_stripe_charge_initiate’);

This time it worked when using the iframe modal pop-up! No “0”, a success message, and the transaction came through on stripe and in the WP Stripe admin area.

Next up was trying to get the inline “legacy” form to work. So I tried hmoore71’s fix for this, and then my “hardcoded” ajaxurl variable. In both cases the transaction went through on the back end (hooray!), but also in both cases I am not getting a “success” message for the user. The form just “freezes” with the submit button “greyed out” after clicking it.

But this is real progress!

EDIT: Oops, looks like Noel released 1.4.2 to fix this, going to try it now. Should have refreshed the page before posting. -Paul

Hi hmoore71, Yeah, I actually did get your post, and I have tried adding both those lines in stripe-functions.php, but it’s still not working for me…

Have you seen the “0” appearing at the top of the form? Or has it worked when logged in, but not when logged out for you?

Good to know about your fix for ajaxurl working with your SSL site. I will have to try setting it to use http instead of https for that and see if it will work for me.

Thanks, I tried that (adding the second line of code in stripe-functions.php) and it didn’t fix things… See my post in “Not Working Most of the Time” for more details.