Table of Contents

Created by: gwideman, Aug 8, 2010 1:13 pm
Revised by: gwideman, Mar 16, 2012 3:08 am (28 revisions)

Page for listing issues with Wikispaces
Id series: GWWS-nnnnn

Issues List

GWWS-1001 (2010-08-06) WYSIWYG Editor: Table cell selection: Does not seem to be able to select multi cells, for example as prelude to applying same formatting to multi cells, clearing the cells (eg. after copy a table), or setting the cell background color.. (This is with the post-Aug 5th editor.)

GWWS-1002 (2010-08-06) WYSIWYG Editor: No ability to set background fill color in tables.

GWWS-1003 (2010-08-01) While logged in, main Wikispaces pages are hard to navigate to. This is because attempts to visit main wikispaces redirect to user's own account pages.

GWWS-1004 (2010-08-01) Nav bar Help link brings up panel that lacks Site Map link. Hence main useful technical help is not navigatable-to.

GWWS-1005 (2010-08-01) Permissions model is not spelled out. See separate page on this: Roles and permissions

GWWS-1006 (2010-08-10) No "draft in preparation" state. Consequently, for subscription levels below Super, any page in preparation is exposed to visitors, if only via Recent Changes and Manage > Pages,

GWWS-1007 (2010-08-xx) Lack of structure and navigation model.
  • Pages do not have parent pages, so there's no intrinsic order.
  • There's a "navigation area", and links can be listed there explicitly, or a page list widget can be placed there, but there is no support for large numbers of pages. (It may be possible to overcome this with some Javascript apparatus).

GWWS-1008 (2010-08-10) Page author, last editor and dates. No way to enforce that all pages have these fields.
  • There are wikitext variables for these, but no way to use those in a theme.
  • There are theme variables for various things like page name, but not for author, date etc.
  • There's a template feature, into which the wikitext variables could be pre-placed. But no way to oblige authors to use the template, or to not remove the variables.
  • Wikitext variables could be used in the navigation area, but then they just report the author etc of the navigation page, not of the main page.
  • Hmmm... maybe this could be partly addressed via page includes... must test. Yes, a standard include page could be used for this. However, there's no way to enforce that every page includes the standard include page.
  • Partial relief: The Content area includes a div with id="WikiPageInfo", normally hidden, which includes "LastEditBy" person and date. This could be exposed using javascript.

GWWS-1009 (2010-09-27) After page rename, wrong page
After using the Page > Rename feature, and pressing the Rename button, the server attempts to "return" to the old page, which is no longer there (unless we selected to create a redirect). This prompts to (re)create the old page. This is unwanted and confusing for users.

GWWS-1010 (2010-09-27) Page rename does not update existing links
In some other systems, renaming a page causes all links to that page (within the same site) to be updated accordingly. Evidently on Wikispaces that does not happen. Therefore, the "redirect" is needed even for links on this same site. This is a problem if you want to reuse the old page name for a new page with different content.

GWWS-1011 (2010-09-27) "Other Widget" and "Include file" widget symbols clumsy and inscrutable
In the WYSIWYG editor, some widgets are represented by large rectangular blobs, which are ungainly, and lack any indication of what they stand for, other than the type of widget.
  • The Include File widget could be much smaller, and show what file it is including. This would make it far more usable as a building block. This widget at least reveals its source in the wikitext editor.
  • The Other Widget widget symbols is also large and ugly for no reason, and again lacks any indication of what it is about. At the very least the HTML widget should allow for a name which could be shown in the editor. This widget is inscrutable in the wikitext editor also.

GWWS-1012 (2010-09-28) In WYSIWYG editor, copying Other Widget does not copy widget content
Copying page content from one page to another does copy the symbols for Other Widgets, but does not copy their content.

GWWS-1013 (2010-10-06) Style Text dialog expands border styles and does so incorrectly
Bug in the parser for the "Style Text" button's dialog (titled "Color and Style"). If you use the Advanced feature to apply the following simple style:
border: 1px solid black;
... the preview is fine, and upon "Apply Styles", the result is fine in the editor. However, if you reselect the same text and reopen Style Text, the style is disrupted, and turned into a large number of separate attributes, which are not correct (many "undefined"s).
Update: 2010-10-06: Fixed (email from Jeff Hanke).

GWWS-1014 (2010-10-07) Theme editor textarea buggy in IE8
The IE8 textarea bug makes it almost impossible to edit the theme text in IE8. Two issues: 1. Typing characters in the textarea causes scrolling to occur. 2. Mouse-over on the Save or Preview buttons also causes weird scrollbar and scrolling activity. Google "ie8 textarea bug" for suggestions on how to fix. I found that using IE8 dev window to change the textarea attribs worked: delete the width=100% and set cols to say 90 causes correct behavior.

