[Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

Geoff - Enmore Services

Hi – I’ve just set up a Tiki17 site which now has the beta version, but I’m noticing that ckeditor seems to be set up differently to how it is in Tiki16.2

 

In Tiki17.0beta when you open the editor I’m seeing that an iframe is being used but the head section for this iframe does not include the stylesheet for the site theme so the edit screen uses the contents.css from the vendor folder which obviously means it is not exactly wysiwyg !

 

Was this intended??

 

If so, could the correct stylesheet be applied in some way?

 

Thanks

 

geoff

 


Virus-free. www.avg.com

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

Jonny Bradley-4

Yup, noticed that too - also the wiki table editor gets messed up now - probably worth filing a bug/wish as i'm snowed...

jb



> On 5 Jun 2017, at 13:17, Geoff - Enmore Services <[hidden email]> wrote:
>
> Hi – I’ve just set up a Tiki17 site which now has the beta version, but I’m noticing that ckeditor seems to be set up differently to how it is in Tiki16.2
>  
> In Tiki17.0beta when you open the editor I’m seeing that an iframe is being used but the head section for this iframe does not include the stylesheet for the site theme so the edit screen uses the contents.css from the vendor folder which obviously means it is not exactly wysiwyg !
>  
> Was this intended??
>  
> If so, could the correct stylesheet be applied in some way?
>  
> Thanks
>  
> geoff
>  
>
> Virus-free. www.avg.com
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

Jonny Bradley-4
Hi Geoff and all WYSIWYG fans! :)

That (iframe vs divarea fix) should now be fixed in http://sourceforge.net/p/tikiwiki/code/62989 - note you'll need to clear pref caches to see it.

I added it to this pref instead of hard-wiring it on so people can override it locally if necessary - seemed cleaner than a code hack.

Also, i updated the base tiki less file to fix the always white background (and recompiled all css), and then added a workaround for darkroom weirdness in subsequent commits (in 17.x) - was this the right way to do it Gary? Some other themes will need similar treatment (and maybe variables adding for 18.x?)

Happy typing! :D

jonny




> On 7 Jun 2017, at 12:14, Jonny Bradley <[hidden email]> wrote:
>
>
> Yup, noticed that too - also the wiki table editor gets messed up now - probably worth filing a bug/wish as i'm snowed...
>
> jb
>
>
>
>> On 5 Jun 2017, at 13:17, Geoff - Enmore Services <[hidden email]> wrote:
>>
>> Hi – I’ve just set up a Tiki17 site which now has the beta version, but I’m noticing that ckeditor seems to be set up differently to how it is in Tiki16.2
>>
>> In Tiki17.0beta when you open the editor I’m seeing that an iframe is being used but the head section for this iframe does not include the stylesheet for the site theme so the edit screen uses the contents.css from the vendor folder which obviously means it is not exactly wysiwyg !
>>
>> Was this intended??
>>
>> If so, could the correct stylesheet be applied in some way?
>>
>> Thanks
>>
>> geoff
>>
>>
>> Virus-free. www.avg.com
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

Bernard Sfez-3
The "ms-word type" users thank you J ! :)


On 13 Jun 2017, at 15:01 , Jonny Bradley <[hidden email]> wrote:

Hi Geoff and all WYSIWYG fans! :)

That (iframe vs divarea fix) should now be fixed in http://sourceforge.net/p/tikiwiki/code/62989 - note you'll need to clear pref caches to see it.

I added it to this pref instead of hard-wiring it on so people can override it locally if necessary - seemed cleaner than a code hack.

Also, i updated the base tiki less file to fix the always white background (and recompiled all css), and then added a workaround for darkroom weirdness in subsequent commits (in 17.x) - was this the right way to do it Gary? Some other themes will need similar treatment (and maybe variables adding for 18.x?)

Happy typing! :D

jonny




On 7 Jun 2017, at 12:14, Jonny Bradley <[hidden email]> wrote:


Yup, noticed that too - also the wiki table editor gets messed up now - probably worth filing a bug/wish as i'm snowed...

jb



On 5 Jun 2017, at 13:17, Geoff - Enmore Services <[hidden email]> wrote:

Hi – I’ve just set up a Tiki17 site which now has the beta version, but I’m noticing that ckeditor seems to be set up differently to how it is in Tiki16.2

In Tiki17.0beta when you open the editor I’m seeing that an iframe is being used but the head section for this iframe does not include the stylesheet for the site theme so the edit screen uses the contents.css from the vendor folder which obviously means it is not exactly wysiwyg !

Was this intended??

If so, could the correct stylesheet be applied in some way?

Thanks

geoff


Virus-free. www.avg.com
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Bernard Sfez | bsfez.com


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

