Hi devs,
Here’s what I commented on https://github.com/xwiki/xwiki-platform/pull/307 :
“
Thanks Pascal. I've just noticed that we still bundle TinyMCE in XWiki's WAR. It was probably left for backward compatibility but since it's been like 6-7 years that we've dropped it, I believe we could vote about dropping it from our sources and if someone really needs it they'll still be able to manually install them in their wikis. I'll follow up on the devs list, thanks.
“
WDYT? Are you ok to remove it?
Thanks
-Vincent
Hi devs,
So this proposal appeared in some of my proposals but right now I created a
proper Proposal/Idea mail for it.
It's about having an 'Administer Page' section in the menus, similar to the
'Administer Wiki' and 'Administer Space' functionality.
The 'Administer Page' will be accessible to global admins, page creators
and users with (edit?/admin?) rights for the page.
>From what we currently have implemented it should contain the 'Rights
Editor' (?editor=rights) at page level.
In the future we could make 'Presentation', 'Page Elements' or 'Panel
Wizard' to be more granular and be set at Page level (have different panels
and style for just one page).
Some screenshots at
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/PageAdministration
Thanks,
Caty
Hi devs,
I recently discussed with Edy about how the breadcrumb should look and
there may be an inconsistency with the hierarchy displayed by the
document tree.
Breadcrumb on the main wiki:
Home Icon (pointing to the main wiki home page) / MDoc1 / MDoc2 / ... / MDocX
Breadcrumb on a subwiki (that has only global users):
Home Icon (pointing to the main wiki home page) / Subwiki Pretty Name
(pointing to the subwiki home page) / SDoc1 / SDoc2 / ... / SDocX
After seeing the breadcrumbs both on the main wiki and on a subwiki
the user might think that the document MDoc1 and the wiki "Subwiki
Pretty Name" are on the same level: both children of the main wiki.
Next if the user tries the document tree macro using:
{{documentTree showWikis="true" /}}
he will notice that "Subwiki Pretty Name" is not actually a child of
the main wiki but a top level node (a child of the "farm"), on the
same level with the main wiki.
Can this be considered as an inconsistency? In our model (e.g.
document reference) there is no hierarchy between wikis, although, as
Edy pointed out, there are places where we consider the main wiki to
be the "parent" of the subwikis (e.g. in the authorization module, by
inheriting access rights from the main wiki).
WDYT? Is the main wiki the parent of the subwikis or just a sibling?
Should the breadcrumb be synchronized with the tree?
Thanks,
Marius
Hi,
We are using mixed naming when referring to a document/page, not only on
different pages, but also in the same context (Rename step for example).
There is also an issue referring to this problem
XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to
find an answer in order to move forward consistency.
So the question is which version we prefer: "Page" or "Document" ?
I'm voting +1 for "Page".
"Page" is more used IMO, especially in the "Space"/"Page" context.
"Page" is more general than "Document" and better fitted for a platform that
encapsulates all kind of content (not just documents).
Please cast your vote.
Thanks,
Caty
Hi Devs,
I would to propose an improvement for the color theme editor to make it
more powerful and flexible.
In order to achieve this, I propose to
add a new tab "Customized Variables
<http://design.xwiki.org/xwiki/bin/view/Proposal/Improvethecolorthemeeditor>"
to the editor. This tab would allow us to add more LESS CSS variables and
list them in a list We could use this variable in order to add more LESS
css rules in the advanced tab and target any area on the platform.
http://jira.xwiki.org/browse/XWIKI-12351
WDYT?
--
*Yacine KEBIR*
Web Designer / Front End Developer
yacine.kebir(a)xwiki.com
*Mobile: *+213 550 749 033
*Web Site : *www.xwiki.com
Hi,
Right now almost all func tests fail to delete pages when they do getUtil().deletePage(…). They fail with:
Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [interface org.xwiki.job.Job] hint = [delete]]
The reason is that since XWIKI-12268 the Delete action cannot work if the Refactoring module isn't bundled, which makes the Refactoring module a core module. And this module is not part of the core modules ATM. I’ve added it to the PackageMojo for now but we need to decide what to do.
Personally I’ve always viewed Refactoring as optional and advanced features.
I don’t consider basic delete, basic copy and basic rename/move as refactoring options. However there are some parts of them that are refactorings. For example when Renaming, also check for wiki pages having the renamed page as parent and updating them or updating wiki links in pages.
So we need to decide if:
* We consider the Refactoring module as core.
* Introduce a new module and move some of the core actions such as delete, move, etc to it and keep the refactoring module for non-core refactoring
* Split the refactoring into basic refactorings and advanced ones. Have basic delete, copy, rename + advanced options for them separately
* Others?
WDYT?
Still hesitating on my side.
Thanks
-Vincent
Hi devs,
Problem:
* We have several ways of getting the main wiki id and the current wiki id:
** way 1: $services.wiki.mainWikiId and $services.wiki.currentWikiId
** way 2: $xcontext.getMainWikiName() and $context.getDatabase()
* In menu_macros.vm we set: #set ($mainWikiId = $services.wiki.mainWikiId)
** This is used in some other templates such as drawer.vm:
#set ($hasHomeWikiAdmin = $xwiki.hasAccessLevel('admin', $xcontext.user, "${mainWikiId}:XWiki.XWikiPreferences”))
** This means that currently is a module doesn’t declare a dependency on the wiki module, its functional tests will fail with:
15:29:29.868 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 15:29:29,868 [http://localhost:8080/xwiki/bin/register/XWiki/Register] WARN o.h.u.JDBCExceptionReporter - SQL Error: -4850, SQLState: 3F000
15:29:29.869 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 15:29:29,868 [http://localhost:8080/xwiki/bin/register/XWiki/Register] ERROR o.h.u.JDBCExceptionReporter - invalid schema name: ${MAINWIKIID}
15:29:29.884 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 15:29:29,883 [http://localhost:8080/xwiki/bin/register/XWiki/Register] ERROR .a.DefaultAuthorizationManager - Failed to load rights for user [Public] on [${mainWikiId}:XWiki.XWikiPreferences].
Solution:
* Make the Wiki API Module and the Wiki Script Module a core API (ie the most minimal version of XWiki cannot work without them)
Actions to take:
* Add a dep on these 2 modules in PackagerMojo.java
* Deprecate $xcontext.getMainWikiName() and $context.getDatabase() and favor using $services.wiki.mainWikiId and $services.wiki.currentWikiId (once we finish adjusting all places, move xcontext.getMainWikiName() and context.getDatabase to the oldcore legacy module).
* Remove all the checks we do to check for the availability of the wiki script service. For example:
admin.vm: #if ("$!services.wiki" != '' && $services.wiki.currentWikiId != $services.wiki.mainWikiId)
Activity.xml: #if ("$!services.wiki" != '' && $services.wiki.mainWikiId == $services.wiki.currentWikiId)
menuview.vm: #set ($isWikiAPIAvailable = ("!$services.wiki" != '') && ("!$services.wiki.user" != ''))
CreateWiki.xml: #if ($services.wiki && $services.wiki.creationjob)
WDYT?
Thanks
-Vincent