I have a custom role based on the Contributor role. In Access Control they are set to be able to edit their own posts.
I have a View that lists their posts and displays links to edit the posts. These links only appear next to posts that have a status of 'published'. If they are have either 'draft' or 'pending' status, the links are not displayed.
If, however I add a CRED edit post form to the View, the post is displayed no matter what status it has and the User can edit it.
This doesn't make sense. If a User has the right permissions to edit a post, then post edit links should also be available.
I escalated this to the development team and the response is that it's not a bug. it's by design and here it's a part of their response:
"CRED edit post liks create a link that, when clicked, point to the frontend page for a given post, and display the desired edit form insted of the post content. But when a post is not published, there is no such thing as "frontend page for a given post", because, well, it is not published."
For now, I submitted this again as a feature request in our system so that it can be implemented in the future.
Please let me know if you are satisfied with that.
You can close this ticket and follow the CRED changelog page to know the newly added features to the plugin: https://toolset.com/download/toolset-cred/#changelog
Unfortunately I'm completely dissatisfied with the development team's response.
when a post is not published, there is no such thing as 'frontend page'...because it's not published'
This comment is utter nonsense for the following reasons:-
1. They are not taking users' capabilities into account and they have no choice but to take these into account. WordPress allows Users with the right capabilities to view/edit post with draft status so if you're providing a link to a post then you have to enable display to occur according to post status & user capabilities.
2. If their comment were true, then it wouldn't be possible for a User with the right permissions to view & edit an edit version of a CRED form (displayed directly on a page or via a View rather than via a link to it) when the post has a status of draft but we all know that this IS possible.
3. The behaviour of the edit links HAS to behave in the same way as the edit version of the form. It's illogical and inconsistent to be able to edit a post in draft status in one area of a website (if presented with the edit version of the form) but not be able to edit the same draft post in a different place on a website (if led to it by a credit edit post link).
4. Here's the definitive point; the former cred_link_form shortcode behaves the way it should !!!!!
Something has been changed in the move from using [cred_link_form form='x-y-z' form_name='X Y Z' text='Edit %%POST_TITLE%%'] to using [toolset-edit-post-link content_template_slug="a-b-c"]Edit %%POST_TITLE%%[/toolset-edit-post-link].
It shouldn't be treated simply as a feature request; it's already been a feature, it's been taken away and needs to reinstated.
Thank you for your reply and I forgot to thank you for pointing out to this whatever we can call a feature or a bug.
Let me clarify the developer's feedback.the feedback means that you can preview the post but you are not actually viewing it which means that there is no actual page for the post to view it in the frontend.
What CRED does is that the form replaces the post content in the frontend. and because there is no page for the post because it's not published, then the edit form can't exist anymore.
The good news is that the request is approved which means that the development team has a way to implement this.
My understanding of the erratas list isn't just to 'announce a fix', it's there to also provide details of known issues that are being addressed.
You indicated the fix for this issue was a 'priority'. You now seem to be suggesting this isn't the case anymore.
This issue isn't a feature request. It's a function that no longer works correctly. That makes it a 'bug' (for want of a better word) and should therefore be included on the erratas list. The fact that it's not suggests it's not being taken seriously and won't be addressed anytime soon.
I don't think that's good enough.
I have pursued the use of Toolset's plugins for many reasons but one of the main benefits is the ability to edit custom posts on the front end. I have spent 1000's of hours over the last year building my second website using Toolset plugins. A fundamental part of the design is based on the ability for users to be able to manage custom posts on the front end which means I can keep users out of wp-admin. This has all been possible until the change in the shortcode format for editing posts. So now my site no longer works as constructed and you don't appear interested in reinstating the function with any urgency.
Ultimately this hits my online reputation and my pocket.
Let me first apologize for the inconvenience we might be causing you. We had a different view in how this should be managed, because we considered that this new ability to add edit links using a resource (a Content Template or a layout) was a new solution for a long standing issue we had with the old CRED edit links. As it was a new development, we tried to narrow it down to the most general use case, which involved showing edit links for indeed published posts.
But we were wrong and you were right. The old CRED edit links covered the whole use case, incluing the ability to edit not published posts by those who can indeed edit them.
Our new approach is a little more limited in that regard. Because the link itself just links to the post frontend page, with an extra URL parameter that forces the right resource (Content Template or layout) that includes the CRED edit form. But for not published posts, the limitation is clear: there is no link to the frontend page for that post!
However, there might not need to be one.
I am currently testing a solution that for not published posts (drafts, pending review, future posts, etc) checks whether the current user can inded edit that post. If tht is the case, we will display the edit links, but instead of linking to the frontend page for that post, that does not exist, we will link to the frontend preview of that post, which is available for that current user.
Long story short: we will have a solution for this as soon as we get this tested. That solution will be publishd in an errata that I will link here, so you can use it right away. And the final, stable, definitive solution will be included in the next version of Views.
Many thanks for your response, clarification and acknowledgement of this issue.
I'm very pleased to hear you're actively looking into this.
I'm a little worried by something you said in your penultimate paragraph:-
instead of linking to the frontend page for that post, that does not exist, we will link to the frontend preview of that post
If we link into the preview of the post, will this mean the user (with the correct permissions) will be able to see the post but not edit it? I perceive a preview to be just that and not actually the edit version of the form (which is what we had before). As long as my users with permissions to read & edit posts with draft or pending status will be able to edit or publish such posts on the frontend (as before), I'll be a happy bunny.
On a positive note, having been sceptical initially about using Content Templates to display edit forms, I can now see the benefits and an increase in flexibility which is never bad!
