Using WP Libre Form with SEO Framework puts forms in sitemap.xml

[LauraRocks]

When WP Libre Form and SEO Framework plugin (https://fi.wordpress.org/plugins/autodescription/) in same site, the forms are marked "public" and so they appear in the automatically created sitemap.xml made by the SEO Framework plugin. This is a problem because the forms are not supposed to be accessed directly so the sitemap directs people to non-working form pages. Does anybody have a workaround for this?

[timiwahalahti]

This is because we register wplf-form custom post type as public. Some time before form could have singular view, but we changed it so that forms can be only embedded. CPT was kept as a public to support previewed for logged-in users, others will see 404-page.

I think previews are something that we need to make differently, without need to have CPT set as public. Or we should just remove preview functionality (probably not a good idea). So this is a bit wider issue we need to address.

As for now, workaround for The SEO Framework is something like this

add_filter( 'the_seo_framework_sitemap_exclude_cpt', 'wplf_issue_autodescription_sitemap' );
function wplf_issue_autodescription_sitemap() {
    $remove = array(
        'wplf-form',
    );
 
    return $remove;
}

[k1sul1]

I think we could (should) incorporate the workaround into this plugin itself.

For Yoast and SEO Framework.

[timiwahalahti]

As hotfix yes we could, but there's a heck lot of other plugins making all kind of things relying on CPT being public. If we start to patch those case by case, it's just endless job bloating our codebase.

[k1sul1]

Agreed, a line has to be drawn somewhere, but I think we can make exceptions for plugins with hundreds of thousands of users.

inc/compability.php goes a long way for a few filters.

[timiwahalahti]

Yeah, lets add workarounds for popular plugins in 2.0 if nobody doesn't come up with new way of making previews? Somebody(tm) should then check at least which SEO and sitemap plugins are most used, so we can make workaround for those at the same go.

[ideag]

A (very) simple solution for previous could be to conditionally set wplf-form CPT to public just for logged in users and maybe even only when doing a preview. Something along these lines:

  'public' => (is_user_logged_in() && is_singular( 'wplf-form' ) ? true : false.

Would that break anything?

[timiwahalahti]

@ideag I'm quite sure that would do the trick! Not sure if is_singular( 'wplf-form' ) check is needed and if we should test user capability (to exclude subscribers), but your idea is pure awesomeness in it's simplicity :) Would you like to test that out and make a PR?

[ideag]

I'm adding is_singular check to further limit situations where CPT is public - this way the only place where it is public is the preview link itself. Less contact surface - less chance to break something that relies on CPTs being public. Excluding subscribers is also a neat idea. I am a bit swamped for a couple of days, but I could make a PR over the weekend, unless someone else picks it up earlier.

[k1sul1]

Random thought: that wouldn't affect permalinks in any way, right?

I mean, you have to flush the permalinks after creating or changing a post type, is that not the case in this situation?

[rask]

I would just create a custom preview system with template_redirect/template_include and authorization. Maybe even create a custom admin page and read the preview params from GET. Juggling with the built-in post type arguments for this sounds a bit shaky.

[ideag]

@k1sul1 good point, I'd have to check the behavior on this. For our purposes, permalinks do not have much meaning anyway we can always use plain url to get around it. And as for flushing permalinks, we only have to do that, if we want fresh changes to take effect immediately. If we do not need that, there is no need to flush.

@rask My first impulse was also to offer a custom preview system as a solution, but if this would work, it would save us the trouble of doing so. And we can always come back to that solution if the above does not pan out.

[despecial]

The other problem I see:
when editing normal content and want to include a link, all the forms are in the suggestions list. Which is not useful nor usable. So this CPT should definately not be public any more.