CMS Made Simple Forums

Hello all.

(edit: I might have found a fix, read fourth post of this thread)

The flickering problem has been mentioned in few threads previously, but it hasnt got as much attention as it should. It is really an annoying problem that seems to be only CMSMS specific (details below) and should be fixed.

Here are my observations of the flickering problem.

The problem:
the editor that is used for editing the contents of a page (that is, a wysiwyg editor) flickers (twinkles, blinks (I do not know the best word for this purpose in english)) when some "bigger" event are happening in editor. For example when you press enter the editor jumps up one row and then comes back (it does not, however, do this everytime). Annoying. Very.

Where is this happening?
It seems, that only Firefox (both Linux and Windows) has this problem. I've tested at least TinyMCE on Windows with IE and it did not have this problem. Even though the previous messages about this problem relate it to TinyMCE specific, it is actually happening also with HTMLArea (at least on Linux firefox). I have not tested any other browsers on Linux than Firefox (well, acutally I tested Konqueror, but it does not view the WYSIWYG editor at all... but thats another story and could be related to my settings).

What causes it?
According to my observations and some tests, this seems to be CSS specific problem and thus related to the default admin theme. How do I know this? Well.. first I did go see TinyMCE's home page and tested their demo. It does not flicker (although, they have newer version on their page). Secondly, the editor of Moodle (www.moodle.org) is based on HTMLArea and it does not flicker. Thirdly I disabled css and tested the "edit page" (editcontent.php) of CMSMS and noticed that the editor does not flicker anymore.

How to fix it?
Well.. This is my question really. I tried several things, but since I'm not very good with CSS it is very hard for me to see what could be the problem. For some reason I suspect that the hovers (how the tabs are implemented) could have something to do with this strange behaviour... I also believe that the fix is just few lines...

So, do you have any ideas. I like this CMS much, but this small detail bugs me sooooo much... and for the other users this is almost question of life and death... (and they prefer the latter)...

Jussi

Hi again.

Just to mention what I would try next, if I would be more familiar with the functionality of these tabs in the editcontent.php (and the whole editcontent.php).

I would try to remove the tabbed panes and put everything on one page. This test would clarify the situation bit more. Thus, if the flickering would be gone after this, we would be sure that the problem is related to the tabs, and vice versa of course.

I'll will try this, but I'll will take quite much time since I first need to familiarize myself with the editcontent.php bit more precisely. However, if someone is faster, please share your observations with others.

Jussi

Nice!

I think I've found the problem. It was not related to the tabs and the hover after all.. but it is css related.

So, what did I do?
I commented the line 106 from /admin/themes/default/css/style.php away. Thus the line containing:
p.pageinput { color: #384654; float: left; padding-top: 5px; }
was removed.

[edit]: It seems that only removing the float: left; away from the above is enough. Thus, the line 106 should be:
p.pageinput { color: #384654; padding-top: 5px; }
This will now preserve the paddings.

I have not tested this very much, so I do not know if it causes new problems, but at least we know now what caused the lfickering. Furthermore I have no idea why does it fix the flickering, but it does it....

It however, makes the layout on pages bit tight, since this pageinput was used in several pages (commenting it removes the paddings).

What did it fix?
It actually fixed for me two things. First, at least TinyMCE and HTMLArea do not flicker anymore!
Also with TinyMCE it locates the editor as I think the author of the template has meant. With HTMLArea it places the editor bit oddly, but still it works.

Now others. Please test if this works also on Windows with firefox and IE (and any other browsers).... I hope it does not cause any extreme problems!!

Also I would like to know why does commeting this line fix this problem...

In the /admin/themes/default/css/style.php there is a definition:
p.pageinputwysiwyg { padding-top: 5px; }
that is not used at least in the /admin/editcontent.php. If I guess right, the author of the default admin theme has ment that this definition is used on wysiwyg editors. This solution is based totally on the previous assumption.

This fix is bit more difficult, but it makes sure that the fix affects only the wysiwyg editors and not other components of the page.

So. This time we will edit the editcontent.php file. On rows 313 - 322 you can find something like this:
for($i=0;$i

         
         



       
         
         
       
       
       
         
         
       
      <?php
        }
}

Now this code would change the div class of the textareas to be pageinputwysiwyg instead of pageinput, which would now make use of the pageinputwysiwyg definition on the style.php. It would have been better to mark only the fields with real wysiwyg textarea with the pageinpytwysiwyg class, but I could not find a way to separate these fields..

i have to admit that this approach is bit up-side-down, since I have taken granted that the theme is created according the guidelines and assumed that the editcontent.php is behaving badly. However, since the documentation of the admin theme creation is currently pit poor, I have not been able to find out which is correct. However I think that the editors should be separeted from the other input fields on the level of css.

I have seen this structure as well, and for WYSIWYG editors the structure is not perfect.

The problem here is that the WYSIWYG is included inside a tag, and that tags cannot contain other block level elements such as a to be valid (please correct me if I'm wrong).

Most WYSIWYG editors are buildt up with divs.

A better solution would be to replace the ...WYSIWYG structure.. with ...WYSIWYG structure..