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,
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,
According to the javadoc in XWikiDocument:
/**
* The last user that has changed the document's content (ie not object, attachments). The Content author is only
* changed when the document content changes. Note that Content Author is used to check programming rights on a
* document and this is the reason we need to know the last author who's modified the content since programming
* rights depend on this.
*/
private DocumentReference contentAuthorReference;
This means that objectadd or objectremove actions shouldn't change the content author as they do now.
I'm proposing that we fix this.
Do you see any issue?
Thanks
-Vincent
Hi devs,
In XWiki, if you send a POST request at the following URL
('MySpace.MyPage' is a document that doesn't exist at the moment)
/bin/save/MySpace/MyPage
with the following HTTP parameters:
* template=MySpace.MyTemplate
* XWiki.XWikiRights_0_users=XWiki.Me
* <others parameters>
with 'MySpace.MyTemplate' a template document and 'XWiki.Me' a user of
the wiki.
2 cases:
1. If 'MySpace.MyTemplate' contains a 'XWiki.XWikiRights' object, then
the resulting document 'MySpace.MyPage' will have this object with its
property 'users' initialize with the value 'XWiki.Me' (see HTTP
parameters)
2. If 'MySpace.MyTemplate' does not contain a 'XWiki.XWikiRights'
object, the resulting document 'MySpace.MyPage' will not contain it
either
### PROPOSAL
Create automatically the objects if they don't exist in the template
document.
###
To make it possible, it seems that we would need to refactor the method
'readObjectsFromForm(EditForm, XWikiContext)' in the
'com.xpn.xwiki.doc.XWikiDocument' class. And probably modify also the
'getObject(String)' from 'com.xpn.xwiki.web.EditForm' class.
2 things to take care:
* It seems there is no unit test for these methods.
* May this proposal be a security problem?
WDYT?
--
Jean
Hi devs,
Here's a proposal to move pages currently located in XE into platform modules:
* ColorThemes/*.xml --> xwiki-platform-colorthemes
* Main/Activity.xml --> xwiki-platform-activitystream-ui (move current xwiki-platform-activitytream into xwiki-platform-activitystream-api)
* Main/AllDocs.xml (and XWiki.Tableview, XWiki.Treeview, XWiki.OrphanedPages, XWiki.AllAttachments*, XWiki.DeletedDocuments, XWiki.DeletedAttachments and all pages used by those) --> new xwiki-platform-navigation module
* Main/RssFeeds.xml --> new xwiki-platform-help module or xwiki-platform-rss-ui module (see below)
* Main/SpaceIndex.xml --> xwiki-platform-navigation
* Main/Spaces.xml --> xwiki-platform-navigation
* Main/UserDirectory.xml --> xwiki-platform-user-ui
* Main/WebHome.xml --> xwiki-platform-dashboard-ui
* Main/WebRss.xml --> new xwiki-platform-rss-ui module, we would create a xwiki-platform-rss-api module too where we will move the feed plugin
* Main/Welcome.xml --> move to xwiki-platform-dashboard-ui since it's a dashboard gadget which we could consider as a default widget
* Sandbox/*.xml --> xwiki-platform-sandbox module (or xwiki-platform-help module)
* XWiki/XWikSyntax.xml --> xwiki-platform-help module
* XWiki/AttachmentSelector.xml --> xwiki-platform-user-ui or new xwiki-platform-attachmentselector module
* XWiki/ClassSheet, ClassTemplate, ObjectSheet, XWikiClasses,
* XWiki/GadgetClass.xml --> xwiki-platform-dashboard-ui
* XWiki/LiveTableResult*.xml --> new xwiki-platform-livetable module
* XWiki/MessageStreamConfig.xml --> new xwiki-platform-messagestream-ui module (and move xwiki-platform-message in xwiki-platform-message-api module)
* XWiki/RequestsStatus.xml --> xwiki-platform-administration module or remove from platform till we integrate it in the Admin as an admin tool somewhere since right now I think it's available in the Admin tools application
* XWiki/RequiredRightClass.xml --> since it's used in lots of other ui modules I'd propose to move it in java code as a class created on startup. Alternatively start creating a xwiki-platform-rights-ui module (or xwiki-platform-permission-ui module) and move it there
* XWiki/SharePage.xml --> not sure…. maybe in a xwiki-platform-share or xwiki-platform-sharepage module
* XWiki/TemplateProvider*.xml --> xwiki-platform-administration for the moment
* XWiki/WebHome.xml --> xwiki-platform-administration module
* XWiki/WebPreferences.xml --> xwiki-platform-administration module
WDYT?
Please try to tell me if you're ok for each line if you have time ;)
Thanks
-Vincent
Hi developers.
I have recently implemented the ability to use LESS in SSX:
http://jira.xwiki.org/browse/XWIKI-10708.
This feature has pointed me out some bugs, that are reported upstream:
https://github.com/less/less.js/issues/1878https://github.com/less/less.js/issues/1968
I have tried to implement a workaround, but as a result, it is preventing
us to use an important feature of LESS: .extend(). And it simply breaks the
Caty work on the Menu Application.
Moreover, LESS has been rewritten in version 2. But because of this
refactoring, the Rhino version does not work. See:
https://github.com/less/less.js/issues/2316
So we are stuck with the current version of LESS, with the bugs listed
above (that I am not able to patch).
But in parallel, I have worked to use LESS4j instead of the official LESS
project (http://jira.xwiki.org/browse/XWIKI-11034). And today, I finally
managed to make it work!
The good news is that LESS4j does not have the bugs that are blocking us.
I propose to commit this for 6.4M2 (before tomorrow), and we can still
revert it afterwards.
Advantages of LESS4j:
* should be quicker (see:
https://github.com/xwiki-contrib/less-vs-sass-benchmark)
* does not have the bugs listed above
* we can hope that the version 2 will be ported to LESS4j too.
Drawbacks of LESS4j:
* maintained by only one developer (but reactive when I report bugs)
* not exactly the same behaviour than LESS:
https://github.com/SomMeri/less4j/wiki/Differences-Between-Less.js-and-Less…
* maybe the error messages are less kindly than lessjs ones.
My implementation is configurable: an administrator can decide to use the
LESS official version by changing a property in xwiki.properties. I just
propose to have LESS4j by default.
Here is my +1.
Thanks,
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi.
Problem: in XWiki, we have currently 2 main skins, Colibri (to be
deprecated) and Flamingo, that did not share the same doctype. Colibri
templates are using the XHTML 1.0 syntax, meanwhile Flamingo uses the HTML
5 syntax.
Currently, we have hard-coded in a lot of places the fact that we use XHTML
1.0 syntax, but I would like to replace this by a new setting,
skin-dependant, to select the rendering syntax we want. It would enable us
to generate valid code (with the HTML cleaner, among other things) for each
skin we support.
This setting will be located in the XWiki.XWikiSkins objects, and in the
skin.properties file for file system skins. Of course we also need to add a
new API to get the current rendering syntax.
The alternative is to create a global setting or constant to set the
rendering syntax for the whole XWiki instance.
Some discussions about this there: http://jira.xwiki.org/browse/XWIKI-11602
Here is my +1,
Thanks,
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi All,
i want to put a {{warning}} in the header of a page when a specific macro is
not contained. How can i do that. I tried in a Listener when the needed
Macro-Block is not contained with
doc.getXDOM().getRoot().addChild(new WordBlock("{{warning}}Warning
Text.{{/warning}}"));
context.getWiki().saveDocument(doc, context);
This not works. What is the correct way to manipulate the Document DOM on
Load?
Regards,
Matthias
--
View this message in context: http://xwiki.475771.n2.nabble.com/Inject-Warning-in-Page-when-Macro-in-Spac…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi All,
I want to create a component where i can overwrite a method of the component
from velocity or groovy script inside a wiki page. Its also fine if i can
"read" a groovy script to the component so i can use the defined logic.
Maybe i have to use a own programmed macro for that.
Is that possible? Do you use something similar somewhere?
Regards,
Matthias
--
View this message in context: http://xwiki.475771.n2.nabble.com/Overwrite-Method-of-Component-in-Velocity…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi,
Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274
Basically if you do $xwiki.getDocument("someDoc").getRenderedContent()
it'll get executed in the context of the current doc which I believe
is wrong especially since other signatures of getRenderedContent()
execute in the target document's context.
I have fixed this locally but found that admin.vm for example is
assuming that getRenderedContent() will get executed in the context of
the calling doc (i.e. XWiki.Import when doing an import for example).
FYI the chain flow is admin.vm -- getRenderedContent() -->
XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which
requires the current doc to be XWiki.Import (to get/put attachments
from/to it).
I can fix this easily using a new getRenderedContent signature I've
introduced.
However I'm wondering if we have other places that incorrectly use
getRenderedContent() and assume it won't be rendered in the context of
the target document.
Is this change too dangerous to make? If not know, we'll need to it
quickly (2.1M1?) since it's an important bug IMO.
WDYT?
Thanks
-Vincent