Icons are not being assigned properly due to recent commits
- Status
- Closed
- Subject
- Icons are not being assigned properly due to recent commits
- Version
- 14.x Regression
- Category
- Regression
- Feature
- WYSIWYG (What You See is What You Get)
- Resolution status
- Fixed or Solved
- Submitted by
- taylordustin
- Volunteered to solve
- Jonny Bradley
- Lastmod by
- lindon
- Rating
- Description
I noticed after pulling the latest code from SourceForge that certain icons in the WYSIWYG and Wiki editors were not being set properly. A condition inside an if statement in /lib/toolbars/toolbarslib.php on the line 1709 was setting several icons to the plugin.php icon.
I began looking for the cause of the issue and discovered a series of several commits that had caused the bug. The icons in question are the features 'Image', 'File', 'Mouseover', 'Insert Module', 'HTML', 'Include', 'Code', and 'Remarks Box'.
The problem code for each of the above features can be found in the lib/wiki-plugins/ directory and is attributed to a single line of code in each file. The structure of the hash tables located in these files appears to have been changed from using
'icon' => 'path/to/icon'
to
'iconname' => 'iconset_definition'Unfortunately, this has caused the regression on my site. To fix this, I can simply comment out the line with 'iconname', and replace it with the previous 'icon' line, however this increases the number of customizations on my site I would need to keep track of, and would prefer not to go down that route.
The revision numbers and files for the features in question are as follows:
'Image' = r56275 — /wiki-plugins/wikiplugin_img.php
'File' = r56269 — /wiki-plugins/wikiplugin_file.php
'Mouseover' = r56280 — /wiki-plugins/wikiplugin_mouseover.php
'Insert Module' = r56280 — /wiki-plugins/wikiplugin_module.php
'HTML' = r56273 — /wiki-plugins/wikiplugin_html.php
'Include' = r56276 — /wiki-plugins/wikiplugin_include.php
'Code' = r56254 — /wiki-plugins/wikiplugin_code.php
'Remarks Box' = r56291 — /wiki-plugins/wikiplugin_remarksbox.phpI looked into the new iconset definitions as well, and didn't notice any issues with it, so this is why I'm am submitting the bug report. Let me know if there is anything I can help with!
- Solution
Hopefully r56351 will do it for the normal wiki toolbars, still trying to work out a fix for WYSIWYG...
Thanks for the excellent bug report!- Importance
- 6
- Easy to solve?
- 6
- Priority
- 36
- Demonstrate Bug (Tiki 19+)
-
This bug has been demonstrated on show2.tiki.org
Please demonstrate your bug on show2.tiki.org
Version: Create show2.tiki.org instanceAbout show2.tiki.orgTo help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tiki.org instance. To start, simply select a version and click on "Create show2.tiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tiki.org.
- Ticket ID
- 5719
- Created
- Monday 28 September, 2015 19:37:14 GMT-0000
by taylordustin - LastModif
- Saturday 07 November, 2015 18:10:56 GMT-0000
Attachments
| filename | created | hits | comment | version | filetype | ||
|---|---|---|---|---|---|---|---|
| No attachments for this item | |||||||
;){kind=link}
;){kind=link}
- Browse Directory is broken
- Wiki argument variables, Documentation; The help tools of Tiki for Wiki argument variables redirect to the wrong page
- Plugin List, Wiki Argument Variables; Admin should see a warning when the Wiki Argument Variables is not enabled and he tries to use it.
- General, Navigation; Endless loop, too much redirect error, if a wiki page is the value of the option
- Tiki tag ~ hs ~ is lost on wiki page duplication
;){kind=link}
;){kind=link}