Hello.
In Flamingo, we have a variable called $displayPageHeader, defined in
layoutvars.vm.
When it is set, the logo is not displayed in the top menu, but on a header
under it. It is used by some clients, where they could also add some extra
content.
Example:
http://tof.canardpc.com/view/83040d2d-79c4-4f1b-ab1b-af8ee5f3be62.jpg
I'd like to expose this variable into the Flamingo Theme, see:
http://jira.xwiki.org/secure/attachment/33074/33074_preview.png
However, in order to enable the live preview in the theme editor, I need to
be able to change the value of the $displayPageHeader variable on the fly,
or at least by setting a parameter in the query string.
This variable will be:
displayPageHeader
Possible values:
"true", "false"
Default value:
Fallback to the Flamingo Theme, "false" if empty.
I don't have other use-case to cover with this variable.
Here is my +1.
Thanks,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
The XWiki development team is proud to announce the availability of XWiki
Enterprise 8.3.
This release introduces Recommended Extensions both on extensions.xwiki.org
and inside the Extension Manager. Other changes are page suggestions for
non-existing page, exporting child pages in XAR and HTML formats and many
more improvements. For developers, we added visibility and creation
restrictions on template providers and also Velocity templates can be
provided inside a JAR extension.
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/Data/XWiki/8.3/
Thanks for your support
-The XWiki dev team
Hi devs,
Today is release day for 8.3. I’d like to postpone it to tomorrow the 11th so that we can fix http://jira.xwiki.org/browse/CKEDITOR-113 which is a blocker.
I started debugging over the week end. I’d need some help though since I’m far from sure I’ll be able to fix it by myself. Would be great if at least one other dev could work on trying to fix it too at the same time.
WDYT?
Thanks
-Vincent
Something like this:
https://github.com/phenotips/phenotips/blob/b5fd2933480bcdeaca0194840b1c845…
On 10/04/2016 05:56 AM, Vincent Massol wrote:
>
>> On 04 Oct 2016, at 11:54, Pascal BASTIEN <pbasnews-xwiki(a)yahoo.fr> wrote:
>>
>> Thanks, you are right I forgot to removed solr subdirectory before upgrade.
>>
>> stop + rm + start xwiki = xwiki work again like a charm
>> (sorry ;-) )
>
> cool
>
> you don’t need to be sorry. We need to improve this. Like forcing automatically the removal when we upgrade solr and there’s been some schema changes.
>
> -Vincent
>
>> Thxs
>>
>> --- En date de : Mar 4.10.16, Vincent Massol <vincent(a)massol.net> a écrit :
>>
>>> De: Vincent Massol <vincent(a)massol.net>
>>> Objet: Re: [xwiki-users] Issues when I upgraded my xwiki 7.0.1 to xwiki 8.2.1: search feature
>>> À: "XWiki Users" <users(a)xwiki.org>
>>> Date: Mardi 4 octobre 2016, 11h36
>>> Hi,
>>>
>>> Try removing your solr index.
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>
>>> On 04 Oct 2016, at 11:26, Pascal BASTIEN <pbasnews-xwiki(a)yahoo.fr>
>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> After upgrading my
>>> xwiki 7.0.1 to 8.2.1, i encoutered another issue: xwiki
>>> search feature doesn't work anymore.
>>>> I use Tomcat 8.0.33 + Postrgesqk 9.3 and
>>> attachments in file system and connected with Admin
>>> account.
>>>>
>>>> On page
>>> ./bin/view/Main/Search?text=test&f_type=DOCUMENT&f_locale=fr&f_locale=&r=1
>>> , I have this ugly error message displayed:
>>>> "Failed to execute the [velocity]
>>> macro. Cause: [The resolver parameter doesn't contain an
>>> Entity Reference of type [SPACE]]. Click on this message for
>>> details."
>>>>
>> _______________________________________________
>> 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
>
--
Sergiu Dumitriu
http://purl.org/net/sergiu
Hi devs,
Right now (and since forever) the default behavior for templates is to
be executed with the right of the current document content author
(it's not really explicit, it's just how PR works when there is no
sdoc). This means that unless you explicitly indicate an author for
your template (possible since 7.x) you don't really have any idea
which right it's going to have at runtime. It also make harder to
properly execute templates outside of main rendering thread where the
"current document" often don't really make much sense.
I think we should make the default more stable.
I can think of two possibilities:
1) with what we got right now the only real possibility is to execute
the filesystem template with superadmin right (which is only an option
right now). Makes it consistent with the "code is executed with the
right of its author" rule we have for wiki pages
2) introduce some new virtual user (like "templateauthor" or
"scripter" or whatever) which only have script right and use that as
filesystem template author if we absolutely want template to not have
too many rights by default (even if modifying a filesystem template
require much more access than superadmin in practice)
+1 for 1)
--
Thomas Mortagne
Hi devs,
Question: do we agree to disable "show active installs" for extensions bundled in XE on e.x.o? (if I remember correctly that's why thomas introduced this checkbox but I want to make sure we have the same opinion)
The idea is not to drown the install figures with bundled extensions which are not chosen by users (they get them by default).
Right now we still have a few extensions that are bundled and have their install count displayed. I can fix it but I want to make sure first.
Also we need to decide what to do with contrib extensions bundled in XE. For example:
- Tour app
- CKEditor
- Templates app
I think we should also disable their active install count, following the same rule, even though they can also be installed by themselves in older versions of XE.
WDYT?
To see it:
http://extensions.xwiki.org/xwiki/bin/view/Extension/#|t=extensions&p=1&l=3…
Thanks
-Vincent
Hello all,
Alex and I have fixed a couple of issues on the batch import application
(issues BATCHIMP-1,2,3,4,5,6) and I would like to release version 1.2 of
this application.
Functionally, these changes bring translations being properly activated
when the app is installed, one more option configurable from the UI (clear
names) and some support for the new format of AWM (the nested spaces one).
It does not break compatibility, as I managed to write code that should
work fine in all cases (nested or not).
If nobody has anything against, I will release this tonight.
Thanks a lot,
Anca
Hi devs,
Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPra…
1) New rule 1: “Code” subspace
Current text:
* 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.
New version:
* 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.
* Technical pages should be put in a subspace named “Code”
Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.
2) New rule 2:
* Technical pages without children must be terminal pages.
WDYT?
Thanks
-Vincent