Quick inline edit capability

[jbroadway]

A quick edit button for pages and blocks that lets you edit just the visible elements in-place on the page and save them without leaving the page.

[jbroadway]

Should work on double-click, with hover outline style + tooltip ("Double-click to edit") to show what is editable. Possible library for this:

http://www.appelsiini.net/projects/jeditable

Since it has integration with jwysiwyg as well:

http://www.appelsiini.net/2008/9/wysiwyg-for-jeditable

[spitlo]

Have you considered using Create (http://createjs.org/) for inline editing? IMO it looks and behaves nicer than jeditable, but it might be in to early a development stage.

[jbroadway]

I've looked at Create before, but I feel like their editing facilities are a bit obtrusive and still too limited. I don't like how they add their own toolbar across the top of the page either, this would conflict with the general toolbar we have.

We need something that works with both text and wysiwyg content, but that can use the jwysiwyg for the wysiwyg part. That way the existing plugins for linking, image selection, and embedding dynamic content, will work consistently between the two editing methods.

Proper also looks promising, but not feature-full enough yet, and uses its own wysiwyg editor. I'd much rather see an inline edit library provide a plugin facility and keep itself small rather than reimplement another full wysiwyg editor for inline purposes. Jeditable is the closest to this that I've found.

[spitlo]

Ok, that sounds reasonable. I was mostly put off by the way Jeditable looks, but it seems to be open for styling.

Elefant seems to be perfect for me, I'm looking for a light-weight CMS for those customers needing only to perhaps occasionly update the front page and where a full WordPress would be over the top. I'm really looking forward to the iniine editing capability, I think that's the most intuitive approach for non-techie types.

I'm currently translating Elefant to swedish, I'll get back to you when that's done.

One thing that I'm looking at is adding SDB as a database option, I stumbled across it when I was starting work on my own PHP/JSON based database and I didn't want to reinvent the wheel. http://pagenotes.com/wordpress/2011/12/08/sdb/ Is that something you think would be possible? I'm not asking you to implement it, I'd just like your input on the feasability. The most popular swedish web hosts doesn't provide SQLite, and some charge extra for MySQL. I don't think any of them allow you to install new modules. With SDB, you could basically just clone your dev server to your production server and the site would be live. I'd love to hear your reflections on that.

Great work!

// Spitlo

EDIT: Sorry, I', new to Github. Wrote this as an e-mail, didn't realize it would show up here. Hence the OT.

Den 17 februari 2012 18:15 skrev Johnny Broadway < reply@reply.github.com

:

I've looked at Create before, but I feel like their editing facilities are a bit obtrusive and still too limited. I don't like how they add their own toolbar across the top of the page either, this would conflict with the general toolbar we have.

We need something that works with both text and wysiwyg content, but that can use the jwysiwyg for the wysiwyg part. That way the existing plugins for linking, image selection, and embedding dynamic content, will work consistently between the two editing methods.

Proper also looks promising, but not feature-full enough yet, and uses its own wysiwyg editor. I'd much rather see an inline edit library provide a plugin facility and keep itself small rather than reimplement another full wysiwyg editor for inline purposes. Jeditable is the closest to this that I've found.

---

Reply to this email directly or view it on GitHub: https://github.com/jbroadway/elefant/issues/47#issuecomment-4023851

---

spitlo.com/myspace spitlo@gmail.com

[jbroadway]

Thanks, I'm glad you're liking Elefant! A Swedish translation would be awesome to have!

I definitely plan on styling jeditable to match the look of the rest of the CMS. I agree that its defaults aren't the nicest.

Looked at the SDB page, it looks interesting - a pure PHP JSON database. It might be a lot of work trying to write a full backend for Elefant based on it though, and I didn't see much about concurrent access to the files and locking for safe writes. What would be much easier would be to create an SDBModel class similar to the MongoModel one to add SDB support as an optional additional data store.

Are you sure they don't support SQLite? It's available in PHP by default so they would have to disable it to not support it. SQLite is a very commonly available alternative to MySQL, and also just stores the data in a single file for the site with no server daemon that needs to be running. You can check if it's available by uploading a a PHP script with <?php phpinfo(); ?> in it and loading that in your browser. Just search that page's output for SQLite. Hope that helps :)

[spitlo]

Yeah, it's strange they don't support SQLite. But seeing how it's included in PHP I guess it's a decision more than an oversight. I'll give the SDB thing a try, it would be kinda cool to get it working together with Elefant.

Anyway, looking forward to upcoming updates, running 1.1.4 on my dev server now. The one thing that didn't work was the line RewriteRule . index.php [L] in the root .htaccess file. I had to add a leading slash to index.php to access the admin interface. I guess it's to do with the way my host has their server set up.

//Spitlo

Den 19 februari 2012 20:39 skrev Johnny Broadway < reply@reply.github.com

:

Thanks, I'm glad you're liking Elefant! A Swedish translation would be awesome to have!

I definitely plan on styling jeditable to match the look of the rest of the CMS. I agree that its defaults aren't the nicest.

Looked at the SDB page, it looks interesting - a pure PHP JSON database. It might be a lot of work trying to write a full backend for Elefant based on it though, and I didn't see much about concurrent access to the files and locking for safe writes. What would be much easier would be to create an SDBModel class similar to the MongoModel one to add SDB support as an optional additional data store.

Are you sure they don't support SQLite? It's available in PHP by default so they would have to disable it to not support it. SQLite is a very commonly available alternative to MySQL, and also just stores the data in a single file for the site with no server daemon that needs to be running. You can check if it's available by uploading a a PHP script with <?php phpinfo(); ?> in it and loading that in your browser. Just search that page's output for SQLite. Hope that helps :)

---

Reply to this email directly or view it on GitHub: https://github.com/jbroadway/elefant/issues/47#issuecomment-4044500

