Make the wiki syntax optional

Iam sorry again, but this wont be included. 1.x to 2.x was the switch from html to this markup. This introudced some very important things. I will not maintain to patchs just because of peoples likes / dont likes - there are many reasons of using markup if you are in touch with WYSIWYG and esp. the current WYSIWYG api.

What you want is not wanted here at all - mixing up to different systems for maintaining an entity while not knowing eachother. The integration level of wysiwyg_imageupload with lightbox support, submodules support for meta data imagecache support etc. is not able to be handled if you use several modules at the same time.

I see your point - and there is value in it but still this is huge work and a lot of double effort to maintain both branches.

i actually would not care using html before markup. But you WILL run into serious issues witht eh WYSIWYG api due to the missing api for modifing selections. You will never be able to use cataptions or any themeing or extensive metadata. You will also have a _lot_ troubles making the ahah forms working on all systems due to all those get argument passint.

so no, its not a taste question of all. I dont like wiki-markup at all. And thats why [[]] is not wiki at all, it is mean as a macro here. "replace me by my represenation". Thats not done because wiki`s do like this, thats done because there is no way arround rendering the image for different purposes ( node view and wysiwyg ).

You will waste a lot of time and run into a dead-end finally (like i did). I did not stop the html-markup out of any reason, i mean you have to consider i had it working and removed it. It had several reasons, absolutely none of those was "wiki markup" related.

I can tell you, maintaining this module needs 100% of my knowhow about like anything and needs a lot of maintaining. I would not advice to try to double this work, rather help here improving. This is a extremly time-eating module, thats fore sure :)

Consider to ask TwoD about what iam about with "no api to modify selections" and what that means for the entities being selected by wysiwyg (and what that means for "editing images" ig they are e.g. rendered surrounded by a diff or any markup like a cation, link or lightbox representation.)

I think iam already pushin WYSIWYG api to its limit and i have exchanged myself about the limits talking to TwoD.

what kind of features do you miss in wysiwyg_imageupload you have in that image editing tool?
What image editing tool are you using?
did you look at the submodule archtecture? You can add any new options to the image dialog. E.g. borders, distance, alt, description or even tagging. It is all possible now, just have a look at the lightbox2 submodule.

Before you for, let me know. If you want to maintain the 1.x branch, iam happy to invice doing it here. that way we can coordinate and dont confuse people.

I am using ckeditor with wysiwyg_imageupload. ckeditor has an 'image' button that allows you to view the image path and add styles to the img tag, including border, hspace, vspace, alt and so on. With the current wysiwyg_imageupload 2.x build, if you use these controls, they will adjust the image inside the ckeditor view; however, if you save and then re-edit the node, these attributes are thrown away, because they are not persisted in the [[]] syntax tags. I could disable this button and replace it with other tools that were more compatible with wysiwyg_imageupload, if any existed, or even switch to a different editor if there is one that works better than ckeditor. As for lightbox2, I did have that installed on my site in the past, but it is not enabled at the moment. It's not a big feature for me. What is important is for users to be able to insert and format basic pictures in their nodes.

Thank you for the offer to maintain the 1.x branch. If I ever have any patches to 1.10, I will submit an issue and request this status at that time.

I see; in #7, I thought you were talking about the lightbox2 project, but now I understand that you meant the modules/wysiwyg_imageupload_lightbox in wysiwyg_imageupload. I'll take a look at it.

In a way, it is a little dissatisfying to have to re-implement ckeditor features. With the <> syntax, you would inherit any sort of img tool that any of your editors provided. However, since the ajax editors themselves are limited to features that can be represented in html, perhaps this situation isn't intractable, and it might just be better to "recode our way out" than to go back and fix design mistakes of whatever origin.

The wysiwyg + wysiwyg_imageupload + ajax editor combination certainly opens up some possibilities that just cannot be done in isolation. For example, I can imagine a wysiwyg_imageupload submodule that added a "crop" attribute to an image. That attribute could be quite easily supported with a slight addition to the image resize filter module; the result would be quite useful.

I'll look at the APIs and examples you suggest, and see what can be done. I'll stick with wysiwyg_imageupload 6.x-1.10 until things can be fixed up. Thank you for your support.

@greg: I think you finally got the point. you will stumble uppon much more thinks which are possible now. And imagecropping is even already requested. As the dialog is bootstrapping drupal by default, you can simply add imagecropping - no hacking needed. use the form_api :)

@thatOn3guy: I think that sounds good. WUI will have a lot more of those submodules in the future, the architecture just got introduced. I dont want all those code in the core module so people can activate what they like and keep "other possibly buggy code out"

Iam willing to help here, with tips and implementations but i wont do all the work. If you guys stick heads together and need help - be sure i will provide it.

Those are fair comments. I'm willing to help out here to make things better, but have too many commitments to start anything in the short term. I'll watch the release notes and issue queue, and post any new feature patches that I eventually make on separate issues.

Let's keep this issue about wiki-format vs html format, and I will return here if in my investigations I have any more comments on that subject. I have also encouraged TwoD to weigh in here, if he has a chance.

Wow, great discussion here! I don't have time to read through all this now but it's at the very top of my To-do stack.

I''ve just come back from my - as always, too short ;) - vacation and I've decided to start putting down as much as I can of what's been learned, through discussions and modules like this one, into actual code for everyone to test.

It has been stated before that we'll put all new features into Wysiwyg 3.x [D7] (direct selection handling via Wysiwyg's API could be one of them) and I'll stick to that. I'll try my best to port Wysiwyg 3.x to D6 at the same time, but I think there will have to be at least a 2.2 release before 3.x can become a candidate for 3.0. The longer 3.x is delayed, the more features (or feature-completions as I'd like to call things like getContent() methods, and possible selection handling) will get into a 2.x release. If new things can be added to the 2.x API without breaking compatibility with 2.0, it has a greater chance of getting in before 3.x)

Obvious bugs - like data.node not containing what's expected - will be fixed in all relevant branches at the same time, and I will not consider fixing something like that to be a major backwards compatibility issue (not many modules rely on it anyway) .

Yes, this reply is a bit vague, but I'll be able to give more precise answers as code gets written. I just want you to know I've not forgotten about this issue and I know it's something the community really wants and all new code getting into the module will aim to eventually fix it.

For now, using wysiwyg_imageupload-6.x-1.10 is an acceptable workaround for me in the 6.x timeframe; Eugene has also provided some good help at #869640: Remove internal CKEditr image editor dialog from CKeditor which might eventually get me up to the 1.2 branch, once I have time to work through it. I think that focusing on a solution in the D7 branch first is best; I'd like to switch my sites to D7 as soon as there are enough modules available to make that feasible, so it's good to avoid side tasks that slow down progress on that track.

Thanks for the help and all of the hard work. I'll try to pitch in as I can as things start to come together.

I guess that one is already decided.