Custom WYSIWYG Buttons

Discussion corner for Developers of Serendipity.
konus
Regular
Posts: 334
Joined: Mon Jun 16, 2008 1:57 pm
Location: Dresden, Germany
Contact:

Re: Custom WYSIWYG Buttons

Post by konus »

@judgebert: Sorry, I hope you didn't feel like I want to hurry you. I really appreciate all the work you and the other guys are doing here for the community.
judebert
Regular
Posts: 2478
Joined: Sat Oct 15, 2005 6:57 am
Location: Orlando, FL
Contact:

Re: Custom WYSIWYG Buttons

Post by judebert »

No, no problem. I've been meaning to jump on this, but I'm being lazy. I need to kick my ass into gear. (And stop daydreaming about other projects I'd like to kick off.)

Garvin, since the page rolled over, back up and see what you think about my radical new ideas. I think a single s9y function that outputs the appropriate textarea or WYSIWYG editor should be used. I also think that there are no situations remaining in which we use our "basic" editor Javascript.
Judebert
---
Website | Wishlist | PayPal
judebert
Regular
Posts: 2478
Joined: Sat Oct 15, 2005 6:57 am
Location: Orlando, FL
Contact:

Re: Custom WYSIWYG Buttons

Post by judebert »

I'm about to make some extensive changes to the way our editors work.

Normally we try -- we try very hard -- to keep everything backwards compatible. Sometimes this is not possible, and we try to keep any non-compatible changes separate so we can add them to a single new version.

We've even tried to accommodate backwards compatibility for unknown installations. For instance, YL recently found an event hook that wasn't being used by any of the plugins in our repository. We kept it anyway, since some custom plugins that aren't in our repository use it.

I think that's fine... as long as it's not making our jobs difficult. However, when we want a new feature, or performance improvements, or some other enhancement that will make a difference for future Serendipity developers and users, we need to consider who we're supporting.

We're giving the code away for free. We're developing on our own time, for the benefit of everyone. Supporting the shared code -- the code that benefits everyone -- should be our first priority. Improving that shared code should be our second priority. I suggest that supporting private code -- code that doesn't benefit our entire community -- should be our third priority, at best.

I'm not saying that I want to abandon anyone. I'm just saying that if you've got something proprietary, and the hook or quirk it depends on should be changed to make improvements for everyone, our best decision is to make the change that benefits the community. You may have to modify or reimplement your proprietary code.

If so, you might want to consider implementing something similar that the whole community can use: if we benefit from the quirk that keeps your proprietary code working, we're highly unlikely to change it. After all, we take our responsibility to support our (rather large) shared code base very seriously. And if we do make a change, you can see what we did to your community code and make the same modifications to your proprietary code.

With that in mind, I'm moving the editor form printout from an HTML input field to a Serendipity function/Smarty call, and I'm removing the "basic Javascript browser" functionality. The first change prevents reimplementation of code, and provides a single point for functionality improvements. The second change removes unused code and complexity (especially where editors are concerned). Both are improvements the community can use. I intend to update any community code that uses the earlier functionality.

Garvin is the project coordinator, so if he disagrees with this decision, I'll stop work and try to figure out another way. I just want to explain what I'm doing and why.
Judebert
---
Website | Wishlist | PayPal
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: Custom WYSIWYG Buttons

Post by garvinhicking »

Hi judebert,

I'm with you. Editor integration is one of the first things that we have reached some kind of "one-way dead-end".

If you see a way to make that better for the future, so be it. The only thing I want to prevent is that everything that depends on the WYSIWYG editors (or NON-WYSIWYG editors) will break.

As long as all the s9y plugins and internal templates can work after the upgrade, that's fine.

BUT we need to find a way so that new plugin versions suited for new s9y cores ALSO work for older s9y versions.

Many people might not want to upgrade to s9y 1.5 immediately, but with their 1.4 versions they must still be able to use available plugins. In the other way, a s9y 1.5 core is not required to work with an outdated plugin version - for that, we can force the user to upgrade their plugins.

Customized admin templates should IMHO be neglectible. A change like this, BTW, was always the reason why I disliked smartyfied Admin backends.

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
judebert
Regular
Posts: 2478
Joined: Sat Oct 15, 2005 6:57 am
Location: Orlando, FL
Contact:

Re: Custom WYSIWYG Buttons

Post by judebert »

I can see how someone might not want to update their core to support a plugin.

Is it okay if newer plugins do not crash, but also do not achieve their full functionality? For instance, a new plugin providing buttons for the editors would certainly not cause an error, but its buttons wouldn't necessarily be displayed, either. To achieve the full functionality of the plugin, the core would need to be at least 1.5.
Judebert
---
Website | Wishlist | PayPal
garvinhicking
Core Developer
Posts: 30022
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: Custom WYSIWYG Buttons

Post by garvinhicking »

Hi!
Is it okay if newer plugins do not crash, but also do not achieve their full functionality? For instance, a new plugin providing buttons for the editors would certainly not cause an error, but its buttons wouldn't necessarily be displayed, either. To achieve the full functionality of the plugin, the core would need to be at least 1.5.

That's fine of course; people can only expect new functionality, when they upgrade the requirements. Only the old functionality should n ot be disturbed (I'm thinking of plugins like TinyMCE or Amazonchooser, those need to also work in s9y < 1.5 versions).

