Do not like the new Code and Quote in 3.4

[Schot]

Here is the same text, but this time use the light switch first to paste it and quote it then switch back. Please know that in 3.3 it doesn't required me to do this and the text still align correctly.

After that, I have to hit Light Switch again to start a new line of my text and to get out of the Quote box area.

And now I need to code my text, I hit the light switch again to code. Then when I edit my post because I want to add more Text in my Box I need to hit the light switch again because I can't put anything in my code box without doing so. Hitting return without in Light Switch mode will make text go outside the code box.

This switch back and fourth is time consuimg, not user friendly and take too much work. I like it much better in 3.3 where I can just type everything in one go.

Example sentence links
Example Sentence links
Example Sentence links

Yup, definitely problems.

1. Quote above didn't capture quote within quote.
2. If I try to copy the user name from the quote title I can't. If I try to highlight just the name from the author line, the whole line will be highlighted or the whole quote. Can't highlight just the author name. I often do this when writing responses to long complicated user names. Interestingly... This is not a problem after posting. It's only a problem while the quote is within an editor. There seems to be a problem with the quote box graphic only while in rte. A bit of graphic duplication in the upper left corner. Possibly something to do with not being able to control what is highlighted within that line.
3. If I accidentally break the quote box, pasting a copy of the copy from clipboard does not correct the mistake. Simply pastes the unformatted text.
4. when first quoting someone it appears as though my cursor is trapped within the quote box. Pushing enter at the bottom inside of the quote escapes my cursor below. It's an odd disorienting behaviour that makes me feel the need to switch off rte to resolve the problem initially.
5. Tailoring a quote can be problematic. Double-click highlighting the first line in a quote can break the quote format. Happened twice while creating this post.

I run the tech side of my forum and don't post often but every since the upgrade I have been finding myself "switching" frequently. Never ever used to turn the rte on and off before. Now I think it's become a requirement to switch at least once per post it seems. Bit of a nuisance. If I was a frequent poster... Probably be a bit of a lot of nuisance.

[Marcher Technologies]

Setting aside your overly hostile tone for a moment - all of those things might affect how the data is SAVED, but changing how HTML is handled in CKEditor should not affect how it DISPLAYS.

What I am saying is, if you submitted content in 3.3, you upgrade to 3.4.2 and that content is suddenly not displaying correctly, I would urge a client to submit a ticket so we can find out why and fix the problem. That seems a much better solution, both short term and long term, than editing hundreds of saved entries after an upgrade because they display differently than prior to the upgrade.

