Category: Regression

{syntax type="tiki" editor="plain"}
~~#F00:Update still on Tiki26.x~~

On Tiki23 if I can have global Admin setting for the Wiki Page to Show page title (enable by default).
So the page "myitems-" will show the title (a link) on the top of the page.

On the properties of the page "myitems-" I can individually turn it off for this page.
So the page "myitems-" doesn't show the title (a link) on the top of the page.

The page can be used as a template to displays items from a tracker using the an alias.
The URL then will become "myitems-4" and now the page title is displayed which is wrong.

Instance is coming

Module execution failed if the visitor is anonymous.
Anonymous can't see listpages.php even if they have Wiki admin permissions

This filter is no longer work if the user is anonymous

{CODE()}
{filter field="title" content="~np~{~/np~{page}}"}
{CODE}
Instance coming... (not reproducible with default settings... more tomorrow)

When using "Wiki page pagination" the navigation bar on the first page look fine.
However on the second page it seems to be conflicting with the sliding side menu and the page look broken.

{syntax type="tiki" editor="plain"}
For themes that don't have child themes, the child theme selectors on tiki-admin.php?page=look should be empty and ghosted. But currently in master and branch 29, child themes are listed in the selector for all themes. The specific child themes that are shown change based on what parent theme was selected (but not necessarily submitted). Whatever the method is to show the correct child theme(s) for each theme, it's broken. This behavior goes away if Element Plus is turned off. (Selecting an incorrect child theme doesn't do anything, but the UI should be accurate, as it was up until Tiki 27.)

{syntax type="tiki" editor="plain"}
When you enable SEFurl you want to redirect all traffic to the SEF counterpart.

To have them also correctly out of reach of robots you have to uncomment the following elements in the robots.txt file.

{CODE()}
# == Begin SEF URL Section ==
# Remove pages in favor of the SEF counterpart (Enable only after SEF URL’s are enabled in tiki will otherwise prevent indexing.)
# Disallow: /tiki-forums.php
# Disallow: /tiki-view_forum.php
# Disallow: /tiki-index.php
# Disallow: /tiki-read_article.php
# Disallow: /tiki-view_blog.php
# Disallow: /tiki-list_file_gallery.php
# == End SEF URL Section ==
{CODE}

It was working till Tiki28.
But if you do it in Tiki29, a <meta name="robots" content="index, follow, NOINDEX, NOFOLLOW"> will be added to all the pages.

May come after this : https://gitlab.com/tikiwiki/tiki/-/merge_requests/6653

I've been using for many semesters this workspace template (See below) which allowed me to create a bunch of pages, groups, category, and a few other objects. I've recently updated to 16.2svn , attempted to create the new workspace "2017a Spring" for this new semester based on this same template, and so far I saw that only the default group __Courses:_:2017a Spring__ was created and not the two subgroups "Courses:_:2017a Spring Faculty" and "Courses:_:2017a Spring Students".

So something is borked, and I presume that other parts of the workspace where not created properly (untested yet)



{CODE(caption="YAML")}
---
objects:
-
type: categorize
data:
type: wiki_page
object: $50f320f6d7ffe
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: 50f320f6d7ffe
data:
name: $profilerequest:namespace$undefined$
namespace:
content:
-
type: categorize
data:
type: wiki_page
object: $50f320f6d822c
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: 50f320f6d822c
data:
name: Sessions
namespace: $profilerequest:namespace$undefined$
content:
structure: 0
-
type: categorize
data:
type: wiki_page
object: $50f320f6d82c4
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: 50f320f6d82c4
data:
name: Menu
namespace: $profilerequest:namespace$undefined$
content:
-
type: categorize
data:
type: wiki_page
object: $50f320f6d8383
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: 50f320f6d8383
data:
name: Final Paper
namespace: $profilerequest:namespace$undefined$
content:
structure: 0
-
type: categorize
data:
type: wiki_page
object: $reffinalpapertemplate
categories:
- $profilerequest:category$undefined$
-
type: wiki_page
ref: reffinalpapertemplate
data:
name: Final Paper Template
namespace: $profilerequest:namespace$undefined$
content:
-
type: categorize
data:
type: forum
object: $forumref
categories:
- $profilerequest:category$undefined$
-
type: forum
ref: forumref
data:
name: Main forum
namespace: $profilerequest:namespace$undefined$
attachments: everyone
list: [ topic_reads ]
content:
mappings:
Base: $profilerequest:group$undefined$
Students: >
$profilerequest:group$undefined$
Students
Faculty: $profilerequest:group$undefined$ Faculty
permissions:
Base:
description: $profilerequest:group$undefined$
autojoin: y
objects:
-
type: category
id: $profilerequest:category$undefined$
allow:
- admin_categories
- add_object
- remove_object
- post_comments
- read_comments
- download_files
- upload_files
- view_file_gallery
- edit_gallery_file
- view_fgal_explorer
- view_fgal_path
- forum_edit_own_posts
- forum_post
- forum_post_topic
- forum_read
- forum_vote
- view_freetags
- freetags_tag
- unassign_freetags
- group_view
- group_view_members
- group_add_member
- group_remove_member
- perspective_view
- view_sheet
- view_sheet_history
- tracker_view_attachments
- tracker_view_comments
- create_tracker_items
- tracker_view_ratings
- tracker_vote_ratings
- tracker_revote_ratings
- view_trackers
- view
- edit
- wiki_view_history
- edit_structures
- rename
- rollback
- upload_picture
- wiki_view_comments
- wiki_view_source
- site_report
- modify_object_categories
-
type: group
id: Base
allow:
- group_view
- group_view_members
- group_add_member
- group_remove_member
-
type: group
id: Students
allow:
- group_view
- group_view_members
- group_add_member
- group_remove_member
-
type: group
id: Faculty
allow:
- group_view
- group_view_members
- group_add_member
- group_remove_member
Students:
description: >
$profilerequest:group$undefined$
Students
objects:
-
type: category
id: $profilerequest:category$undefined$
allow:
- admin_categories
- add_object
- remove_object
- post_comments
- read_comments
- edit_gallery_file
- forum_edit_own_posts
- forum_post
- forum_post_topic
- forum_read
- forum_vote
- view_freetags
- freetags_tag
- unassign_freetags
- edit_sheet
- view_sheet
- view_sheet_history
-
type: group
id: Base
allow:
- group_view
- group_view_members
-
type: group
id: Students
allow:
- group_view
- group_view_members
-
type: group
id: Faculty
allow:
- group_view
- group_view_members
Faculty:
description: $profilerequest:group$undefined$ Faculty
autojoin: y
objects:
-
type: category
id: $profilerequest:category$undefined$
allow:
- admin_categories
- view_category
- add_object
- remove_object
- assign_perm_category
- post_comments
- read_comments
- admin_comments
- edit_comments
- remove_comments
- dsn_query
- admin_file_galleries
- assign_perm_file_gallery
- batch_upload_files
- create_file_galleries
- edit_gallery_file
- remove_files
- admin_forum
- forum_attach
- forum_autoapp
- forum_edit_own_posts
- forum_post
- forum_post_topic
- forum_read
- forums_report
- forum_vote
- view_freetags
- admin_freetags
- freetags_tag
- unassign_freetags
- broadcast
- perspective_edit
- perspective_admin
- admin_sheet
- edit_sheet
- view_sheet
- view_sheet_history
- admin_trackers
- attach_trackers
- tracker_view_attachments
- comment_tracker_items
- modify_tracker_items
- modify_tracker_items_pending
- modify_tracker_items_closed
- remove_tracker_items
- remove_tracker_items_pending
- remove_tracker_items_closed
- tracker_view_ratings
- view_trackers_closed
- view_trackers_pending
- watch_trackers
- export_tracker
- admin_wiki
- assign_perm_wiki_page
- lock
- remove
- use_as_template
- wiki_view_ref
- wiki_admin_attachments
- wiki_attach_files
- wiki_view_attachments
- workspace_instantiate
-
type: group
id: Base
allow:
- group_view
- group_view_members
-
type: group
id: Students
allow:
- group_view
- group_view_members
-
type: group
id: Faculty
allow:
- group_view
- group_view_members

{CODE}

In a number of places in the admin interface, there's a wrench icon that, when hovered over, causes a popover/popup containing action links. Since the update to Bootstrap 4, this popup disappears with no delay as soon as the cursor leaves the wrench icon. The popover and its links disappear before any link can be clicked. There needs to be a longer delay before the popover disappears, similar to how it was with Bootstrap 3.

On creating a group, group is created but a false error warning is displayed wrongly.

Check adding a group on the instance.

On Safari the error is different:
{CODE()}AJAX: error 0 (rejected) for URL: tiki-ajax_services.php?controller=group&action=new_group&modal=1{CODE}

There is a regression when choosing values from the multiselect fields (the Select feature must be enabled?) the forms input fields do not behave correctly when typing the suggestions. Also the pink rectangle looks a bit ugly. It was blank (same color as the background) before when you started typing in it?

See the video below:
{mediaplayer src="display1800"}

(This is also to test if the RTC video recording works properly ;))