Gary Cunningham-Lee
In reply to this post by Jonny Bradley-4
Hi,

There's a page about this here -
https://themes.tiki.org/Enabling+themes+to+provide+values - but it
probably needs flow charts and a Tour or something.

The deal with these cases is a bit convoluted-sounding, but the general
pattern has been, if there's a CSS color rule (or similar) that a theme
should be able to define, then the rule should be in tiki-selectors.less
where a Less variable is used rather than a color value, and then a
default definition is put in tiki-variables.less; then tiki_base.css
gets compiled from these.

The themes import tiki-selectors.less and can have their own variable
definition for this and other rules.

So according to this, the color values you put in tiki-selectors.less
should actually be variables, like:

.cke_wysiwyg_frame,
.cke_wysiwyg_div {
     background: @cke_wysiwyg_bg;
     color: @cke_wysiwyg_color; }

and then rules should be added to tiki-variables.less like

@cke_wysiwyg_bg: #474747;
@cke_wysiwyg_color: #d8d8d8; /* default values (tiki_base.css) */

Since a theme like Darkroom needs its own rules, it imports
tiki-selectors and uses its own definitions of the variables when its
stylesheet is compiled.

This way there also there should be no need for the added specificity in
the selector to override the default values. The default values are in
tiki_base.css, but the theme stylesheet loads later so should override
where necessary.

Does this make sense? I can make the changes and do the commit for this.

By the way, I've often appended ".tiki" to the selector to give it more
specificity, to override another rule, rather than using "!important".
I'd suggest doing that here also.

-- Gary


On 6/13/2017 9:01 PM, Jonny Bradley wrote:

> Hi Geoff and all WYSIWYG fans! :)
>
> That (iframe vs divarea fix) should now be fixed in http://sourceforge.net/p/tikiwiki/code/62989 - note you'll need to clear pref caches to see it.
>
> I added it to this pref instead of hard-wiring it on so people can override it locally if necessary - seemed cleaner than a code hack.
>
> Also, i updated the base tiki less file to fix the always white background (and recompiled all css), and then added a workaround for darkroom weirdness in subsequent commits (in 17.x) - was this the right way to do it Gary? Some other themes will need similar treatment (and maybe variables adding for 18.x?)
>
> Happy typing! :D
>
> jonny
>
>
>
>
>> On 7 Jun 2017, at 12:14, Jonny Bradley <[hidden email]> wrote:
>>
>>
>> Yup, noticed that too - also the wiki table editor gets messed up now - probably worth filing a bug/wish as i'm snowed...
>>
>> jb
>>
>>
>>
>>> On 5 Jun 2017, at 13:17, Geoff - Enmore Services <[hidden email]> wrote:
>>>
>>> Hi – I’ve just set up a Tiki17 site which now has the beta version, but I’m noticing that ckeditor seems to be set up differently to how it is in Tiki16.2
>>>
>>> In Tiki17.0beta when you open the editor I’m seeing that an iframe is being used but the head section for this iframe does not include the stylesheet for the site theme so the edit screen uses the contents.css from the vendor folder which obviously means it is not exactly wysiwyg !
>>>
>>> Was this intended??
>>>
>>> If so, could the correct stylesheet be applied in some way?
>>>
>>> Thanks
>>>
>>> geoff
>>>
>>>
>>> Virus-free. www.avg.com
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
>>> TikiWiki-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

Gary Cunningham-Lee
Sorry, I made a couple of edits.

On 6/15/2017 12:37 AM, Gary Cunningham-Lee wrote:

> Hi,
>
> There's a page about this here -
> https://themes.tiki.org/Enabling+themes+to+provide+values - but it
> probably needs flow charts and a Tour or something.
>
> The deal with these cases is a bit convoluted-sounding, but the general
> pattern has been, if there's a CSS color rule (or similar) that a theme
> should be able to define, then the rule should be in tiki-selectors.less
> where a Less variable is used rather than a color value, and then a
> default definition is put in tiki-variables.less; then tiki_base.css
> gets compiled from these.
>
> The themes import tiki-selectors.less and can have their own variable
> definition for this and other rules.
>
> So according to this, the color values you put in tiki-selectors.less
> should actually be variables, like:
>
> .cke_wysiwyg_frame,
> .cke_wysiwyg_div {
>      background: @cke_wysiwyg_bg;
>      color: @cke_wysiwyg_color; }
>
> and then rules should be added to tiki-variables.less like
>
> @cke_wysiwyg_bg: #474747;
> @cke_wysiwyg_color: #d8d8d8; /* default values (tiki_base.css) */

Or, better,

@cke_wysiwyg_bg: @body-bg;
@cke_wysiwyg_color: @text-color;

