xwiki-devs August 2015

xwiki-devs@xwiki.org

15 participants
43 discussions

[xwiki-devs] [Proposal] Remove TinyMCE files from the XWiki WAR

by vincent＠massol.net

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

8 years, 8 months

[xwiki-devs] [Idea] Page Administration

by Ecaterina Moraru (Valica)

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

8 years, 9 months

[xwiki-devs] Inconsistency between the breadcrumb and the document tree on a subwiki

by Marius Dumitru Florea

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

8 years, 11 months

[xwiki-devs] [UX][Consistency][Vote] "Page" vs. "Document" consistent naming

by Ecaterina Moraru (Valica)

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

8 years, 12 months

[xwiki-devs] [Contrib] Request for a new project

by Jean SIMARD

Hi devs, Lately, I've been working on some sort of new format to import information in XWiki [1] (I'm not that comfortable with editing XAR format with my text editor). You'll find an example of this format in the testing procedure of my module [2]. To create this format, I used the XML Schema described in the REST API of XWiki [3]. To code the importer, I've used the filter module [4]. I've also create a REST service in order to import through REST (using filters) [5]. I'd like that project be a part of xwiki-contrib. At the moment, I've called it 'api-xwf'. Maybe 'api-xwiki-format' would be more self explicit. If you'd prefer something else, please let me know. Thanks, [1] https://github.com/woshilapin/api-xwf [2] https://github.com/woshilapin/api-xwf/tree/master/xwf-filter-stream/src/tes… [3] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwi… [4] http://extensions.xwiki.org/xwiki/bin/view/Extension/Filter+Module [5] https://github.com/woshilapin/api-xwf/tree/master/xwf-rest-api -- Jean Simard jean.simard(a)xwiki.com Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org

9 years

[xwiki-devs] [Proposal] Customized Less Variables on the color editor

by Yacine Kebir

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

9 years

[xwiki-devs] [Iteration][UX] Nested: Livetable

by Ecaterina Moraru (Valica)

Hi, I've added some ideas on how to display 'Space' column in the AllDocs page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable Let me know what you think and if there are other ideas. Thanks, Caty

9 years

[xwiki-devs] [Brainstorming] Is the Refactoring module a core module?

by vincent＠massol.net

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

9 years

[xwiki-devs] [Iteration][UX] Nested: Tree Location

by Ecaterina Moraru (Valica)

Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation Thanks, Caty

9 years

[xwiki-devs] [VOTE] Make the Wiki API + Script modules be core modules

by vincent＠massol.net

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

9 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs August 2015