To reproduce:
#Enable the JQuery upload feature
#Edit a page and upload an image using the icon "Choose or upload images"
#Save the page
#Then you decide to change that picture: Click the img plugin helper icon below the image
#Click the icon next to the fileId field to upload new image insted of the current one
#Upload the image then click it - it should replace the ID 1 with ID 2 but instead it inserts the whole wiki syntax and messes up the img when saved

{syntax type="tiki" editor="plain"}
I installed a Tiki 30 from git using an existing DB to be upgraded.

On DB validation I had a white screen and this is the error log:

{CODE()}
[23-May-2026 06:17:12 UTC] PHP Warning: Undefined array key "feature_fixed_width" in /blabla.bsfez.com_tiki30/installer/schema/20260312_change_fixed_width_default_tiki.php on line 18
[23-May-2026 06:17:12 UTC] PHP Fatal error: Uncaught Exception: Found 1 unsupported mail queue entries (serialized in old Laminas/Zend format). These entries cannot be processed. WARNING: These entries will be DELETED if you proceed with --auto-register, and queued email data will be lost. To delete them and continue, rerun:<info> php console.php database:update --auto-register</info> in /blabla.bsfez.com_tiki30/installer/schema/20260430_remove_unsupported_mail_queue_entries_tiki.php:42
Stack trace:
#0 /blabla.bsfez.com_tiki30/installer/Installer.php(192): upgrade_20260430_remove_unsupported_mail_queue_entries_tiki(Object(Tiki\Installer\Installer))
#1 /blabla.bsfez.com_tiki30/installer/Installer.php(143): Tiki\Installer\Installer->installPatch('20260430_remove...')
#2 /blabla.bsfez.com_tiki30/installer/tiki-installer.php(562): Tiki\Installer\Installer->update()
#3 /blabla.bsfez.com_tiki30/tiki-install.php(132): include_once('/Users/bernards...')
#4 {main}
thrown in /blabla.bsfez.com_tiki30/installer/schema/20260430_remove_unsupported_mail_queue_entries_tiki.php on line 42
xxxxx htdocs %
{CODE}

