Content Composer control becomes non-editable if one discards autosave changes
Permalink
There is an issue with Content Composer control becoming non-editable if one chooses to "discard changes" while editing a page. If one chooses to "publish changes", this problem does not appear. The following describes the steps to replicate this issue.
1. Create a new page using page type "Page" (the default one that comes with Elemental).
2. Go into Composer mode, fill in the details and click Publish to publish the page.
3. Go back into Composer mode. Check that the Content field in the Composer is editable.
4. Wait for the autosave message to appear at the top of the Composer form.
5. Click on the pencil icon to go into Edit mode.
6. Click on the pencil icon again to exit Edit mode. This time you will be asked if you want to publish the changes.
7. Choose "Discard changes".
8. Go back into Composer mode. Now, the Content field in the Composer becomes non-editable. In place of the textarea is this message: "Unable to load block into composer. You must edit this content from within the context of the page."
You can repeat these same steps, but instead of discarding changes in step 7, choose "Publish changes", and when you go back to Composer mode, you will still see that the Content field is still editable.
I've tried this on both 5.7.4.2 and 5.7.5.1 and the issue is present on both versions.
Is this a known issue, or is this the correct behaviour?
1. Create a new page using page type "Page" (the default one that comes with Elemental).
2. Go into Composer mode, fill in the details and click Publish to publish the page.
3. Go back into Composer mode. Check that the Content field in the Composer is editable.
4. Wait for the autosave message to appear at the top of the Composer form.
5. Click on the pencil icon to go into Edit mode.
6. Click on the pencil icon again to exit Edit mode. This time you will be asked if you want to publish the changes.
7. Choose "Discard changes".
8. Go back into Composer mode. Now, the Content field in the Composer becomes non-editable. In place of the textarea is this message: "Unable to load block into composer. You must edit this content from within the context of the page."
You can repeat these same steps, but instead of discarding changes in step 7, choose "Publish changes", and when you go back to Composer mode, you will still see that the Content field is still editable.
I've tried this on both 5.7.4.2 and 5.7.5.1 and the issue is present on both versions.
Is this a known issue, or is this the correct behaviour?
I have been troubleshooting this the entire day, and have found that this issue appears as long as changes are being "saved" (not "published") within the Composer interface, and then the changes are "discarded". Once the changes are discarded, going back into the Composer interface, you will see that the Content field will no longer be editable within Composer ("Unable to load block into composer. You must edit this content from within the context of the page.")
Sounds like you should file this exact message in the bug tracker:
http://www.concrete5.org/developers/bugs/5-7-5-1/...
http://www.concrete5.org/developers/bugs/5-7-5-1/...
Yes, I did that. The bug has been filed here:http://www.concrete5.org/developers/bugs/5-7-5-1/discarding-changes...
Just to add, I've actually poked around the database and c5 core a bit more, and found that the crux of the issue is that the record in PageTypeComposerOutputBlocks becomes dissociated from the correct bID. When changes are discarded, blocks are also deleted from Blocks and CollectionVersionBlocks tables, but the bID of that block still remains in the PageTypeComposerOutputBlocks table, instead of being reverted to the previous version block's bID. I've tested this by going into the DB to manually change the bID back to the correct bID, and was able to bring the compose control back.
I'm rather new to c5, and couldn't really find a way to fix this in the c5 core, although I am able to do a quick and dirty hack in my codes to force this bID column to be updated with the old bID. Hoping that someone might more experienced with c5 can come up with a proper fix for this.
Just to add, I've actually poked around the database and c5 core a bit more, and found that the crux of the issue is that the record in PageTypeComposerOutputBlocks becomes dissociated from the correct bID. When changes are discarded, blocks are also deleted from Blocks and CollectionVersionBlocks tables, but the bID of that block still remains in the PageTypeComposerOutputBlocks table, instead of being reverted to the previous version block's bID. I've tested this by going into the DB to manually change the bID back to the correct bID, and was able to bring the compose control back.
I'm rather new to c5, and couldn't really find a way to fix this in the c5 core, although I am able to do a quick and dirty hack in my codes to force this bID column to be updated with the old bID. Hoping that someone might more experienced with c5 can come up with a proper fix for this.
Excellent, chances are much better in the bug tracker than the general forums for this type of thing...
Thanks! Yeah, still finding my way around the community here.
