impresspages / ImpressPages

ImpressPages is php framework with admin panel. Build functional website in one hour.
http://www.impresspages.org
Other
501 stars 178 forks source link

Support for blocks that can show the same content on all pages, but have revision control. #759

Open jmasukawa opened 8 years ago

jmasukawa commented 8 years ago

The functionality of static blocks are very useful, but it seems that they have no revision history. https://github.com/impresspages/ImpressPages/blob/2e54345e9f39ac9ea3de884a5145a0295955a0e7/Ip/Block.php#L60-L62

It looks like this is by design. The problem is that this means that if clients are editing global sidebars (using a static block), and they save a mistake, they are unable to recover the content. It would be nice to have revision history on a static block.

Pardon my ignorance if there is a way to make a global sidebar with revision history.

Thank you!

maskas commented 8 years ago

You are right. This is done that way by design. And would be a nice feature to have.

jmasukawa commented 8 years ago

Thanks for the reply! What was the design reason for always setting revisionId to 0? I think it's possible to get behavior on revisionId like normal blocks, but just display the same content across all pages.

Maybe we can always keep the data on the main page version (or a page that is guaranteed), and then display that content on all other pages. Editing the block on other pages would end up working the same; data would be stored as the main page version.

If you have criticisms of this design, or a better alternative, let me know. =) I can experiment with implementing this in my local branch, and submit a pull request if things work okay.

maskas commented 8 years ago

I don't see an easy solution without side affects. If you do it in your suggested way, you will face many inconsistancies and strange bits of code. E.g. you will have to create a new revision for the home page when user has changed the text in the static block on completely different page. How would you know, that the home page is the one that has to carry revision id's. There are many websites that have static blocks only on internal pages. In that case which one of those internal pages is the "main". If these points are not clear, you will understand them when you will start to implement.

jmasukawa commented 8 years ago

Ah, I see what you mean. That would be troublesome...Hm. How about replication of data upon saving a static block, to all pages that use the static block? I suppose this would be a "pseudo static block", and not a true static block, so I can see you might not want this to be in your project =)

Suppose we have the following pages: main, home, page1, page2, internal1, and internal2

And suppose we have a static block "side1" shared between home, page1, and page2, and a static block "side2" shared between internal1 and internal2.

Editing "side1" on home would behave like a normal block for revision purposes, except this data will be replicated to the page-specific version of "side1" that is present on page1 and page2 at the same revisionId. Viewing page1 will show the same content when visited for edit or view.

I acknowledge it's probably not the the cleanest solution, and might just be better for something for me to implement on my local and use with my client.

maskas commented 8 years ago

You can invent your won "static blocks" or any other mean of implementing similar feature. It may go as a plugin. In that case you would have a complete freedom. And if it becomes a de facto standard, it could be included into the core.

jmasukawa commented 8 years ago

Ah good point, will give it a go as a plugin and see how that goes. If you'd like to leave this open for tracking, please do, or feel free to close this out. Thanks so much!

eazuka commented 8 years ago

@jmasukaw did you later work on this topic, any success?

jmasukawa commented 8 years ago

@eazuka Unfortunately I did not. In talking with the client, the content of the sidebar (social media account links, phone number, address, etc.) was determined to be unlikely to change and not needed to be changed by the client. I ended up just making it a part of the page template.

Sorry about that!