[Module] Front End Editing (split from Adding an Edit Button to every page)

Check OnParseDocument and OnWebPagePrerender on the System Events tab

Where is OnParseDocument on the System Events tab? I do not seem to see it. I have already uploaded the modded parser file. Plus, you have to edit the dependency to the QuickEdit plugin before step 6 will work.

Either way, I cannot get your module to run. I followed your instructions, but to no avail. Please advise.

P.S. Try the module installer from the Xinha and TinyMCE RTE’s.

Quote from: Mark at Aug 14, 2005, 11:28 PM

Where is OnParseDocument on the System Events tab? I do not seem to see it. I have already uploaded the modded parser file. Plus, you have to edit the dependency to the QuickEdit plugin before step 6 will work.

Sorry about that Mark. I forgot to mention that you need to add the OnParseDocument plugin to the DB too. If you run this SQL in your DB it should fix it.


I’ll take a look at those installers tonight, I’m curious to see how they work. We are planning on having this as a core plugin by the next release anyway, so the installer isn’t too important but I need to learn anyway.

I tried the sql but it still does not work.

I’ve been in touch with Mark trying to work through this. There seems to be some problem that still needs worked out. If anyone else has or hasn’t had problems getting it to work I’d appreciate hearing from you.

One issue is that the default Module path is wrong. It points to a QuickEdit folder instead of the QuickEditModule folder. This is a simple setting in the Paramaters tab of the module and is easy to fix.

I don’t have too much time now as I’m at work, but I will do some more testing and maybe some better documentation tonight.

For all those interested, the module stops when it comes to replacing the edit link comment with the real edit link.

One thing to note is that it might be best to use lowercase letters for file and folder names. Linux is case sensitive but windows doesn’t care.

Okay, I think I have everything fixed now (it turns out that I accidentally included an older version of one of the files ). But while I was at it I fixed another bug that I discovered.

The old installation instructions still apply.

Update:
Please see the newer version here.
http://modxcms.com/forums/index.php/topic,765.msg4457.html#msg4457

This is such a nice and helpful piece of work, aNoble, thank you so much. Some questions and thoughts:

1. Your ManagerLogin.zip file seems to come up empty. Could you please re-upload?

