WordPress.org

1. davidosullivan
   Member
   Posted 1 year ago #
   

   Hi there,

   Sorry for bombarding you with questions today!

   Two last things:

   1) Is there an event I can bind to when FEE activates so I can attach some of my own functions to elements that are being edited? Reason being that I'd like to show a 'Save' and 'Cancel' button in place of the 'Edit' button when the editor is active- amongst other things...

   2) Is there a method I can call that will temporarily hide the editor? I have tried FrontEndEditor.hide() as a guess but that's no good.

   Hope you can help ;)

   http://wordpress.org/extend/plugins/front-end-editor/

2. davidosullivan
   Member
   Posted 1 year ago #
   

   Ok well thats one thing off the list...

   You can use

   jQuery(document).bind("edit_start", function(){
   alert('we started editing!');
   }),

   To attach functions to when the editor starts and the same but with 'edit_stop' to do stuff when the editor ends...

   Am still looking for a method to temporarily hide the editor...

3. davidosullivan
   Member
   Posted 1 year ago #
   

   Actually my idea in the previous post was no good as when that fires the actual .fee-form does not exist so I need something that triggers when the form is actually ready to edit...:(

4. scribu
   Member
   Plugin Author
   Posted 1 year ago #
   

   2) Is there a method I can call that will temporarily hide the editor?

   There isn't.

   1) Is there an event I can bind to when FEE activates so I can attach some of my own functions to elements that are being edited?

   There is no event specifically for that.

   Reason being that I'd like to show a 'Save' and 'Cancel' button in place of the 'Edit' button when the editor is active- amongst other things...

   That would mean that you would also have to hide the default Save and Cancel button sets (one set built into Aloha and another set for the others). Why would you need to do that?

5. davidosullivan
   Member
   Posted 1 year ago #
   

   Basically its because I think that the user may well expect to see save/cancel buttons in the same place as they saw the 'edit' button- specifically if you have for example inserted an image and the save cancel buttons are not visible in that 'insert' tab. Also if you have large images at the top of your post quite often the editor goes off screen untill you click on text below- in which case you cant see what to do to get out of the mode. If there were save/cancel buttons following you down the post this would all be obvious to the user.

   The way I was planning on doing it to avoid the problem you mention is to clone the buttons from the editor (which should also carry over their functionality) and insert them into the edit button itself and give that button a different class at the same time which would make them show correctly.

   Thats why I need to bind to the stage ready event or something so that I know when the editor and its buttons and the fee-form are all ready to go...

   Really hope this is something you have some ideas about as I really think it will have big usability benefits...

6. scribu
   Member
   Plugin Author
   Posted 1 year ago #
   

   Actually, now that you've mentioned it, I think that's how the Save/Cancel buttons should work out of the box:

   https://github.com/scribu/wp-front-end-editor/issues/66

   Are you familiar with CoffeeScript? :-)

   https://github.com/scribu/wp-front-end-editor/wiki/Development-guide

7. davidosullivan
   Member
   Posted 1 year ago #
   

   CoffeeScript- I am afraid not... I will look into it though, whats it for/do?

8. scribu
   Member
   Plugin Author
   Posted 1 year ago #
   

   CoffeeScript is a way of writing better JavaScript.

   I actually use Coco, a CoffeeScript dialect, in Front-end Editor but I'll probably switch back to plain CoffeeScript, since it's a little better known.

9. davidosullivan
   Member
   Posted 1 year ago #
   

   Hmm, had a look at CoffeeScript. I think it would be a good idea for me to learn it but just don't think I can right now... I take it that you'd like me to have a go at writing the changes in Coffee script so you can compile them into the output your end is that right?

   I think it should be a pretty straight forward change though actually- couldn't we just include the buttons in the markup and hide them- then show them on start_editing (maybe with a little timeout unless we can make them show when the fee-form is loaded) and bind a click function that triggers a click on the aloha buttons?