GWWS-1015 (2010-12-14) Custom CSS save rejects multi-class selector with .wiki
When specifying a CSS selector involving .wiki with another class (for example, the save function reports an error and rejects this. This makes it difficult to apply styles for use in the tinymce editor. Error: "Your stylesheet is invalid. You can only apply styles to items under the .wiki class. The selector " h1" is not allowed as it is not under the .wiki class."

GWWS-1016 (2011-04-09) Bug: Visual editor shift-tab list/quotelist confusion
Expected behavior:
In a bulleted list, after writing a series of items at level N, one might want to "step out" to create items at level N-1. To do that, we would use Shift-Tab.
Curent behavior:
Shift-Tab sometimes works, but at other times it has the wrong effect, instead creating "quotelist" text.

GWWS-1017 (2011-06-08) Bug: Visual editor: eliminates space between monospace strings
Where there are two adjacent monospace strings (using double-curly-braces) separated by a space, the translation from WYSIWYG to wikitext erroneously eliminates the space.

GWWS-1018 (2011-09-13) Bug: Same-named teams in multi-project causes trouble
Creating two teams with the same name in two different projects causes one of them not to be accessible from the Projects list page, and one of them will no longer work. Attempting to delete one of the teams causes wikispaces to hang for a long time, and ultimately the team does not disappear, but no longer works.

GWWS-1019 (2011-09-13) Bug: WYSIWYG cursor keys stop working
Often, but not always, while editing page content using the WYSIWYG editor, cursor keys stop working in the editor, and instead operate on the containing browser window/page. (See email)

GWWS-1020 (2011-11-04) Bug: "familiy" typo in CSS for projects
In xxx-internal.css, there's a rule for .ProjectTeam .teamName that contains a setting for "font-familiy". I.e., "familiy" is misspelled.

GWWS-1021 (2011-11-04) CSS issues: border radius syntax and inconsistency
  • border-radius-topright -- incorrect syntax, should be border-top-right-radius
  • Inconsistent provision of variants for CSS3, -moz-, -webkit-

GWWS-1022 (2011-11-08) Project theme and javascript variables
Several issues with theme and javascript variables that relate to projects and teams. See page here: GWWS-1022 Project variables.
GWWS-1023 (2011-11-20): Team page-level permissions settings refer to wiki-level permissions instead of project-level permissions.
The wikispaces "project" features involve setting default permissions at the project level that apply to all pages created by all teams of that project. Hence, when visiting the permissions settings page for an individual page within a project/team, one would expect the "Default" radio-button item to to read:
"The page permissions are the same as the project permissions. View project permissions." [link to project permissions]
Instead, it reads:
"The page permissions are the same as the WIKI permissions. View WIKI permissions." [link DOES go to project permissions!]

GWWS-1024 (2011-11-20): Multiple wiki vs team permission wording issues
Subsumes GWWS-1023.
1. Page-level perms for team-created pages incorrectly refers to WIKI scope
2. Team Perms page badly mistitled and other bad labels
3. Recommend including "Team" or "Project" in various labels
4. Recommend NOT using the Lock icon for Permissions!
See email for more detail.

GWWS-1025 (2011-12-01): WebDAV pages_html transfers fail due to wrong size
For pages_html files, WebDAV server is reporting the sizes of the wikitext files, not the html version. BitKinex sees this as an integrity failure, and repeatedly attempts to refetch the files, eventually failing.

GWWS-1026 (2012-03-03): Theme docs need update
Theme docs at Theme components do not correspond to current wikispaces behavior, primarily relating to the recently changed Page Menu behavior. See notes at

GWWS-1027 (2012-03-05): "Pages and Files" list sorts backwards
On admin page "Pages and Files" (, the sort indicator up/down arrow shows the reverse of the actual sort order that is applied to the table. Ie: If you click on the Name column, so that the sort indicator points up (which conventionally means alpha ascending order), then the list is sorted in reverse alphabetical order.

GWWS-1028 (2012-03-16) WYSIWYG cursor keys STILL broken
This is basically a repeat of GWWS-1019 of six months ago,but with a few more details, notably that cursor keys are broken 100% of the time after creating a new page, using FireFox.

GWWS-1029 (2012-03-16) Paste text is wrapped in unwanted [p] tag
In the WYSIWYG editor, pasted text gets wrapped in an unwanted [p] tag, resulting in a linebreak before and after. This requires manually deleting the unwanted linebreaks.

GWWS-1030 (2012-03-16) Wikitext-to-WYSIWYG confuses list vs bold asterisks
In wikitext markup, outdenting a list item often causes that item to stop being a list item, and instead become some free text within the enclosing