Kind of an edge case, but if layout theme names change between versions or due to development work, so there's a mismatch between the stored layout preference and the layouts listed in the files, then a blank screen is the result. The database needs to be edited directly to correct the problem (tiki_preferences site_layout updated to match available layout names).

There should be a fallback to a default layout ("basic") if the preference name isn't found, similar to how the site will fall back to the default theme if the selected theme or stored-preference theme isn't found.

Nothing displays when trying to view, for example, http://doc.tiki.org/tracker20 . The page was normal a few days ago. This problem seems to be restricted to doc.t.o.

I tried to access the poll at dev.t.o using the Setting menu item, polls.
It goes to a 500 page error.

Polls are working fine at tiki.org

In a Tiki 21.4 I get a WSOD (white screen of death / blank page) when I save a newly created page.

The page is created anyway and usable. The WSOD disappears when the browser is sent one page back or the site/page is loaded manually.

The bug __only__ occurs while __saving__ a newly created page for the __first time__.

After editing a previously existing wiki page, there is no WSOD after saving.

I did not yet test the behaviour for other versions, but I will add versions accordingly.

Tested in show instances:

Tiki 23.1vcs
http://bsfez-11581-7912.show2.tikiwiki.org
success - could not reproduce

Tiki 21.5vcs
http://torsten-11143-7928.show2.tikiwiki.org
success - could not reproduce