10. scribu
    Member
    Plugin Author
    Posted 1 year ago #
    

    Yeah, it shouldn't be too hard. My only concern is this: what happens if there isn't enough room on the left side of the element to display the buttons?

11. scribu
    Member
    Plugin Author
    Posted 1 year ago #
    

    Did a first pass at this. You can try it out by downloading the development version (2.3-alpha).

    The buttons currently have no CSS of their own.

12. davidosullivan
    Member
    Posted 1 year ago #
    

    Yep that all seems to work great ;)

    Still got issues with text aligning btw

13. scribu
    Member
    Plugin Author
    Posted 1 year ago #
    

    Still got issues with text aligning btw

    If it's not related to the Save/Cancel buttons, please open a new topic, with a screenshot attached.

14. davidosullivan
    Member
    Posted 1 year ago #
    

    Also am having issues with jQuery UI draggable in this new version with the save/cancel buttons- I am not sure if this is down to those changes or the new version of Aloha...

    What I am doing is making images editable in various ways when the editor is in editing mode. One of the things I do is initialise draggable on click on the image which enables the image to be able to be dragged around inside its own container.

    This was working in FEE 2.2 but in this new version the drag is not working. If I bind an alert to the dragstart event on the image that shows up- but the actual jQuery ui 'drag' event seems to be being blocked.

    Any idea why that may be?

15. scribu
    Member
    Plugin Author
    Posted 1 year ago #
    

    In the new version, there are 'mouseover', 'mouseout' and 'mousemove' listeners on the form too, not just on the element before it's edited.

    Your best bet is to follow the execution step by step using a breakpoint in Firebug or Chrome Console.

16. davidosullivan
    Member
    Posted 1 year ago #
    

    Do you disable these listeners when the mouse is over the floating editor controls? The save and cancel buttons hide themselves when the mouse is over the editor controls... I'd like to replicate that when the mouse is over one of my active images- or perhaps when my 'edit image' button has been clicked...

    I can see now that this is because the mouse is not over the form when it is over the editor- so it constitutes a mouseout and so the buttons get hidden...

17. scribu
    Member
    Plugin Author
    Posted 1 year ago #
    

    I don't have to, since the listeners are only bound to the editable element. Here's the relevant code:

    https://github.com/scribu/wp-front-end-editor/blob/76049ae54844ff6834dc1b3d08f4e9171e423d8b/coffee/hover.coffee#L20-46

18. davidosullivan
    Member
    Posted 1 year ago #
    

    I have tracked it down to being something to do with the block plugin in the new aloha build actually- at lib/aloha-editor/plugins/common/block- if I use the block plugin from fee 2.2 jQ UI draggable works again... Will look into it more, but its off topic now...

19. scribu
    Member
    Plugin Author
    Posted 1 year ago #
    

    You should let the Aloha devs know about it: https://github.com/alohaeditor/Aloha-Editor/issues

20. davidosullivan
    Member
    Posted 1 year ago #
    

    Solved this by adding class 'aloha-block' to the element I wanted draggable ;)

21. davidosullivan
    Member
    Posted 1 year ago #
    

    I think its deliberate looking at the notes in blockmanager.js... I'll be digging into the block plugin alot over the next couple of days

    So yeah I think what you have done with the editor buttons in 2.3 works a treat :)

    Going back to the original subject of the thread though since there are still some more things I need to do to the form once it is loaded, is it possible to have an 'edit_ready' trigger to bind to?

    I can bind to "edit_start":-
    jQuery(document).bind("edit_start", function(){
    //do whatever
    })
    It would be really great if I could bind to something that triggered when the content has been retrieved from ajax and added into the form:-
    jQuery(document).bind("edit_ready", function(){
    //do whatever
    })
    Any chance of that?

22. scribu
    Member
    Plugin Author
    Posted 1 year ago #
    

    Here you go: https://github.com/scribu/wp-front-end-editor/commit/54d602d168f65477c9e2366f38a9021b206d6815

    Available in the development version (2.3-alpha2).

Topic Closed

This topic has been closed to new replies.