2. You mentioned in an earlier post setting up an option to choose either a text editor or text box. Is this implemented? I’m not seeing it. It would be great if it could be specified in the template, e.g. [*#content:txt*]. Also, what about something like [*#content:fck-basic*] or [*#content:fck-standard*], allowing different toolbars for types of fields?

3. Have you (or anyone out there) thought about the option of editing right on the page?
I did something before using DOM contentEditable, might try to get it going in Modx if no one else is working on it.

4. Related to this general topic, the idea of "frontend-only" site editing comes to mind. From a previous post in this thread (Webmedic):

How about buttons for adding a child or sibling document also? in this way it would be very easy to add a new document wherever you want.

I’d like to extend Webmedic’s request to propose providing all the basic page options, add child, add sibling, publish, unpublish, delete, perhaps in a pop-up window but better in a menu bar at the top of a page (basic users can get frustrated when they click the parent window and lose the pop-up). Moving pages would probably require a pop-up to show the page tree, but perhaps there would be other ways.

Among my end users, some see the manager as pretty intimidating and non-intuitive, even with only basic editing privileges. These are the sorts of users who will never put in a chunk, snippet or TV--they can’t begin to understand them. They just want to put in text and images. It might be just the ticket to be able to keep such users away from the manager interface altogether, and could be a feature to really set Modx apart.

Quote from: jlarson at Aug 16, 2005, 08:11 PM

This is such a nice and helpful piece of work, aNoble, thank you so much. Some questions and thoughts:

Thanks I enjoyed working on it.

1. Your ManagerLogin.zip file seems to come up empty. Could you please re-upload?

Hmm... seem to work fine for me. You may want to clear out your cache and try again. Also, you may want to check that you don’t have sytems files hidden.

2. You mentioned in an earlier post setting up an option to choose either a text editor or text box. Is this implemented? I’m not seeing it. It would be great if it could be specified in the template, e.g. [*#content:txt*]. Also, what about something like [*#content:fck-basic*] or [*#content:fck-standard*], allowing different toolbars for types of fields?

This should already be implemented for template variables. See the input type field in the template variable screen. The content area uses whichever richtext editor is used in the manager. The pagetitle, longtitle, and description use textboxes. Eventually the content and other fields sholud also become default TVs, so you’ll be able to easily customize their input methods.

3. Have you (or anyone out there) thought about the option of editing right on the page?
I did something before using DOM contentEditable, might try to get it going in Modx if no one else is working on it.

This was suggested a while ago. I looked into it before I started on this project. There are a couple of issues. Number one I don’t personally like the fact that contentEditable is not a standard and as a result it’s handled very differently in different browsers. Secondly I’m not sure how plausible it would be to implement it without the template being very specifically designed to handle it, especially in the case of gecko browsers where an iFrame has to be rendered dynamically. You’d have to figure out a good way to handle inline elements and empty block elements. I’m not saying it’s impossible or it shoudn’t be done, but I have my doubts that it should be the default frontend editing method, I think we need to start out with a more reliable method that we can always fall back on if necessary. I’m no expert in this area, so if anybody knows more than me on this issue I’d like to hear your input.

4. Related to this general topic, the idea of "frontend-only" site editing comes to mind. From a previous post in this thread (Webmedic):

How about buttons for adding a child or sibling document also? in this way it would be very easy to add a new document wherever you want.

I’d like to extend Webmedic’s request to propose providing all the basic page options, add child, add sibling, publish, unpublish, delete,

I think it would definitely be good get add a page, publishing and deleting working. Publishing would require a small change to the core to allow logged in users to view unpublished pages and also special menus that would show unpublished pages for people who are logged in. I have this working on one of my sites now but it’s an old hacked version. I also think it would be good to have the Menu Index/Hide available.

perhaps in a pop-up window but better in a menu bar at the top of a page (basic users can get frustrated when they click the parent window and lose the pop-up).

Acutally the way that the editor windows work now they are always on top in gecko browsers (unfortunately it doesn’t seem to work in IE)

Moving pages would probably require a pop-up to show the page tree, but perhaps there would be other ways.

I’m curious to see how the tree is implemented in the new manager interface. Hopefully it will be easy to implement in the frontend. Another option (which might actually be better) would be a sort of a cut and paste functionality. A person could go to a page and click a "Pick Up" which would register a simple session variable, then navigate to the destination through any means and then click the "Put Here" button.

Among my end users, some see the manager as pretty intimidating and non-intuitive, even with only basic editing privileges. These are the sorts of users who will never put in a chunk, snippet or TV--they can’t begin to understand them. They just want to put in text and images. It might be just the ticket to be able to keep such users away from the manager interface altogether, and could be a feature to really set Modx apart.

Same here. I work for a college and we’ve been using a different form of frontend editing for a while now. We had to take features out of HTMLArea and hide a lot of the features in the document edit page just to make it seem simpler to use. If I tried to dump them right into the typical manager there’d be mass panic!

I hope to get around to these in the future but I’ll probably wait until it’s been released in the next Technology Preview so that we can get some good testing of the basic functionality before I try to get too fancy. Recently I’ve been been working mostly on the backend code and I will probably keep working on it. I want to make sure I have a solid foundation to build on before I start "adding floors."

Thanks for your good input. If you want to work on adding any of this functionality please feel free. I don’t want to have a "my code" attitude about this, I’ve seen that exact attitude wreak havoc on other open source projects.

I am continually amazed by both the skill and the selfless attitudes of the great contributors to this project. I don’t think I’m overstating to say that this is open source at its best. Thanks again, Adam.

I finally did get the snippet unzipped, thanks--I guess for some reason my zip utility didn’t like it.

Input types for template variables. Of course. Silly me.

Concerning contentEditable, I haven’t had any complaints when I restrict clients to a particular browser for content editing. It seems worth having as an available module anyway.

Another option (which might actually be better) would be a sort of a cut and paste functionality. A person could go to a page and click a "Pick Up" which would register a simple session variable, then navigate to the destination through any means and then click the "Put Here" button.

That’s something I had in mind, but then you still have to deal with menu ordering. But this is something that needs improvement anyway--get away from the manually inputted numerical index.

I hope to get around to these in the future but I’ll probably wait until it’s been released in the next Technology Preview so that we can get some good testing of the basic functionality before I try to get too fancy.

Yeah, take a break. You’ve earned it!