Hi devs,
A user has reported the following, mentioning it was taking a lot of steps, and we’ve all experimented that creating wiki links could be easier:
“
1. Go to page you want to link to (Target Page).
a. Copy URL
2. Go to page where you want to add the link (Source Page)
3. Edit it using Wiki Syntax Editor
4. Create the link
i. Write [[
ii. write label
iii. write >>
iv. paste the link pointing to Target Page
v. Remove https://w.amazon.com/bin/view from pasted link
vi. Replace manually all encoded URL strings (like + and other symbols)
vii. Replace “/” with “.”
viii. Add WebHome
ix. write ]]
5. Save
6. Done.
"
So I’d like to brainstorm about what we could do to make it easier to creating wiki links.
Some ideas:
A) Remove step 4. ix with http://jira.xwiki.org/browse/XWIKI-12920
B) The label>> parts (steps ii and iii) can be omitted, especially when the link label generation is configured to use titles
C) The real solution for me is autocomplete on links: http://jira.xwiki.org/browse/XWIKI-206 This should probably be implemented in the autocomplete extension: see http://extensions.xwiki.org/xwiki/bin/view/Extension/AutoCompletion+API and http://extensions.xwiki.org/xwiki/bin/view/Extension/AutoCompletion+Applica…
D) Using CTRL+G helps since it provides the reference and helps in finding the page to link to. It can be considered as a simplified autocomplete, ie a simplified impl for C).
E) Marius mentioned elsewhere: "I would also like to have a common Insert Link dialog between the CKEditor and the Wiki Editor. You click on a button on the tool bar, you get a dialog where you can search for the target page (or select it from the tree) and then click Insert, which will generate the wiki syntax for your. The Insert Link dialog can have a shortcut key for quick access. Of course autocomplete is nicer but it's more work, while the Insert Link dialog is a must for the CKEditor anyway.”
F) Marius mentioned elsewhere: "We can also implement a dedicated "Insert Reference" dialog for the Wiki Editor that offers a text input where you can paste an URL and the dialog attempts to extract the entity reference from the URL and inserts it in the Wiki Editor text area to be used for links but also for macros or anywhere where you might need a document reference. This can be implemented as an XWiki extension.”
G) Add the ability to paste a full URL in the reference part of wiki links and upon save the Rendering will automatically transform it into a document reference if it’s a local link. And if you want a real url for a local link then you’d need to use the “url:” prefix. Implementation: One relatively simple solution is to parse the URL (using a ResourceTypeResolver/ResourceReferenceResolver) and then serialize it and verify if the result matches the passed URL. If it does it means it’s a local URL.
H) Caty mentioned elsewhere: "We could display the reference of a page in:
a. a Permalink dialog (containing the URL + reference) that the user can copy paste in browser input or editor
b. Information tab
c. other?”
IMO the best (possibly not the easiest) are C) and G). With those 2 we would get:
* easy pasting of existing URLs
* easily finding the page you want to link to when you don’t have its URL
Now, even if we agree to do C) and G) in the future I still think that all the other ideas (ie. E, F and H) could also be implemented.
WDYT?
Thanks
-Vincent
Hello all,
Since http://xwiki.markmail.org/thread/jrug6cbbqpia5bx4 (but not only) the
rule says that we should discuss contrib related stuff with the community.
In my case, I cannot manage to follow all the mails on the devs(a)xwiki.org
(because they are a lot) but I would be particularly interested of not
missing the ones about contrib extensions. However, today, I don't know how
to differentiate them, I would need to read all devs(a)xwiki.org to not miss
one.
There are multiple solutions that I can propose for this, please let me
know what you think:
1/ have a contrib mailing list
2/ have an alias for the contrib that would send on the same list, this way
we could filter by the "to" field
3/ have a convention about mails related to contrib (e.g. [Contrib] in the
subject) that would allow to filter
4/ any other technical solution that I didn't think about that would allow
to automatically decide if a mail is about contrib or not, without reading
it :D
1, 2 and even 4 are perfectly fine with me, 3 is a bit risky because people
might not follow conventions.
What do you think?
Anca
Hi everyone,
I’d like to give everyone some heads up about the plan I discussed with Marius (who’s working on the new CKEditor integration) regarding the new CKEditor-based WYSIWYG.
Goals:
======
* Replace the current GWT-based WYSIWYG editor with one based on CKEditor, see http://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration
* Keep it as an extension so that it can be installed using the Extension Manager on XWiki versions 7.4.x. We need to introduce some UIXP to be able to replace the existing editor in the XWiki menus so we’ll need to commit that in 7.4.x (with x >= 2).
* Make it possible to install the extension on XWiki versions 6.2.5+. However the installation will have some manual parts, to replace the GWT-based editor.
Timeline:
=========
* Before the 19th of Feb, a new version of the CKEditor integration will be released containing wiki page/attachment linking and image insertion features. At that point what will remain is:
** Support for editing macros
** Office importer (if needed)
** Configuration UI in the administration
** Add UIXP to integrate the CKEditor nicely into the platform (using extension points)
** Future: Add support for packaging CKEditor plugins as XWiki Extension.
* The goal is to implement all these remaining features around when 8.1M1 is released (i.e. early April 2016), except maybe the Future part which could be done later on.
* Starting 8.1M2, the goal would be to bundle the Extension in the distribution (default flavor) but to not make it the default yet. There would be some configuration option to select which WYSIWYG editor to use (GTW-based or CKEditor-based).
* Starting 8.2, if all goes alright, we would set the CKEditor WYSIWYG to be the default (still with ability for admins to configure the editor they wish to use so they can continue to use the GWT-based one if they want that).
* Starting 9.0, the idea would be to remove the GWT-editor and retire it to XWiki Contrib with instructions for advanced developers to build it and use it in XWiki should they still want to do that. However we won’t spend extra time to refactor it as an extension since that would spend too much time which we prefer to spend on improving the new WYSIWYG editor.
WDYT?
Thanks
-Vincent
PS: cc-ing the users list to let the XWiki users know about the plan ahead of time!
I'd like to cut a bugfix release for MoccaCalendar quite soon, probably on Monday next week if I find the time, or Tuesday if I miss out on Monday
This will contains all fixes that are b/w compatible without nested spaces.
The idea is to have this bugfix release our before the decision on dropping support for pre-nested pages is made, as this discussion is still in pending (slumbering?) mode.
The release will be 2.5.2, and will be released from the stable-2.5 branch
Issues fixed so far:
http://jira.xwiki.org/browse/MOCCACAL-99?jql=project%20%3D%20MOCCACAL%20AND…
Translators: please note that one translation has changed and might need to be updated:
MOCCACAL-95 : Change Calendar's home page to be named "Calendar" instead of "Calendar overview" <http://jira.xwiki.org/browse/MOCCACAL-95>
The translation key to be updated is 'MoccaCalendar.calendar.title':
http://l10n.xwiki.org/xwiki/bin/view/L10N/Search?application=Contrib&name=M…
Any objections, comments?
Clemens
I have XWiki and a separate app. I need to use my app permissions in XWiki.
XWiki uses security cache and asks my app for a particular permission only
once. I need to make XWiki aware about permission changes in my app.
I have several options:
1. sometimes I invalidate cache in my application. I could call xwiki api to
invalidate the whole xwiki cache when I invalidate my app cache.
2. from time to time (say, every minute) make a REST call to my app. My app
says if cache was invalidated. If it was I would like to invalidate xwiki
cache.
My questions are:
1. how to invalidate the whole cache? I implemented
CustomSecurityCacheInvalidator, but it seems like I can remove only separate
entities there via `remove` call. As I understand I have to call `suspend`
and then remove entities from the cache and then call `resume`, right? But
SecurityCache has only `get` and `remove` methods for separate entities.
2. should I create a separate `Component` for scheduler which will poll data
from my app from time to time? I could start new thread there to ask my app
on schedule and Inject CustomSecurityCacheInvalidator. Is it the right
approach?
My class is here:
@Component
@Singleton
public class CustomSecurityCacheInvalidator extends
DefaultSecurityCacheRulesInvalidator {
@Inject
private SecurityCache securityCache;
@Override
public void suspend() {
System.out.println("suspend!");
super.suspend();
//I can use securityCache here
}
@Override
public void resume() {
System.out.println("resume!");
super.resume();
}
}
--
View this message in context: http://xwiki.475771.n2.nabble.com/How-to-invalidate-security-cache-tp759913…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
The XWiki development team is proud to announce the availability of XWiki 7.4.3.
This is a bugfix release that fixes important bugs discovered in the 7.4.2 version.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki743/
The following people have contributed code to this release (sorted alphabetically):
Alexandru Cotiuga
Clemens Robbenhaar
Ecaterina Moraru (Valica)
Eduard Moraru
Guillaume Delhumeau
Marius Dumitru Florea
Thomas Mortagne
Vincent Massol
Thanks for your support
-The XWiki dev team
The XWiki development team is proud to announce the availability of XWiki
8.1 Milestone 2.
This milestone release brings a new parameter to the Document Macro, the
synchronization of the avatars coming from LDAP and the support of feeds
delivered over HTTPS in the RSS Macro.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki81M2
The following people have contributed code to this release (sorted
alphabetically):
- Alexandru Cotiuga
- Clemens Robbenhaar
- Eduard Moraru
- Guillaume Delhumeau
- Lukas Raska
- Manuel Smeria
- Marius Dumitru Florea
- Thomas Mortagne
- Vincent Massol
- Yuri Konotopov
Thanks for your support
-The XWiki dev team