Hello everyone,
I've been following the onboarding tracks 1 and 2 on the past days, here is
what I can say:
The first track really helped me to get started in XWiki contributions as I
could easily pick a jira issue to work on. The issue description was clear
even though we had to discuss it on the chat. Speaking of the chat, it has
been a very valuable tool, people have been very responsive and I was
rarely stuck. I found the development practice a bit inconvenient at first,
having to make changes in the vm files of my XWiki instance and then report
the changes to the sources. I would have love to see a way to link my
source files (especially for vm/js/css files) with the one of my XWiki
instance to avoid errors when I copy past my changes (and get benefit of my
git ecosystem).
The second track is a good introduction to some XWiki concepts, I don't
have much to say for this one. A link to a real application could maybe
give a better understanding.
Thanks again for the help I had!
<http://www.xwiki.com/> *Adel Atallah*
*Product developer intern*
adel.atallah(a)xwiki.com <corina.luong(a)xwiki.com>
tel: +33 (0)6 12 96 35 06
Hi devs,
Some users have complained that the navigation panel shows top level pages
that they don't need/want to navigate to, most importantly the XWiki page.
There are multiple ways in which we can fix this.
Solution 1: Content Page
Create a top level "Content" page for user content and configure the
navigation panel to show the contents of this page.
Pros:
* Namespace isolation (no conflicts between user pages and application
pages)
Cons:
* The user may want to navigate to a top level application page (although
it's better to use the application panel for this instead)
* All the paths / references used to access the user content will start
with this "Content" page
Solution 2: Blacklisting
Add support for specifying a list of (top level) pages to exclude from the
navigation panel.
Pros:
* The user (top level) pages created later on will be visible in the
navigation panel
* The blacklist could be used to filter not only top level pages but also
any nested page from the navigation panel.
Cons:
* The blacklist depends on the installed apps. The administrator may have
to update the blacklist when new applications are installed
* The blacklist depends on whether you view hidden pages or not. If you
don't view hidden pages then the blacklist probably contains 4 pages: Help,
Menu, Sandbox, XWiki (there is an application panel entry for each of them
except XWiki), which is manageable. If you view hidden pages then you need
to black list 28+ pages which is hard to manage and maintain.
* The filtering needs to happen on the database (otherwise we break the
pagination) so the database queries will become a bit more complex, which
could led to some performance penalty, depending on how long the blacklist
is.
Solution 3: Whitelisting
Add support for controlling the list of top level pages that are displayed
in the navigation panel.
Pros:
* the whitelist doesn't depend on the installed extensions or hidden pages
so it's easier to maintain.
* the whitelist can be used to order the top level pages visible in the
navigation panel.
* the whitelist can be used to show at the top level (for navigation
purpose) a page that is not really a top level page
* No performance penalty
Cons:
* The user (top level) pages created later on will not be visible in the
navigation panel. The administrator will have to add them to the whitelist
if they are useful for the navigation. Although creating top level pages
should happen less often than creating nested pages under the existing top
level pages.
* the whitelist controls only the first level in the tree. The next levels
will be dynamic (database queries) and with the default order.
Solution 4: Exclude extension pages
Exclude from the navigation panel the top level pages that belong to an
installed extension, allowing the administrator to make some exceptions
(e.g. keep the home page). The rationale is that if an installed extension
has a top level page then that page is most probably the application home
page which should be accessible from the application panel. This can be
implemented on top of solution 3 (the whitelist is basically dynamic: we
collect the top level pages that don't belong to an extension).
Pros:
* It does a clear separation between applications (accessible from the
application panel) and content (accessible from the navigation panel). The
navigation panel is currently mixing application pages and (user) content
pages.
* The administrator doesn't need to update the navigation panel
configuration to exclude a top level application home page each time an
application is installed
* The hidden top level extension code pages are not shown even when "show
hidden pages" is set to true
* The user top level pages created later on appear in the tree automatically
Cons:
* The user won't be able to navigate easily to an application home page:
** if the application panel is not shown
** or if the application doesn't provide an application panel entry
** or if the administrator has removed the entry from the application panel
I prefer solution 4.
WDYT?
Thanks,
Marius
Hi all,
I'd like to request a repository for a new application allowing to create relations between pages and to show direct / inverse relations. It's similar to the use of links / backlinks except that in the case of this application, the links to other pages can be added as objects rather than in the content itself. Also, in the future, we may consider the option to name each relation, so as to have something similar to what RDF proposes.
Here's the name of the repository I would like to request, if you agree: "application-relations". I saw there was an issue with the JIRA contrib project template plugin, there's no need for a JIRA project right now.
Thanks a lot,
Stéphane
--
Stéphane Laurière
XWiki www.xwiki.com
+33 645 816 202 @slauriere
Hi,
I would like to publish an extension to add charts and statistics to
AppWithinMinutes.
Could I have the repo
appwithinminutes-charts
Thanks
Ludovic
--
*Ludovic Dubost*
*Founder and CEO*
ludovic(a)xwiki.com
skype: ldubost
Blog: http://blog.ludovic.orgTry XWiki on the cloud
<http://www.xwiki.com/en/products/try-xwiki-cloud> - Try Cryptpad: Secure
realtime Wysiwyg Editing <https://cryptpad.fr>
Hi devs,
When dealing with extension pages protection we ended up with a very
visible issue: EVERYONE customize the home page so it does not make
much sense to warn every user trying to edit it that it's dangerous
and might break the extensions.
Since it's not the only use case 10.3 introduce the concept of XAR
entry type which allow controlling a bit more edit/delete and upgrade
behavior. See http://extensions.xwiki.org/xwiki/bin/view/Extension/XAR+Module+Specificati…
for more details.
On component side it's possible to decide the default type of a page
reference (that's where "Main.WebHome" type come from currently). It's
also possible to override the upgrade behavior for a specific type or
even a specific reference for more exotic use cases.
So it's now possible to control the type you want for a page at XAR
descriptor level. I already typed a few page, for example
"Main.WebHome" is now of type "home" which means "it's OK to edit it
and you should only upgrade it if no customization have been made".
Cool home page is covered but we now entered a new era of endless
debates to decide of what type some page should be and what other
types to introduce :)
We are not going to discuss all these in this mail so everyone with a
doubt should start a discussion for a standard page (or a set of
standard page which are obviously very similar like color themes).
Currently, protected page produce a warning that you can force. The
plan in 10.4 is to keep the warning only for advanced completely
prevent basic user to modify protected pages by default and also allow
configuring all that (indicate in your profile that you don't want to
be bothered with that, override edit/delete right even for advanced
users, etc.). But before that we need to make sure basic users are
allowed to edit all the pages they are supposed to edit.
Happy tuning :)
--
Thomas Mortagne
Hi,
We have discussed this subject multiple times, but we don't have an
official vote and conclusion on the topic.
Problem: In JIRA who is the Assignee of an issue fixed by a Pull Request?
1: Contributor
- he provided the solution
- giving the attributions, the contributor might feel encouraged to
contribute more
- we could do some JIRA statistics on external contributions, but this use
case can be covered by GitHub statistics
2: Committer
- he does the merging on his account and he becomes responsible for the
committed code.
- in case there are problems, the committer needs to find solution, since
we can't rely on contributors availability
- in doing the PR review, the committer spends a lot of time analyzing and
testing the provided solution
We are talking here about complete solutions provided by the PR, since in
case of partial solutions, the committer can assign himself on the issue
(depends on the quantity of modification he does).
Let me know what you think,
Caty
Hi devs,
Hi Anca Luca especially :)
I have been working on some issues with the Publication Workflow
Application lately (on a branch called XAWORKFLOW-37 ... which ended up
containing several other fixes, too.)
I'd like to merge these fixes into the master and make a new release 1.9
soon, preferably near the end of the next week.
The list of fixes so far are in this list:
https://jira.xwiki.org/browse/XAWORKFLOW-20?jql=project%20%3D%20XAWORKFLOW%…
Also this will raise the required XWiki version to 7.2, mainly as I did
not want to test if it still works with a pre-"nested pages" XWiki :-/
Any objections? Or anyone sees the need and want to do a code review?
I am still in the process of testing if everything works with the latest
XWiki version (I had developed it against an old 8.0-instance that I had
lying around). I know a few folks who will test the release and I am
prepared to shoot out a 1.8.1 in case I seriously goofed up something. ;)
Thanks,
Clemens
Hello all!
My name is Vivek Iyer (github and Riot handle: Remorax) and I'm so grateful
for being selected as part of GSoC and I'm honestly looking forward to
contributing here!
My project for the summer is the Google Blockly Editor and to integrate it
with the current wiki and WYSIWYG editors. I plan to do this in four
stages:
- Firstly develop a small extension as test, so that I can build up on it.
- The second stage would be actually integrating a basic Blockly editor in
XWiki.
- The third stage would be adding custom blocks which generate the code for
functions which are most commonly used
- The fourth and the last stage would be making these blocks output
Velocity (or alternatively JS) code which would substitute the contents of
the div which would normally contain the manually written code.
Ideally, I plan on finishing stages 1 and 2 before the first evaluation,
stage 3 before the second evaluation and stage 4 before the final
evaluation.
As mentioned in my proposal, I'll be on vacation from 10th to 20th May and
won't have internet access so I'll be unable to contribute during that
period, but I'll surely make up for the lost time later on and get the work
done on schedule!
I've also kept buffer slots in between in case I run behind schedule.
I have also made a design on design.xwiki.org here:
http://design.xwiki.org/xwiki/bin/view/Google-Blockly-Editor/
Do check it out and let me know your opinions!
That's all from my side. I'm eager for your feedback and happy to receive
any suggestions as to where I could improve my current schedule.
Thanks and regards,
Vivek Iyer
Hello devs,
While I was trying the Ratings UI in the Iceberg color theme, I noticed
that the golden images of the stars might just not fit in any environment.
My main issue is that I am not able to change the stars' colors and it's a
pain to provide different images to override the existing ones.
I was looking for a solution to fit in both Silk(default) and Font Awesome
icon themes, using the Icon Service Renderer, but for the Silk's case the
issue will be the same since the output would be also represented by images.
So I would like to refactor the Ratings UI using the Font Awesome which
will provide the needed flexibility in changing the font and colors of the
icons.
Thanks,
Alex