Regards,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/
mgroeninger
Regular
Posts: 546
Joined: Mon Dec 20, 2004 11:57 pm
Contact:

Re: Custom WYSIWYG Buttons

Post by mgroeninger »

Hi all,
Sorry to come to the party really late. :D

Is there any change in this? I'm rewriting the Amazon Media button to work with Amazon's new api, and it would be nice to be able to add it to the wysiwyg editors.

Hope everyone is doing well,
Matt
mgroeninger
Regular
Posts: 546
Joined: Mon Dec 20, 2004 11:57 pm
Contact:

Re: Custom WYSIWYG Buttons

Post by mgroeninger »

OK, after I re-read my post I realized my question is probably wrong.

My question should probably be:
Did any of this work get added to core?

And the follow up would be:
If so, how would I use it?

If it never made it to core, is there anything I can do to work on it? I need to finish the Amazon plugin first, probably, but I might be able to look into this afterward...
Don Chambers
Regular
Posts: 3652
Joined: Mon Feb 13, 2006 2:40 am
Location: Chicago, IL, USA
Contact:

Re: Custom WYSIWYG Buttons

Post by Don Chambers »

I believe this is Judebert's baby. I know the plugin he we wanted this for has not yet been completed, but I cannot say with certainty what is in the core.... hopefully he will chime in soon!

And welcome back after a bit of an absense! :wink:
=Don=
mgroeninger
Regular
Posts: 546
Joined: Mon Dec 20, 2004 11:57 pm
Contact:

Re: Custom WYSIWYG Buttons

Post by mgroeninger »

Hi Don! Thanks for the welcome back!
Don Chambers
Regular
Posts: 3652
Joined: Mon Feb 13, 2006 2:40 am
Location: Chicago, IL, USA
Contact:

Re: Custom WYSIWYG Buttons

Post by Don Chambers »

mgroeninger wrote:Hi Don! Thanks for the welcome back!
You're welcome! Now... get back to work and give us some more of your awesome code contributions!!!!

:mrgreen: :lol: :mrgreen: :lol:
=Don=
judebert
Regular
Posts: 2478
Joined: Sat Oct 15, 2005 6:57 am
Location: Orlando, FL
Contact:

Re: Custom WYSIWYG Buttons

Post by judebert »

Unfortunately, I'm kinda stonewalled on this. It's a neat idea, but to make it work right requires changing the way Serendipity handles its textarea display, and that's built in to several plugins and the core (I hate redundant code).

Trying to make it backwards-compatible is a big difficulty, as well.

Anyway, you can add your own custom buttons to WYSIWYG editors already, I think. Just hook backend_entry_toolbar_body and backend_entry_toolbar_extended. It's not easy, but it can be done.
Judebert
---
Website | Wishlist | PayPal
Huhu
Regular
Posts: 157
Joined: Tue Oct 04, 2011 3:22 pm

Re: Custom WYSIWYG Buttons

Post by Huhu »

Just read the topic. I would like to implement some buttons that just insert blocks of code, which I have to use repeatedly throughout almost all articles (nothing fancy, just something like "<div class="x"></div>" stuff).

I somehow remember that there should be a solution (non-wysiwyg) but couldn't find it ... thanks for any help ...
Post-apocalyptic Jugger sports: What is Jugger? Video I Free ebook on the sport
Don Chambers
Regular
Posts: 3652
Joined: Mon Feb 13, 2006 2:40 am
Location: Chicago, IL, USA
Contact:

Re: Custom WYSIWYG Buttons

Post by Don Chambers »

Many themes style <code>....</code>. Or <pre>...</pre>
=Don=
onli
Regular
Posts: 2822
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: Custom WYSIWYG Buttons

Post by onli »

Post Reply