I have a strange problem on Tiki 2.0RC2:

I have two similar TikiWiki-installations. One just for testing on my Linux-Server and the second on a WinNT-Server. The Windows-Server is the one we want to/have to use for our Wiki :-(

On my Linux-Server works everything.

On the Win-Server don’t work wysiwyg-editor’s “Insert/Edit an internal wiki link”-button. The “window” opens but it shows only this animated waiting-bar. (See the picture)
Any other button works fine!

{syntax type="tiki" editor="plain"}
**Affected versions:** 30.0, 30.1, and current `master` (verified against the raw files on GitLab).
Not present in 29.2.

**Severity:** The WYSIWYG editor never renders on affected pages, so those pages cannot be edited
in WYSIWYG mode at all. On our site this hit 194 of 249 wiki pages, because Tiki remembers the
last-used editor per page in `tiki_pages.wysiwyg`.

**Environment:** Tiki 30.1, PHP 8.3.33, MySQL 8.0.46. `markdown_enabled = y`,
`markdown_default = markdown`, `feature_wysiwyg = y`.

----

!! Symptom

Opening a wiki page whose last-used editor was WYSIWYG loads the page (HTTP 200, nothing in the
PHP error log), but the editor never appears. The browser console shows:

```
Uncaught TypeError: a.lastIndexOf is not a function
at formatTikiToolbars.js:31:11
at Array.forEach (<anonymous>)
at P (formatTikiToolbars.js:28:26)
```

!! Root cause

Tiki 30 renamed `TextArea`'s `syntax` parameter to `_syntax`, but did not update the toolbars
handler that consumes it.

The rename itself looks deliberate and correct: `TextArea.php` emits every parameter whose name
does **not** start with `_` as an HTML attribute on the `<textarea>`:

```php
// lib/smarty_tiki/BlockHandler/TextArea.php:213-216
foreach ($params as $k => $v) {
if ($k[0] != '_' && ! in_array($k, ['comments', 'switcheditor', 'section', 'area_id', 'autosave'])) {
$textarea_attributes .= ' ' . $k . '="' . $v . '"';
}
}
```

so under 29.2 a bogus `syntax="tiki"` attribute was being written into the markup. The fix was to
prefix it. What was missed is that the same `$params` array is handed straight to the toolbars
handler, which still keys on the old name:

1. `TextArea.php:91,93` -- sets `$params['_syntax']` from `guess_syntax()` (e.g. `'tiki'`).
2. `TextArea.php:203` -- `$wysiwyglib->setUpEditor($as_id, $params);` passes the **whole array**.
3. `wysiwyglib.php:87` -- `json_encode(smarty_function_toolbars($params, ...))` forwards it.
4. `FunctionHandler/Toolbars.php:26` -- still reads `syntax`, so with the key gone its default wins:

```php
$default = [
'comments' => 'n',
'is_html' => $is_html,
'section' => $section,
'syntax' => $prefs['markdown_default'], // <-- takes over; no '_syntax' fallback
];
$params = array_merge($default, $params);
```

Every Tiki-syntax page is therefore reported as `markdown`. That takes the markdown branch of
`ToolbarsList` (`lib/core/Lib/core/Toolbar/ToolbarsList.php:227-251`), which flattens the toolbar
by one level and `json_decode`s each token into an object -- a shape built for the Toast editor
("need to flatten the icons for toast which only has one toolbar it seems").

Summernote's formatter then receives that Toast-shaped structure:

```js
// src/js/wysiwyg/summernote/formatTikiToolbars.js:29,33
const flattenDepth1 = toolbar.flat(1);
flattenDepth1.forEach((item, index) => {
const lastSeparator = item.lastIndexOf("-"); // objects have no .lastIndexOf -> TypeError
```

With the correct syntax the non-markdown path returns `$lines[] = [$lineOut]` (one level deeper),
so `flat(1)` yields arrays and `lastIndexOf` resolves. With the markdown path it yields objects,
and the editor dies before rendering.

!! Reproduction

1. Set `markdown_enabled = y` and `markdown_default = markdown`.
2. Create/edit a wiki page whose content is Tiki syntax (so `guess_syntax()` returns `tiki`).
3. Set the page to use the WYSIWYG editor and reload the edit page.
4. The editor does not render; the console shows the TypeError above.

!! Evidence

Building the toolbar directly from CLI on 30.1, varying only the parameter name:

| params passed to `smarty_function_toolbars()` | result of `toolbar.flat(1)` |
|---|---|
| `'syntax' => 'tiki'` (pre-30 behaviour) | 2 blocks -> 2 arrays -- works |
| `'_syntax' => 'tiki'` (30.x behaviour) | 3 blocks -> 23 objects -- throws |
| `'syntax' => 'markdown'` (genuinely markdown) | 3 blocks -> 23 objects -- Toast shape, as intended |

Worth noting for triage: stock 29.2 and 30.1 produce the same toolbar structure for a given
syntax value, and ship byte-identical built JS for formatTikiToolbars (I diffed the minified
public/generated/js/wysiwyg-summernote.js in both releases). The regression is purely the
dropped parameter name -- not the toolbar structure and not the editor bundle.

!! Suggested fix

Honour the new name in the handler, falling back to the preference as before:

--- a/lib/smarty_tiki/FunctionHandler/Toolbars.php
+++ b/lib/smarty_tiki/FunctionHandler/Toolbars.php
@@
$default = [
'comments' => 'n',
'is_html' => $is_html,
'section' => $section,
- 'syntax' => $prefs['markdown_default'],
+ 'syntax' => $params['_syntax'] ?? $prefs['markdown_default'],
];

This is behaviour-preserving: array_merge($default, $params) still lets an explicit syntax
parameter win (as templates/wiki_edit.tpl passes via syntax=$textarea_syntax), and when
neither key is present nothing changes. It only affects the case where _syntax is set and
syntax is not -- exactly the broken path.

Applied to a production 30.1 install, this restores the 29.2 structure (2 blocks -> 2 arrays)
and the WYSIWYG editor loads correctly again.

An alternative, if you would rather keep the handler's public API as syntax, is to translate at
the call site in wysiwyglib::setUpEditor() -- but the handler-side fix covers every caller that
forwards a TextArea params array, of which there are several
(wysiwyglib.php:51, :87, :267).

!! Possibly related

WysiwygLib::setUpEditor() in 30.x issues an outbound HTTP request to the LanguageTool server
(Services_LanguageCheck_Controller::getLanguageToolUrl(), default http://localhost:8081) on
every editor setup, unconditionally -- the "always check if language is supported" block runs
even when feature_language_check is n. On a host with no LanguageTool server this is a wasted
request per edit-page load, and against a slow/filtered remote host it would add up to the 5s
timeout. Reported separately here only as an observation; it did not cause the failure above.

WYSIWYG articles are ok when displayed using tiki-read_article.php, plugin or newsletter but show html on tiki-view_articles.php

Check Article 2 wysiwyg
http://demo.tiki.org/11x/tiki-read_article.php?articleId=4

Now compare : http://demo.tiki.org/11x/tiki-view_articles.php
and also : http://demo.tiki.org/11x/tiki-index.php

The WYSIWYG doesn't load the bars with size and font into the post (''and several other tools in the toolbar'') .
Please see this short video recording which explains and shows the issue:
[https://drive.google.com/file/d/1-kZWIMVLvu-Z9AO_C0nsPKupW194NYQ_/view|https://drive.google.com/file/d/1-kZWIMVLvu-Z9AO_C0nsPKupW194NYQ_/view]

Kind regards
PowerQuest

Most of the icons are not showing up for WYSIWYG kama theme in firefox.

Demonstrated on instance.

{img src="http://i.imgur.com/cCLoy3R.png"}

Just for clarity, I don't believe its a local cache issue. I tried it, and someone I work with tried it, different browsers, cleared caches, etc.

This was discovered on a Tiki12 upgraded from Tiki9 using wysiwyg, but the issue is also there with no wysiwyg.
I suppose we should first focus on the non-wysiwyg issue and there are chances it will also be solved in wysiwyg. So no more about wysiwyg

!First, I remind how things should work, as all is fine in wiki pages
In HomePage, insert
~np~{HTML()}<iframe src="http://www.musarama.org/en/widget/slideshow/key/269c31354b3770e5e96e8eccb1fec97ced34f0fc0b" width="480" height="300" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>{HTML}~/np~

Approve → OK
This works fine as I understand it should, and as it worked in Tiki 9. Meaning there is a nice iframe with images in it.
See: [http://jyhem-9952-5156.show.tikiwiki.org/tiki-index.php]

!Second, I show the problem
Create new article and put inside
~np~{HTML()}<iframe src="http://www.musarama.org/en/widget/slideshow/key/269c31354b3770e5e96e8eccb1fec97ced34f0fc0b" width="480" height="300" frameborder="0" webkitAllowFullScreen mozallowfullscreen allowFullScreen></iframe>{HTML}~/np~
→ It asks for validation but on viewing, the content of the HTML plugin is wiped!
I see it is wiped by editing the article, and I see the HTML plugin is empty.

I try again, checking ''Allow full HTML (Keep any HTML tag.)
If not enabled, Tiki will retain some HTML tags (a, p, pre, img, hr, b, i).'' but that seems to be ignored.
In re-editing, it does not even stay checked.
Anyway, that should not be the way to do this. HTML plugin should not require to check ''Allow full HTML''.

I attempt to insert my html code outside the HTML plugin but it still gets stripped out, even when checking ''Allow full HTML''.
See: [http://jyhem-9952-5156.show.tikiwiki.org/tiki-read_article.php?articleId=1]

So right now there is no way to insert stuff in articles like they could :-(

When I create a WYSIWYG table using the editor WYSIWYG table editor is create a code like this is one and single row:

{CODE()}||table|a|b %%% 1| |  %%% 2| | ||{CODE}
Carriage returns are turned into wiki syntax and therefor it break the table

It should have been:
{CODE()}||table|a|b
1| | 
2| | ||{CODE}

{syntax type="tiki" editor="plain"}
We are running Tiki 6.2 (clean install), on a Windows 2003 Server, Apache 2.2.16 w SSL, PHP 5.3.3, remote MySQL 5 database.

This bug is across all browsers.

Our users are editing in the CKEditor WYSIWYG and trying to add anchors. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%our users use the Anchor icon (flag) to create an anchor at the bottom of a page. The anchor name window comes up and they give it a name, save, a yellow anchor icon is displayed in the editor. If they jump to the top of the page and create a Link (using the Link icon in the toolbar) and select Link Type: "Link to another anchor in the text", Select an Anchor/By Anchor Name and press Ok. At this point everything looks correct in CKEditor.The user presses Save. The Link at the top is correct using the normal syntax %%% {CODE()}[#myAnchor|Link to bottom]{CODE}%%%however the anchor at the bottom is gone as if it never saved or the parser has discarded it.

I have had to instruct our users how to type in manually the anchors using the old plugins [http://doc.tiki.org/PluginAlink] and [http://doc.tiki.org/PluginAname]. They are not happy about using long hand plugin notation.

I have tried in both IE 8 and FF 3.6 with the same result.

Since IE is our corp standard our users need to be able to add anchors using that browser. Also, they had no problem in Tiki 5.x but that was a different WYSIWYG system.

May be related to [http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1499]

{syntax type="tiki" editor="plain"}
We are using Tiki v6.2 vanilla, PHP 5.3.3. When using the WYSIWYG_6x default profile of:%%%{CODE()}Editing and Plugins
Wiki Paragraph formatting (ON, however default: off)
...but still create line breaks within paragraphs (on)
HTML Purifier (on)
Wiki
Allow HTML (on, however default: off)
WYSIWYG
Content is parsed like wiki page (on)
Content is partially wiki parsed (off)
Use Wiki syntax in WYSIWYG (off){CODE}%%%we can not edit a section using the Edit Section button. A blank WYSIWYG screen is displayed and if you enter content and save it gets thrown to the bottom of the wiki page and not within the section.

Reproduce: Create a blank wiki page in WYSIWYG, create a bunch of headers, save, view edit icons (if not already), click on "Edit Section" button.