---

spitlo.com/myspace spitlo@gmail.com

[jbroadway]

We're halfway to fundraising for an OEM license of the Redactor editor that will allow us to include it with Elefant. Once we replace jwysiwyg with that, inline editing will be much easier and cleaner to implement from there.

[jbroadway]

See issue #132 to track the Redactor integration, now that we've been able to purchase their OEM license. Once that's in place, inline editing should be fairly straight-forward to add.

[betaman]

Hey Johnny, I was thinking about the inline editing. Editing the text is probably no problem, but dealing with includes will be a little tricky. My Idea is to wrap a div around it and store the data in a data-embed attribute just like in the jwysiwyg Editor at the moment. Upon clicking an edit button (or even the whole embedObject) the layer from the embedObject- Manager would open and you can edit the embedded object as usual. After edititing you can easily render the new data and put it in the div via ajax, But there needs to be a way to find the include in the unrendered content from the database. Do you think it will be possible to backtrack the include and replace it with the new data?

[jbroadway]

I think we should start with the titles and body content for the page and for blocks, and worry about other kinds of inline editing later. That should keep the complexity down too. The admin could double-click the content itself, or click a "quick edit" icon, and it would replace the editable content with either a text input for the title, or the Redactor editor for the body (like the demo here: http://imperavi.com/redactor/examples/click-to-edit/). The new editor would have the same embed dialog, so it would work the same as the current embeds do. That seems to be the easiest way to start and then expand from there.

I'm not sure other embeds that are coded into the templates via {! app/handler !} tags should be editable directly though, if that's what you mean. The reason being an admin may not realize that the inline edit would affect the template itself, and consequently every page that template is used on. They may inadvertently shoot themselves in the foot.

I'm thinking a generalized way of exposing the inline editing to other apps would be the next step, so we can add inline editing to blog posts, events, you name it. Have to get my hands dirty first to see how that should work :)

[betaman]

Replacing the content of a block or page with an redacto editor is a good start. It will be the First step in the right direction, sorting out how the editing will be done, setting up the restful APIs and so on, But what's really cool in inline editing is that its Not a wysiwyg Editor, but Real wysiwyg. Wouldn't it be cool if You would Not See our bordered box with the Text, that there will be a navigation (or some other embedded object), but the real embedded objec itselft. I hope we will accomplish this. Maybe not in 2.0, but maybe in 3.0....

[jbroadway]

I think keeping some kind of border may be necessary for usability, to help the user visually identify the elements that are editable or not. Even the Aloha editor uses a border around the editable content while the editor is active.

Redactor can load custom CSS for its contents, so we should be able to match the content pretty closely to any site's style and making it feel pretty close to what you're describing already, although it does fall short. An example of the limitations would be if their site style did something like #content a { color: #159; }. The content in the wysiwyg editor wouldn't be wrapped in a <div id="content"></div>, so that style wouldn't be applied. So it's not true wysiwyg, but can appear close to it.

With Aloha on the other hand, they have a great idea, but I really don't like the usability of the editor's toolbar, and their dialogs for links and images feel amateurish compared with the polished experience of Redactor's dialogs. From the Redactor examples on their site, it seems to be able to work very similarly too, so I'm sure we'll get there in time :)

[betaman]

I didn't mean to give up on borders to indicate what's editable. In fact i think borders are a great solution. When I wrote

Wouldn't it be cool if You would Not See our bordered box with the Text, that there will be a navigation (or some other embedded object), but the real embedded objec itselft. I hope we will accomplish this.

I ment this:

The buttons are fine but a border could preserve the layout even better:

If you click edit the redactor opens (we will need a save button and an settings button to chenge meta infos)

And if you embed an Object, instead of this:

You will see this!

And Editing will work something like this:

On Hover:

On Click:

By the way: Why do you think #content a { color: #159; } wouldn't be applied? The redactor doesnt run in an iframe, so the style should cascade. Or is there something I'm missing?

And finaly: I don't like the look and feel of aloha neither .-)

Cheers Betaman

[jbroadway]

Ah now I see what you mean! Thanks for clarifying :)

I like the idea of rendering the dynamic elements, but that will come with some challenges too (shouldn't be able to interact with them within the editor, for example). Will be interesting to see how far we can get with that!

With Redactor's rendering, I'll have to test how it applies custom CSS to its content. I was under the impression it works more like jWysiwyg than Aloha in how it applies style, since it seems to have a separate internal style for elements than the rest of the page. I'll have to setup a quick test to try it out.

[betaman]

Right, lets see how far we can push it. The Pink pane that will show on hover should block any interaction. I planned it as a div that's placed absolute on a pretty high z-Index on the full extend of the embedded Object. The edit Button is just a hint, but actually you could Click anywhere (but the delete button) to edit.

I think the greatest challange will be syncronising the {! runinclude !} in the textarea along with the Redactors Content representation which holds the rendered embedded Object and finally our $page->body (or $block->body).

Lets see what we can come up with...

[jbroadway]

I wonder if we can't do it like this:

1. You select the handler you want from the embed dialog, enter your options, and click Embed.
2. Before Elefant includes the tag, it does a request for the handler's output via AJAX.
3. Once it has the response, it places it inside the <span class="embedded"></span> tag, so the rendered content is wrapped in a known tag in the resulting markup.

Style can be applied based on span.embedded and span.embedded * to get the desired behaviour (overlaid colour, etc). An onclick event handler could override any clicks inside the span and pass them to the span instead, which would trigger the embed dialog again, which would simply repeat steps 1-3.

If we needed to get more complicated with the inserted HTML, that wouldn't be hard. One trick will be updating the regex used in Template::run_includes(), but that should be easy enough to fix.

[betaman]

That sounds good to me. I think it will work :-)