At last! Good news :)
-Vincent
On 4 Jun 2014 at 13:40:19, noreply(a)ckeditor.com (noreply@ckeditor.com(mailto:noreply@ckeditor.com)) wrote:
> Hi vmassol,
>
> wiktor has commented on: "Where are the sources for CKBuilder?"
>
> ----
> Apologies for taking so long to publish it. We had a plan to rewrite
> CKBuilder to node.js, but after realising that it would be a pretty
> time-consuming task, we've decided to postpone it till CKEditor 5. After
> cleaning up the code, documentation etc. the source files are finally
> available:
>
> https://github.com/ckeditor/ckbuilder [1]
>
> Thanks for your patience!
>
> ----
>
> You can view the comment at the following url
> http://ckeditor.com/comment/132339#comment-132339
Hi devs,
I’ve noticed a recurring trend from our users: a lot of them seem to wish to display Tree views/navigation view of their wiki pages either in page content or in a panel.
When they go to e.x.o, there’s a lot of extensions listed (showing that other users had this need previously) but none really work well:
http://extensions.xwiki.org/xwiki/bin/view/Extension/WebHome#|t=extensions&…
We do have a tree view in AllDocs but it’s not perfect and it’s not easily reusable.
Thus I believe we need to find an official solution to this tree view issue.
The easiest solution could be to create a wiki macro based on our current tree view so that it can be reused in wiki pages and more importantly in a panel. Having a “spaces” parameter to restrict the list of spaces to display would be nice too.
WDYT?
Any other idea?
Thanks
-Vincent
Good evening,
We have discussed recently about the necessity of having a new Color Theme
Editor for Flamingo. Some of you have suggested to try to integrate in
XWiki an existing Bootstrap Customizer such as FancyBoot:
http://fancyboot.designspebam.com/
After looking on Google and Github, I could not find any that matches this
criterias:
- Bootstrap 3 support
- active
- compatible with an XWiki integration
That is why I propose to write our own, which could actually take some code
from existing projects.
On my side, I have written 2 prototypes and I have pushed them in a new
github repository:
https://github.com/xwiki-contrib/bootstrap-customizer-prototypes
Prototype A
====
Demo:
http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeA/
(chrome users: please refresh the page if you do not see a color picker
when you click on an input box)
This prototype opens a real web page inside an iframe, and use the LESS
browser compiler to update the CSS.
Pros:
- it uses LESS so it shows the **real** results
- any wiki page can be seen in the preview frame
- not so hard time to implement
Cons:
- it is quite slow, and sometimes the browser gets frozen for a few seconds.
Prototype B
====
Demo:
http://xwiki-contrib.github.io/bootstrap-customizer-prototypes/prototypeB/
This prototype emulates the behaviour of LESS when we change some
variables. The results is displayed in a preview box, but it is a fake one.
Pros:
- The prototype runs quickly in the browser because there is no LESS
compiler involved.
Cons:
- The preview box is not a real page and it cannot show all use-cases.
- Will take more time to implement and to maintain because we have to
manually emulate what LESS would do in the preview box.
I'm +1 for Prototype A.
What do you think?
Thanks,
Guillaume
Hi Devs,
I have a loop in which i add object to all documents under the space
"Main", it crashes in the middle of the loop ...
##get all document in the Main space
#set($docus = $xwiki.getSpaceDocsName("Main"))
#foreach($docu in $docus)
#set ($myDoc = $xwiki.getDocument("Main", $docu))
$myDoc.getFullName()
##Add object to the page
#set($obj = $myDoc.newObject("Revision.RevisionClass"))
$obj.set("approvedRev", $myDoc.getVersion())
## Save the object in the page
$myDoc.getDocument().setMetaDataDirty(false)
$myDoc.getDocument().setContentDirty(false)
$myDoc.save()
#end
Stack is attached
Please any method to catch the exception and let it go in Velocity
Thanks in advance :)
Hi community
I need a method which return all documents under a specific space, a
deperecated method if possible, cuz i'm working on 4.4 actually,
Thanks in advance :)
Hi devs,
I’ve worked with Lyes to define a new mail sender API.
We’ve put it here:
http://design.xwiki.org/xwiki/bin/view/Proposal/MailModule
Our idea is to:
- implement this in XWiki Platform in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-sender. In the future we’ll be able to have xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-reader if we want. At some point we should also move the Mail configuration UI in xwiki-platform-core/xwiki-platform-mail/xwiki-platform-mail-ui.
- deprecate the mailsender plugin and once all our code has been updated to use this new API, move the plugin to xwiki-contrib.
Please let us know what you think about both the API and the plan.
Thanks
-Vincent
Hi devs,
In notification emails, the link of modified document is like :
localhost:port, in the template script i found $event.getUrl().
How can i change in order getUrl return the right URL and not localhost
Thanks in advance :)
Hi Community,
I'm migrating all our content from XWIKI 4.4 to XWIKI 5.4.5.
I use admin tools to export/import large content, it's a very good tool,
almost all documents are imported successfully.
but now in order to have the approved revision functionality i must have
the version "1.1" for all imported document.
Can i tell Admin tools to override version to "1.1" ?
Thanks in advance :)
Hi devs,
Right now our practice in XWiki Platform for the apps we develop is to move to storing all the pages of an app in a single space.
See http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra…, specifically:
“
Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.
"
Now there are potentially some use cases that may warrant to have 2 spaces: one for the content documents and one for the technical documents:
- ability to easily set permissions on all technical pages so that only a group of person can modify them but allow another group of persons to edit the content pages (e.g. for the Blog application)
- easier to remove all the content pages of an app but still keep the app working
So one idea would be systematically have 2 spaces for apps:
- one XXX space (e.g. Blog space) for holding content pages
- one XXXCode space (e.g. BlogCode space) for holding technical pages
Of course all technical pages are hidden and thus the XXXCode space will not appear in the list of spaces or searches by default.
WDYT? Would you be ok to modify all our existing apps to go in that direction?
Note: A future solution is to use nested spaces but even with nested spaces the need for 2 spaces would be the same. We would just need to make the XXXCode space a subspace of the XXX space (assuming we can set permissions on subspaces ;)).
Thanks
-Vincent
Hello,
I used admin tool to export the whole wiki from XWIKI 4.4 and i did the
import in XWIKI 5.4.5
The result wasn't perfect i have some link which still refer to the old
wiki,
Please, another tools to try ? should try some other script out there?
Thanks in advance :)