not meaning to being hostile, the prospect of losing a solid repeat client(he's eyeballing wordpress at this moment) to something beyond my control is not sitting well with me.

The problem is that it was saved as bbcode mixed with html in an html-allowed CKE field.

bbcode, and indeed, autoparsing media url's(yet another item changed for consistency with the forums, and is the summary content of the field for EVERY record) no longer works in an HTML CKE field, and that is 'working as intended'.... he did submit a ticket, it got him nowhere.

As it stands, I ended up writing a script to convert the data to another field type suitable to salvage the site, if he decides to even use it, I would not blame him at all at this point for using something more stable and less fickle with how the editor functions between versions.

And he *did* submit a ticket, there is no lack of trying to get help, a bug report was created as a result even, which then summarily was 'Not a Bug'.

Excuse my frustration please, but frankly, the editor HTML mode changes have been so radical between the versions I'm surprised that this is not a more common occurrence.

[mat206]

Setting aside your overly hostile tone for a moment - all of those things might affect how the data is SAVED, but changing how HTML is handled in CKEditor should not affect how it DISPLAYS.

What I am saying is, if you submitted content in 3.3, you upgrade to 3.4.2 and that content is suddenly not displaying correctly, I would urge a client to submit a ticket so we can find out why and fix the problem. That seems a much better solution, both short term and long term, than editing hundreds of saved entries after an upgrade because they display differently than prior to the upgrade.

Heh.. we've had to modify hundreds of articles many times over thanks to the editor. We've literally almost cried in frustration because of the lack of consistency between edited articles. It's been absolutely horrible, but almost useless to complain about.

We have FINALLY taken steps to cut out ckeditor by making our own editor for at least IP.Content.. though I wish I could replace IP.CKEditor everywhere.

[MisterPhilip]

We have FINALLY taken steps to cut out ckeditor by making our own editor for at least IP.Content.. though I wish I could replace IP.CKEditor everywhere.

:drool: I need to catch up with you and find out more!

[bfarber]

not meaning to being hostile, the prospect of losing a solid repeat client(he's eyeballing wordpress at this moment) to something beyond my control is not sitting well with me.

The problem is that it was saved as bbcode mixed with html in an html-allowed CKE field.

bbcode, and indeed, autoparsing media url's(yet another item changed for consistency with the forums, and is the summary content of the field for EVERY record) no longer works in an HTML CKE field, and that is 'working as intended'.... he did submit a ticket, it got him nowhere.

As it stands, I ended up writing a script to convert the data to another field type suitable to salvage the site, if he decides to even use it, I would not blame him at all at this point for using something more stable and less fickle with how the editor functions between versions.

And he *did* submit a ticket, there is no lack of trying to get help, a bug report was created as a result even, which then summarily was 'Not a Bug'.

Excuse my frustration please, but frankly, the editor HTML mode changes have been so radical between the versions I'm surprised that this is not a more common occurrence.

As more information becomes available it starts to make more sense, and is why I suggested submitting a ticket in the first place.

In 3.4.1 we passed HTML through the parser and was told (you were one of the people in fact :) ) that the parser should NEVER change the content if you are submitting as HTML. If you are submitting a raw HTML post (or article) then it is not up to the parser to guess what you mean, change tags, parse links, etc. So we did that. And now I'm hearing that it...should? Because it did in a previous version?

This is a situation we run in to sometimes. We made changes in IP.Board based on very very direct feedback - do not run HTML content through the parser. So we changed it, based on feedback. I'm not sure how that could be rectified? Either we run HTML content through the parser (which is what auto-links media tags) or we don't. Personally I agree with the feedback that we shouldn't, however we're of course open to discussion on the best way to handle this.

[Marcher Technologies]

As more information becomes available it starts to make more sense, and is why I suggested submitting a ticket in the first place.

In 3.4.1 we passed HTML through the parser and was told (you were one of the people in fact :smile: ) that the parser should NEVER change the content if you are submitting as HTML. If you are submitting a raw HTML post (or article) then it is not up to the parser to guess what you mean, change tags, parse links, etc. So we did that. And now I'm hearing that it...should? Because it did in a previous version?

This is a situation we run in to sometimes. We made changes in IP.Board based on very very direct feedback - do not run HTML content through the parser. So we changed it, based on feedback. I'm not sure how that could be rectified? Either we run HTML content through the parser (which is what auto-links media tags) or we don't. Personally I agree with the feedback that we shouldn't, however we're of course open to discussion on the best way to handle this.

when the user states in a system setting that they want media tags parsed automatically......... it is beyond confusing that HTML mode completely ignores such configurations.

It is also annoying that no mention of such a change was ever made...... backwards compatibility is the most important thing. as you yourself said, there is no reason the user should ever have to edit their content to fix what was once valid.

[bfarber]

when the user states in a system setting that they want media tags parsed automatically......... it is beyond confusing that HTML mode completely ignores such configurations.

It is also annoying that no mention of such a change was ever made...... backwards compatibility is the most important thing. as you yourself said, there is no reason the user should ever have to edit their content to fix what was once valid.

Stop for a minute and be clear. Are you now saying that we SHOULD be running HTML content through some sort of parsing routines?

[mat206]

I typed out both of your examples:



Yes, on save, they do turn into the other format you mentioned but that is what is supposed to happen as that is how it needs to be formatted on the back end.

I think the fact that you changed the original post is the problem. If you want to translate it to some intermediate version prior to display, then do it and store the intermediate version.. but don't mess with the original like that. What happens is that flaws in your parser routines, display routines, etc. have already mangled the original post.. and it's too late to fix it. Store the original and you don't have that problem.