(define in terms of existing variable if appropriate)

> ....
>
> By the way, I've often appended ".tiki" to the selector to give it more
> specificity, to override another rule, rather than using "!important".
> I'd suggest doing that here also.

I meant to say I've often prepended the selector with ".tiki".

-- Gary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

Jonny Bradley-4

Thanks Gary, that all sounds sensible. By the way, the thing i was overriding was already !important (i think) so needed that, and and extra selector to override the override (just using .tiki would be better).

Thanks, if it sort of works ok for 17.0 let's leave it as it is and fix it better later?

jonny



> On 14 Jun 2017, at 16:47, Gary Cunningham-Lee <[hidden email]> wrote:
>
> Sorry, I made a couple of edits.
>
> On 6/15/2017 12:37 AM, Gary Cunningham-Lee wrote:
>
>> Hi,
>> There's a page about this here - https://themes.tiki.org/Enabling+themes+to+provide+values - but it probably needs flow charts and a Tour or something.
>> The deal with these cases is a bit convoluted-sounding, but the general pattern has been, if there's a CSS color rule (or similar) that a theme should be able to define, then the rule should be in tiki-selectors.less where a Less variable is used rather than a color value, and then a default definition is put in tiki-variables.less; then tiki_base.css gets compiled from these.
>> The themes import tiki-selectors.less and can have their own variable definition for this and other rules.
>> So according to this, the color values you put in tiki-selectors.less should actually be variables, like:
>> .cke_wysiwyg_frame,
>> .cke_wysiwyg_div {
>>     background: @cke_wysiwyg_bg;
>>     color: @cke_wysiwyg_color; }
>> and then rules should be added to tiki-variables.less like
>> @cke_wysiwyg_bg: #474747;
>> @cke_wysiwyg_color: #d8d8d8; /* default values (tiki_base.css) */
>
> Or, better,
>
> @cke_wysiwyg_bg: @body-bg;
> @cke_wysiwyg_color: @text-color;
>
> (define in terms of existing variable if appropriate)
>
>> ....
>> By the way, I've often appended ".tiki" to the selector to give it more specificity, to override another rule, rather than using "!important". I'd suggest doing that here also.
>
> I meant to say I've often prepended the selector with ".tiki".
>
> -- Gary
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Tiki-devel] change in ckeditor behaviour from Tiki16 to Tiki17 ?

Gary Cunningham-Lee
You're welcome, and it's ok with me to leave further changes on this
until after the release.

-- Gary

On 6/15/2017 12:51 AM, Jonny Bradley wrote:

>
> Thanks Gary, that all sounds sensible. By the way, the thing i was overriding was already !important (i think) so needed that, and and extra selector to override the override (just using .tiki would be better).
>
> Thanks, if it sort of works ok for 17.0 let's leave it as it is and fix it better later?
>
> jonny
>
>
>
>> On 14 Jun 2017, at 16:47, Gary Cunningham-Lee <[hidden email]> wrote:
>>
>> Sorry, I made a couple of edits.
>>
>> On 6/15/2017 12:37 AM, Gary Cunningham-Lee wrote:
>>
>>> Hi,
>>> There's a page about this here - https://themes.tiki.org/Enabling+themes+to+provide+values - but it probably needs flow charts and a Tour or something.
>>> The deal with these cases is a bit convoluted-sounding, but the general pattern has been, if there's a CSS color rule (or similar) that a theme should be able to define, then the rule should be in tiki-selectors.less where a Less variable is used rather than a color value, and then a default definition is put in tiki-variables.less; then tiki_base.css gets compiled from these.
>>> The themes import tiki-selectors.less and can have their own variable definition for this and other rules.
>>> So according to this, the color values you put in tiki-selectors.less should actually be variables, like:
>>> .cke_wysiwyg_frame,
>>> .cke_wysiwyg_div {
>>>      background: @cke_wysiwyg_bg;
>>>      color: @cke_wysiwyg_color; }
>>> and then rules should be added to tiki-variables.less like
>>> @cke_wysiwyg_bg: #474747;
>>> @cke_wysiwyg_color: #d8d8d8; /* default values (tiki_base.css) */
>>
>> Or, better,
>>
>> @cke_wysiwyg_bg: @body-bg;
>> @cke_wysiwyg_color: @text-color;
>>
>> (define in terms of existing variable if appropriate)
>>
>>> ....
>>> By the way, I've often appended ".tiki" to the selector to give it more specificity, to override another rule, rather than using "!important". I'd suggest doing that here also.
>>
>> I meant to say I've often prepended the selector with ".tiki".
>>
>> -- Gary
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> TikiWiki-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> TikiWiki-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
TikiWiki-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel