I just finished a standalone installation of XE 1.8 on a Windows XP SP3
system. For some reason the main Wiki Dashboard does not display correctly
in Firefox or in IE (although, oddly, it is slightly better in IE). Please
see the attached image. Other parts of the wiki seem to be fine. I would
appreciate any help.
Thanks,
Josh Eastburn
SAES Pure Gas, Inc.
SLO, CA
Hi,
I'm new to Xwiki and am using an Xwiki Enterprise 1.7.2 with multiple
spaces. I just migrated this wiki from another organization that was
using version 1.4.2 (in case that makes a difference in my question).
Environment: apache centos 5.2/tomcat 6/mysql 5.1 - I searched mailing
lists, google and xwiki site but found no leads yet.
The migration went well and now I've added a new public space. The
wiki as a whole denies all rights except 'Register' for unregistered
users. But the new space grants 'View' access to unregistered users.
View access is working fine *except* none of the panels appear for
unregistered users and I wanted at least one to show by default - the
one that lists all the pages in the space. how can I let unregistered
users see this without logging in?
Thanks,
Cris
Hello,
I am student of master program in informatics at Brno University of
Technology, Czech Republic. There is a
short list of experience I can provide to make your project better:
- Java is my primary language for more than 5 years,
including JPA (Hibernate), JTA and web development
(JSP, Struts, Stripes, Freemarker templates)
- very good experience and knowledge about compilers
- good knowledge of XML background such as XSLT, XSD, XPath and
XQuery
- basic knowledge about semantic web (RDF, OWL, Jena, Sesame)
During my bachelor program I defended (in year 2008) thesis called
Native XML databases http://www.fit.vutbr.cz/study/DP/BP.php.en?id=7006
(in Czech, abstract in English), which basically was an comparison of
two portals of Wikipedia, the first based on Stripes, JPA (Hibernate)
and PostgreSQL, the other on eXist and Apache Coocon, both deployed an
JBoss application server, considering the speed (both of application and
development) and developers experience of both solutions.
There very same year I wrote fully compliant CSS 2.1 parser
http://cssbox.sourceforge.net/jstyleparser, part of CSSBox project for
semantic recognition of web pages. This parser uses ANTLR as parsing
layer.
Currently I am doing some minor work on Czech linux portal
http://www.abclinuxu.cz, which is based on Java servlets with Freemarker
templates.
I can provide my CV, references and more detailed description upon
request.
What I would like to do for XWiki?
My current focus in studying is towards artificial intelligence, which
can be applied to same heuristic optimization, but I'm mainly interested
in JSR 168, because the idea suspects good project design. Another very
interesting proposal from my point of view is Improved fetching for
XWiki Watch, as the proposal expect me to do both module desing and some
semantic recognition and content parsing and any work considering some
parsing and compilers will fit to my profile.
By the way, I'll be at XML Prague during this weekend. If any developer
participates, I would be nice to discuss ideas face to face.
Looking forward to hearing from you.
Best regards,
Karel Piwko
The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.8 and XWiki Enterprise Manager 1.6.
This is the final 1.8 version.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
Changes from 1.7:
-------------------------
* First usable version of new rendering and new WYSIWYG editor
* New Wiki Dashboard
* New way of displaying tags
* Page loading time reduced by 30%
* Improved information section in document footer
* By default the authentication system now calls the authenticator
only once by session
* Updated french translation
* Updated german translation
* Updated spanish translation
Important bug fixes:
--------------------------
* Scaled images in exported PDF and RTF have wrong dimensions
* When a wiki is removed, it's not removed form the cache
* Including a document with first or second heading level breaks the
including document section edit link
* PDF export does not take into account the encoding specified in xwiki.cfg
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise18
Thanks
-The XWiki dev team
Ari Oinas wrote:
> - Scandinavian characters in pageIds don't seem to work
This should work, provided you set the right encoding. By default XWiki
comes with ISO-8859-1, but you should change it to UTF-8 (we're planning
to do this by default in 1.9).
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi xwiki-users,
When attempting to include an inline form in XWiki Syntax 2.0, the resulting
page always gets wrapped in a {pre} tag. It says this was to prevent
further rendering of the form, but this doesn't work too well with the 2.0
syntax since {pre} is not a valid tag (just renders it as a literal string).
I just created a custom form (using the {{html}} tag), but what is the
preferred way of creating inline forms using the 2.0 syntax? Is this (
http://jira.xwiki.org/jira/browse/XWIKI-2891) the JIRA that tracks this
issue?
Also, I'm not 100% certain, but it also seems that a "#includeForm(" needs
to exist in order for the default "edit" mode to enter inline editing (I
think viewheader.vm is used to render the top panel... and there's a check
[#if($doc.content.indexOf("includeForm(")!=-1)], which probably detects
this) - again, will this still hold true in the 2.0 syntax?
Thanks in advance!
-- Lewis
Ari Oinas wrote:
>> Thanks for your feedback. I would be glad to know a bit more about what you
>> were looking for, which wikis you tried and what made you choose XWiki
>> rather than another system. This would help us understand better what makes
>> XWiki stand out and what it lacks compared with other platforms.
>> If you've got a little time, do you think you could tell us a bit about
>> that?
>> Many thanks in advance,
>> Guillaume
>>
>
> Ok, here's a small list of reasons why I chose Xwiki and not some other
> wiki.
> Before I begun searching for suitable wiki, I gathered a list of
> requirements that a wiki must have.
> Wikis that I tested or studied were: MediaWiki, TikiWiki, Xwiki and
> Confluence. Maybe some others too, but I don't remember ;)
>
> Here is that list and how different wikis fulfill those requirements:
>
> Requirement 1: Ability to transclude pages and sections of pages in other
> pages
> MediaWiki: Yes, support page transcluding natively and section transcluding
> can be added with plugin
> Xwiki: Supports page transcluding. Section macro was easy to do, and I got
> to do it just the way I like it :)
> Confluence: I think it supports transcluding. Not tested it though.
>
> Requirement 2: Support for hierarchical information ( tree-like )
> MediaWiki: Very bad. Can be achieved using categories, but because Category
> is a namespace, category names must be unique which was unacceptable in
> mycase.
> Xwiki: Very flexible. Namespaces ( Spaces in Xwiki ) are easy to create and
> pages can be ordered hierarchically using page's parent -field.
>
> Requirement 3: Support for content localization/translation
> Mediawiki: None. AFAIK every language needs it's own Wiki.
> Xwiki: Built-in. Creating translated content is easy. Functions to retrieve
> translations still needs work, but are good enough to get the job done.
>
> Requirement 4: Flexible, easy to maintain user rights
> Mediawiki: User right management very restricted. Better with plugins but
> still poor.
> Xwiki: Superb! Very easy, yet powerful way to handle user rights. I really
> liked that user right has 3 options: allow, deny, neutral. This combined
> with user groups and spaces makes user rights management very enjoyable.
> TikiWiki: Frustratingly detailed. Has some very powerful features, but list
> of about 100 different user right parameters is very frustrating. (This
> opinion is based on very quick tests)
>
> Requirement 5: Ability make offline HTML dumps of wiki content
> MediaWiki: Possible (maybe with a plug-in, I don't remember)
> Xwiki: Supported natively. Yet, I decided to make my own XML Dump program
> which fetches content through XML/RPC interface.
>
>
> And now a list of pros and cons for every wiki I tested:
>
> Mediawiki:
> + Widely used, lots of help available
> + lots of plugins
> - hierarchical information support very bad
> - user right management limited and hard to comprehend
>
> TikiWiki:
> + Lots of features
> - User interface looks clumsy and is difficult to use ( maybe because I
> tested Xwiki just before this ;)
> - User rights management is overwhelming
>
> Confluence: ( not tested, opinions based on what I read about it)
> + seems finalized
> + used widely in enterprises and universities
> + XML/RPC interface
> - PRICE
>
> Xwiki:
> + Very slick UI
> + Macros / Programming capabilities
> + XML/RPC interface
> + User rights management
> + customer support
> - Seems in many ways incomplete/work in progress
> - Documention is scattered across the internets / help is very hard to find
> using Google. Most searches end up in Xwiki JIRA-pages.
> - Xwiki documentation pages seem disorientating. Even if I know theres some
> useful info there, it takes me 15mins to find it. (DevGuide, dev.xwiki.org,
> xwiki.org/Features)
> - Example:
> http://xoffice.xwiki.org/xwiki/bin/view/CodeBase/XmlRpcProxy and
> http://platform.xwiki.org/xwiki/bin/view/Features/XMLRPC, so similar, yet in
> totally different places
>
The XmpRpcProxy page was created after you sent your first mail. I
published that page, as a result of your mail, so that it potentially
helps you. As you can see the notes in the page, it is only a draft.
When completed(fully maps the xml-rpc model&api) it will be linked/added
to the platform page.
> - Scandinavian characters in pageIds don't seem to work
>
>
> I hope these lists are helpful to you. Despite some criticism I presented
> here, you have developed an amazing wiki. I think you should focus a little
> more on making documentation easy to find and read even for someone who is
> just starting to code or otherwise noob (such as me ;). Now it gives an
> impression that you have to be Linux-expert/super-coder/uber-nerd to be able
> to set up wiki and program it (which you don't need to be, it's actually
> quite simple).
>
> Best regards,
>
> Ari
>
>
>
>
>
>
>
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
>
Hi Ari,
On Fri, Mar 20, 2009 at 10:00 AM, Ari Oinas <ari.oinas(a)jidea.fi> wrote:
>
> >Thanks for your feedback. I would be glad to know a bit more about what
> you
> >were looking for, which wikis you tried and what made you choose XWiki
> >rather than another system. This would help us understand better what
> makes
> >XWiki stand out and what it lacks compared with other platforms.
> >If you've got a little time, do you think you could tell us a bit about
> >that?
> >Many thanks in advance,
> >Guillaume
>
> Ok, here's a small list of reasons why I chose Xwiki and not some other
> wiki.
> Before I begun searching for suitable wiki, I gathered a list of
> requirements that a wiki must have.
> Wikis that I tested or studied were: MediaWiki, TikiWiki, Xwiki and
> Confluence. Maybe some others too, but I don't remember ;)
>
> Here is that list and how different wikis fulfill those requirements:
>
> Requirement 1: Ability to transclude pages and sections of pages in other
> pages
> MediaWiki: Yes, support page transcluding natively and section transcluding
> can be added with plugin
> Xwiki: Supports page transcluding. Section macro was easy to do, and I got
> to do it just the way I like it :)
> Confluence: I think it supports transcluding. Not tested it though.
>
> Requirement 2: Support for hierarchical information ( tree-like )
> MediaWiki: Very bad. Can be achieved using categories, but because Category
> is a namespace, category names must be unique which was unacceptable in
> mycase.
> Xwiki: Very flexible. Namespaces ( Spaces in Xwiki ) are easy to create and
> pages can be ordered hierarchically using page's parent -field.
>
> Requirement 3: Support for content localization/translation
> Mediawiki: None. AFAIK every language needs it's own Wiki.
> Xwiki: Built-in. Creating translated content is easy. Functions to retrieve
> translations still needs work, but are good enough to get the job done.
>
> Requirement 4: Flexible, easy to maintain user rights
> Mediawiki: User right management very restricted. Better with plugins but
> still poor.
> Xwiki: Superb! Very easy, yet powerful way to handle user rights. I really
> liked that user right has 3 options: allow, deny, neutral. This combined
> with user groups and spaces makes user rights management very enjoyable.
> TikiWiki: Frustratingly detailed. Has some very powerful features, but list
> of about 100 different user right parameters is very frustrating. (This
> opinion is based on very quick tests)
>
> Requirement 5: Ability make offline HTML dumps of wiki content
> MediaWiki: Possible (maybe with a plug-in, I don't remember)
> Xwiki: Supported natively. Yet, I decided to make my own XML Dump program
> which fetches content through XML/RPC interface.
>
>
> And now a list of pros and cons for every wiki I tested:
>
> Mediawiki:
> + Widely used, lots of help available
> + lots of plugins
> - hierarchical information support very bad
> - user right management limited and hard to comprehend
>
> TikiWiki:
> + Lots of features
> - User interface looks clumsy and is difficult to use ( maybe because I
> tested Xwiki just before this ;)
> - User rights management is overwhelming
>
> Confluence: ( not tested, opinions based on what I read about it)
> + seems finalized
> + used widely in enterprises and universities
> + XML/RPC interface
> - PRICE
>
> Xwiki:
> + Very slick UI
> + Macros / Programming capabilities
> + XML/RPC interface
> + User rights management
> + customer support
> - Seems in many ways incomplete/work in progress
> - Documention is scattered across the internets / help is very hard to find
> using Google. Most searches end up in Xwiki JIRA-pages.
> - Xwiki documentation pages seem disorientating. Even if I know theres some
> useful info there, it takes me 15mins to find it. (DevGuide, dev.xwiki.org
> ,
> xwiki.org/Features)
> - Example:
> http://xoffice.xwiki.org/xwiki/bin/view/CodeBase/XmlRpcProxy and
> http://platform.xwiki.org/xwiki/bin/view/Features/XMLRPC, so similar, yet
> in
> totally different places
> - Scandinavian characters in pageIds don't seem to work
>
Thanks a lot for the feedback :-)
> I hope these lists are helpful to you. Despite some criticism I presented
> here, you have developed an amazing wiki. I think you should focus a little
> more on making documentation easy to find and read even for someone who is
> just starting to code or otherwise noob (such as me ;). Now it gives an
> impression that you have to be Linux-expert/super-coder/uber-nerd to be
> able
> to set up wiki and program it (which you don't need to be, it's actually
> quite simple).
>
We're aware our documentation can be improved. We wanted to work on
improving XWiki.org, but it got delayed with the release of XWiki Enterprise
1.8 taking most of our time. If you've got a little time, we'd be very happy
to have you contribute the program you wrote on http://code.xwiki.org/ and
improve the documentation in places where you found it confusing (adding
details / links where needed). All you need to do this is an account on
xwiki.org and then, well, it's a wiki ;-)
Guillaume
Best regards,
>
> Ari
>
>
>
>
>
>
>
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
Hi Ari,
On Thu, Mar 19, 2009 at 12:48 PM, Ari Oinas <ari.oinas(a)jidea.fi> wrote:
> Some other improvements also came to mind:
> - Search -method should also have ability to set language
> - It would be nice if search -method could also search rendered contents.
> For example if I have a macro on one page, which trancludes text from
> another page, page containing the macro doesn't show in search results. I
> think that this feature is very hard to implement very efficiently. And
> theres definitely should be possibility to turn it on or off. Maybe it
> would
> require a "copy" of renderedContent to be stored on the database and thus
> increases database size.
> - Util class should contain function to strip HTML-tags from string.
>
> There is much of small things that need to be fixed in Xwiki to make it
> "perfect", but it's a pretty good and flexible already.
> I evaluated about 5 different wiki-systems before I decided to go with
> Xwiki. Every wiki had some constraints which rendered them useless for my
> needs, but Xwiki was the most flexible system.
Thanks for your feedback. I would be glad to know a bit more about what you
were looking for, which wikis you tried and what made you choose XWiki
rather than another system. This would help us understand better what makes
XWiki stand out and what it lacks compared with other platforms.
If you've got a little time, do you think you could tell us a bit about
that?
Many thanks in advance,
Guillaume
>
>
> Keep up the good work!
>
> Cheers,
>
> Ari
>
>
> -----Original Message-----
> From: users-bounces(a)xwiki.org [mailto:users-bounces@xwiki.org] On Behalf
> Of
> Fabio Mancinelli
> Sent: 19. maaliskuuta 2009 13:09
> To: XWiki Users
> Subject: Re: [xwiki-users] Translations cannot be fetched using XML/RPC
> interface
>
>
> On Mar 19, 2009, at 8:48 AM, Ari Oinas wrote:
>
> > Hi,
> >
> > And thanks for your efforts regarding this issue. I found the
> > problem which
> > caused my translations not to work.
> >
> >
> Happy that you solved your problem.
>
> > Still, some things to consider:
> >
> > - should renderContent function also handle pageId so that language
> > could be
> > embedded in the end of pageId? Same way as getPage handles pageId.
> >
> > - getPages function returns PageSummaries with default language
> > pageTitles.
> > It would be convenient to call this function with language id, so that
> > pagetitles would be in correct language. Now I have to loop through
> > every
> > pagesummary and get page title to get correct pageTitles to show on
> > navigation tree.
> >
> Thank you for spotting these improvements.
> I will open Jira issues in order to add these feature in the next
> release.
>
> > Thanks for superb customer support!
> >
> You are welcome.
>
> Cheers,
> Fabio
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/users
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/