Nabble - Magnolia - Dev

[JIRA] Commented: (MAGNOLIA-2671)
2009-11-27T06:56:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25146#action_25146 ]

Oliver Knorr commented on MAGNOLIA-2671:
----------------------------------------

Hello Jan,
I just tried this, and you are right! To be more precise, the problem exists, if the {{cmsu:simpleNavigation}} is nested insided the {{cms:contentNodeIterator}} tag (in my case, it's part of a special paragraph). If I put the same {{cmsu:simpleNavigation}} before the opening tag of {{cms:contentNodeIterator}} or after its closing tag, it works fine.

> <cmsu:simpleNavigation relativeLevels="true" fails
> --------------------------------------------------
>
> Key: MAGNOLIA-2671
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2671
> Project: Magnolia
> Issue Type: Bug
> Components: taglibs
> Affects Versions: 4.0.1, 4.1.1
> Environment: Windows Vista Business SP1
> JDK 1.6.0_11
> apache-tomcat-5.5.26
> magnolia-bundled-webapp-4.0.1.war
> Reporter: Oliver Knorr
> Assignee: Fabrizio Giustina
> Fix For: 4.2.x
>
>
> After upgrading from Magnolia 3.6.3 to 4.0.1, the tag {{<cmsu:simpleNavigation relativeLevels="true" startLevel="0" endLevel="1" />}} does not print out the list of subpages anymore.
> Like with MAGNOLIA-2669, the problem seems to be caused by the changes for MAGNOLIA-2642 as it disappears for me when I revert Resource.java to the previous revision from http://svn.magnolia-cms.com/view/community/magnolia/trunk/magnolia-taglib-cms/src/main/java/info/magnolia/cms/taglibs/Resource.java?revision=21024

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MGNLDATA-93) Introduce generics into the parts where they are still missing and cleanup the code

2009-11-26T07:58:36Z

[ http://jira.magnolia-cms.com/browse/MGNLDATA-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25131#action_25131 ]

Hudson CI server commented on MGNLDATA-93:
------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia-module-data #485|http://hudson.magnolia-cms.com/job/magnolia-module-data/485/]
Generics and code cleanup ... using google-collections this time around.

> Introduce generics into the parts where they are still missing and cleanup the code
> -----------------------------------------------------------------------------------
>
> Key: MGNLDATA-93
> URL: http://jira.magnolia-cms.com/browse/MGNLDATA-93
> Project: Magnolia Data Module
> Issue Type: Task
> Affects Versions: 1.4
> Reporter: Jan Haderka
> Assignee: Jan Haderka
> Fix For: 1.4.1
>
>

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2910) Preserve DMS specific versioning command upon workflow installation

2009-11-26T06:45:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25130#action_25130 ]

Jan Haderka commented on MAGNOLIA-2910:
---------------------------------------

To solve your issue if occurs in versions earlier then 4.2.1, you have to change the command back manually - go to config:/modules/dms/commands/dms/activate and change value of class from info.magnolia.module.admininterface.commands.VersionCommand to info.magnolia.module.dms.commands.DocumentVersionCommand

> Preserve DMS specific versioning command upon workflow installation
> -------------------------------------------------------------------
>
> Key: MAGNOLIA-2910
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2910
> Project: Magnolia
> Issue Type: Bug
> Components: workflow
> Affects Versions: 4.0.3, 4.1.1, 4.2
> Reporter: Jan Haderka
> Assignee: Jan Haderka
> Fix For: 4.2.1
>
>
> Since version 4.0/DMS 1.4, DMS is using its own versioning command to overcome issue MGNLDMS-158. When installing workflow, this command is overwritten with the default.

[JIRA] Updated: (MAGNOLIA-2903) activation: users having only write permission in a subpart of the hierarchy are not able to activate

2009-11-26T05:39:38Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2903:
----------------------------------

Fix Version/s: 4.2.1

> activation: users having only write permission in a subpart of the hierarchy are not able to activate
> ------------------------------------------------------------------------------------------------------
>
> Key: MAGNOLIA-2903
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2903
> Project: Magnolia
> Issue Type: Bug
> Components: activation
> Affects Versions: 4.1.1
> Reporter: Philipp Bärfuss
> Assignee: Jan Haderka
> Priority: Critical
> Fix For: 4.1.2, 4.2.1
>
>
> In the following line a temporary node is created in the root of the workspace (the node name is the uuid)
> --> ReceiveFilter.importOnExisting(ReceiveFilter.java:420)
> If a user cannot write to the root, but only to a sub hierarchy, he cannot create this temporary node.

[JIRA] Commented: (MAGNOLIA-2958) (Local?) Magnolia 4.1/4.2 AdminCentral often does not display right in Firefox 3.5

2009-11-26T03:07:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25129#action_25129 ]

Jan Haderka commented on MAGNOLIA-2958:
---------------------------------------

Diff between your pre-release trunk copy and the 4.1.1 tag ... over all modules that make CE.

> (Local?) Magnolia 4.1/4.2 AdminCentral often does not display right in Firefox 3.5
> ----------------------------------------------------------------------------------
>
> Key: MAGNOLIA-2958
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2958
> Project: Magnolia
> Issue Type: Bug
> Components: admininterface
> Affects Versions: 4.1.1, 4.2.1
> Environment: Mac OS X 10.6.2, Firefox 3.5.5, Magnolia 4.1.1 or 4.2.1 installed locally, accessed via http://localhost:8080/...
> Reporter: Will Scheidegger
> Assignee: Philipp Bärfuss
> Attachments: screenshot-1.jpg
>
>
> When trying to work with Magnolia on Firefox 3.5 often half of the content is missing. Since "half of the content" usually means css and js files, this makes Magnolia pretty much useless. Here are some screenshots:
> http://www.fastforward.ch/projekte/magnolia/magnolia_4_display_problems/

[JIRA] Commented: (MAGNOLIA-2958) (Local?) Magnolia 4.1/4.2 AdminCentral often does not display right in Firefox 3.5

2009-11-26T02:42:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25128#action_25128 ]

Will Scheidegger commented on MAGNOLIA-2958:
--------------------------------------------

diff of what? I'm not sure if the problem is situated in the admin interface module. Could also be a cache problem - at least last time (Mag 3.2?) it was a cache problem.

I will install a Magnolia 4.2.1 version this weekend on the same server (the exact same version that gives me problems here locally). Let me check first, if this works.

[JIRA] Commented: (MAGNOLIA-2958) (Local?) Magnolia 4.1/4.2 AdminCentral often does not display right in Firefox 3.5

2009-11-26T02:31:38Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25127#action_25127 ]

Jan Haderka commented on MAGNOLIA-2958:
---------------------------------------

So can you do the diff of the version that works in comparison to 4.1.1 tag?

[JIRA] Commented: (MAGNOLIA-2958) (Local?) Magnolia 4.1/4.2 AdminCentral often does not display right in Firefox 3.5

2009-11-26T01:32:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25126#action_25126 ]

Will Scheidegger commented on MAGNOLIA-2958:
--------------------------------------------

BTW: I don't see the problem on our Mag 4.1.1 pre-released trunk version properly installed on a server accessed via Apache

[JIRA] Updated: (MAGNOLIA-2958) (Local?) Magnolia 4.1/4.2 AdminCentral often does not display right in Firefox 3.5

2009-11-26T01:30:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Will Scheidegger updated MAGNOLIA-2958:
---------------------------------------

Attachment: screenshot-1.jpg

[JIRA] Created: (MAGNOLIA-2958) (Local?) Magnolia 4.1/4.2 AdminCentral often does not display right in Firefox 3.5

2009-11-26T01:28:36Z

(Local?) Magnolia 4.1/4.2 AdminCentral often does not display right in Firefox 3.5
----------------------------------------------------------------------------------

Key: MAGNOLIA-2958
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2958
Project: Magnolia
Issue Type: Bug
Components: admininterface
Affects Versions: 4.2.1, 4.1.1
Environment: Mac OS X 10.6.2, Firefox 3.5.5, Magnolia 4.1.1 or 4.2.1 installed locally, accessed via http://localhost:8080/...
Reporter: Will Scheidegger
Assignee: Philipp Bärfuss

When trying to work with Magnolia on Firefox 3.5 often half of the content is missing. Since "half of the content" usually means css and js files, this makes Magnolia pretty much useless. Here are some screenshots:

http://www.fastforward.ch/projekte/magnolia/magnolia_4_display_problems/

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Created: (MGNLDMS-175) Preview of inbox item doesn't work when activating folder incl. subfolders

2009-11-26T01:22:39Z

Preview of inbox item doesn't work when activating folder incl. subfolders
--------------------------------------------------------------------------

Key: MGNLDMS-175
URL: http://jira.magnolia-cms.com/browse/MGNLDMS-175
Project: Magnolia DMS Module
Issue Type: Bug
Affects Versions: 1.4.1
Reporter: Jan Haderka
Assignee: Philipp Bärfuss

The empty document dialog is displayed instead

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Updated: (MAGNOLIA-2491) Generate content2bean documentation

2009-11-25T23:50:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2491:
----------------------------------

Fix Version/s: 4.2.x
(was: 4.1.2)

> Generate content2bean documentation
> -----------------------------------
>
> Key: MAGNOLIA-2491
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2491
> Project: Magnolia
> Issue Type: New Feature
> Components: build
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Fix For: 4.2.x
>
> Attachments: MAGNOLIA-2491.txt
>
>
> To simplify documentation, we should generate documentation for all beans/components which can be configured through content2bean. Simpler and more end-user focused than javadoc.
> An XDoclet2 plugin seems a simple and reasonable approach for achieving this.

[JIRA] Updated: (MAGNOLIA-2820) Backend with HTTPS - warning in IE7

2009-11-25T23:50:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2820:
----------------------------------

Fix Version/s: (was: 4.1.2)

> Backend with HTTPS - warning in IE7
> -----------------------------------
>
> Key: MAGNOLIA-2820
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2820
> Project: Magnolia
> Issue Type: Bug
> Components: admininterface
> Affects Versions: 3.6.3
> Reporter: Rainer Blumenthal
> Assignee: Philipp Bärfuss
> Fix For: 4.2.x
>
> Attachments: Navigation.java, Navigation.js, Navigation.patch
>
>
> If you access the Magnolia Backend with HTTPS using an IE Browser: u get this warning:
> "This page containsd secure and non-secure items..."
> http://farm3.static.flickr.com/2263/2330340408_63a47989da.jpg?v=0
> If you look here: http://weblogs.asp.net/rchartier/archive/2008/03/12/ie7-this-page-contains-both-secure-and-nonsecure-items.aspx
> somebody seems to have found the cause.
> The Magnolia Backend seems to use an iframe without "src" attribute - the "src" attribute is then set by JS. But on page-load the IE interpretes this as unsecure.

[JIRA] Updated: (MAGNOLIA-2671)
2009-11-25T23:50:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2671:
----------------------------------

Fix Version/s: (was: 4.1.2)

> <cmsu:simpleNavigation relativeLevels="true" fails
> --------------------------------------------------
>
> Key: MAGNOLIA-2671
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2671
> Project: Magnolia
> Issue Type: Bug
> Components: taglibs
> Affects Versions: 4.0.1, 4.1.1
> Environment: Windows Vista Business SP1
> JDK 1.6.0_11
> apache-tomcat-5.5.26
> magnolia-bundled-webapp-4.0.1.war
> Reporter: Oliver Knorr
> Assignee: Fabrizio Giustina
> Fix For: 4.2.x
>
>
> After upgrading from Magnolia 3.6.3 to 4.0.1, the tag {{<cmsu:simpleNavigation relativeLevels="true" startLevel="0" endLevel="1" />}} does not print out the list of subpages anymore.
> Like with MAGNOLIA-2669, the problem seems to be caused by the changes for MAGNOLIA-2642 as it disappears for me when I revert Resource.java to the previous revision from http://svn.magnolia-cms.com/view/community/magnolia/trunk/magnolia-taglib-cms/src/main/java/info/magnolia/cms/taglibs/Resource.java?revision=21024

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

Re: Update on the calendar feed generation progress

2009-11-25T14:23:02Z

On Tue, 2009-11-24 at 09:28 -0700, Ryan Gardner wrote:
> I have it working on my dev system. What I haven't finished yet is
> getting it integrated into the STK.
>
> I decided the best place for the CalendarFeedGenerator would be in the
> STK module since it is coupled to the stkEvent already.

That's fine. Just put it in the same package as the PageSyndicator is.

> I see the preferred way to add links to the stk pages is via runtime
> decoration with javascript. I have a prototype I did yesterday that
> adds a behavior to initbehavior that adds a calendar download link to
> the events pages.
>
Is it now? I thought you will just produce icon with a link similar to
templating-kit/paragraphs/teasers/syndicate.ftl, but maybe you had
something more fancy in mind (like a link in the header of the page?).

> I still have a few things left to do before it is at least a "feature
> complete" patch. One is to make it handle single events as well as
> event overviews, and to make it construct static download links as
> well as subscription links (the only difference is that to subscribe
> to a calendar feed, you change the protocol from http:// to webcal://
> and then the clients take care of the rest)
>
> I think instead of futzing to try to make it put the links in via
> javascript, I will put them into the stk template for now and let
> someone who is more familiar with the existing scripts tweak it.

Sounds reasonable, as long as it is clear or documented what those links
should be like.

>
> The feature should make a lot of people happy. Obviously it won't make
> it out for 4.2.1, or 1.2, but its not invasive so could be easily
> slipped in to the next point release and give you a nice bullet point
> to add to a features list.

Hmmm, minor releases should be strictly bug fixes only (barring few
exceptions to strengthen the rule).

> A future step could be calendar aggregation. iCal4j parses ical feeds
> as well as creates them, so you could do some kind of calendar
> subscriptions that get dumped into an events page in magnolia quite
> easily.
> (Since I have no need personally for calendar subscriptions being
> pulled into magnoloa, it is unlikely I will be working on this soon)

well, you can pull them in and display them on the calendar with the
events created directly in Magnolia. Actually this together with part
you are working on and few other features would be enough to justify
another STK release.

> How far along would you like me to get this before I submit it?

As far as you dare to take it :D

Just submit the patch for review once you feel it feature complete and
we can continue the discussion from that point.

Thanks for the effort.

Cheers,
Jan

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Updated: (MAGNOLIA-2957) multiple editCode controls cannot coexsit in the same dialog

2009-11-25T11:33:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2957:
----------------------------------

Fix Version/s: 4.2.x
(was: 4.2.1)

> multiple editCode controls cannot coexsit in the same dialog
> ------------------------------------------------------------
>
> Key: MAGNOLIA-2957
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2957
> Project: Magnolia
> Issue Type: Bug
> Components: gui
> Affects Versions: 4.2.1
> Reporter: Toby O'Rourke
> Assignee: Federico Grilli
> Fix For: 4.2.x
>
> Attachments: fix_multiple_edit_code_controls.patch
>
>
> DialogEditCode writes out a javascript function which replaces the onclick event of the form on which the control has been placed when codepress is used. When more than one control is placed in a form, this replacement overwrites itself such that only one control works properly. No data is saved from the other controls, the corresponding properties are subsequently removed from the JCR.
> The supplied patch chains the functions, thereby removing the problem. As a side effect it removes the limitation that enabling codepress supersedes the dialog's own specific event handler.

Magnolia 4.2 released

2009-11-25T11:27:09Z

Magnolia 4.2 has been released, featuring:

* WebDAV access to template & resources repository
* Code highlighting and line numbering for the inplace-templating module
* Integration of PUR into STK
* Jackrabbit 1.6
* support for data type hierarchies
* Standard Templating Kit 1.2 with many enhancements for SEO and
Accessibility
* New simplified node builder API for easier module maintenance and
node type manipulation

Enjoy!

For download and further info, including introduction videos see
http://www.magnolia-cms.com/4-2

Thanks to all the great community contributions, keep them coming!

- Boris

PS: Happy 6th birthday, Magnolia!

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2293) startLevel of simpleSearch is ignored

2009-11-25T08:26:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25125#action_25125 ]

Hudson CI server commented on MAGNOLIA-2293:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-4.1-branch #6|http://hudson.magnolia-cms.com/job/magnolia_main-4.1-branch/6/]
release all member variables of the tag. Backport of r29990.

> startLevel of simpleSearch is ignored
> -------------------------------------
>
> Key: MAGNOLIA-2293
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2293
> Project: Magnolia
> Issue Type: Bug
> Components: taglibs
> Affects Versions: 3.6, 3.6.1, 3.6.3, 4.0.1, 4.2.1
> Environment: Windows Vista Business SP1
> jdk1.6.0_07
> apache-tomcat-5.5.26
> magnolia-bundled-webapp-3.6.1
> Reporter: Oliver Knorr
> Assignee: Jan Haderka
> Priority: Minor
> Fix For: 4.1.2, 4.2.x
>
> Attachments: SimpleSearchTagPatch.diff
>
>
> The startLevel attribute of cmsu:simplesearch should limit the search only to the current website tree, but is ignored at least in Magnolia 3.6 and 3.6.1.
> Steps to reproduce:
> # Open the demo search page http://localhost:8080/magnoliaAuthor/help/search.html and search for "mail". 5 results from inside and outside the help tree should appear.
> # In webapps\magnoliaAuthor\templates\samples\templates\sample-search.jsp, replace the line
> <cmsu:simpleSearch query="${param.query}" var="results" />
> with the line
> <cmsu:simpleSearch query="${param.query}" var="results" startLevel="1" />
> # Try the search again. Expected result: one hit (/magnoliaAuthor/help/user-mailing-list.html),
> actual result: all the 5 results from the first test are shown.
> The reason seems to be info\magnolia\cms\taglibs\util\SimpleSearchTag.java: the startLevel is respected only in the obsolete generateXPathQuery() method, but not in the new generateSimpleQuery().
> I could fix the problem for me, by replacing
> {code}
> protected String generateSimpleQuery(String input) {
> // jcr and xpath escaping :
> final String escapedQuery = input.replace("'", "\\''");
> return "//*[@jcr:primaryType='mgnl:content']//*[jcr:contains(., '"+ escapedQuery +"')]";
> }
> {code}
> with the following (taking the code from generateXPathQuery()):
> {code}
> protected String generateSimpleQuery(String input) {
> // search only in a specific subtree
> startPath = "";
> if (this.startLevel != 0) {
> try {
> Content activePage = Resource.getActivePage();
> if (activePage != null) {
> startPath = StringUtils.strip(activePage.getAncestor(this.startLevel).getHandle(), "/"); //$NON-NLS-1$
> }
> }
> catch (RepositoryException e) {
> log.error(e.getMessage(), e);
> }
> }
> // jcr and xpath escaping :
> final String escapedQuery = input.replace("'", "\\''");
> return startPath+"//*[@jcr:primaryType='mgnl:content']//*[jcr:contains(., '"+ escapedQuery +"')]";
> }
> {code}

[JIRA] Commented: (MAGNOLIA-2293) startLevel of simpleSearch is ignored

2009-11-25T08:22:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25124#action_25124 ]

Hudson CI server commented on MAGNOLIA-2293:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-trunk #1136|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1136/]
Release all member variables of the tag after use.

[JIRA] Resolved: (MAGNOLIA-2293) startLevel of simpleSearch is ignored

2009-11-25T08:17:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka resolved MAGNOLIA-2293.
-----------------------------------

Resolution: Fixed

[JIRA] Updated: (MAGNOLIA-2293) startLevel of simpleSearch is ignored

2009-11-25T08:13:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2293:
----------------------------------

Fix Version/s: 4.2.x
Affects Version/s: 4.2.1
Assignee: Jan Haderka (was: Grégory Joseph)

[JIRA] Commented: (MAGNOLIA-2293) startLevel of simpleSearch is ignored

2009-11-25T08:11:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25123#action_25123 ]

Jan Haderka commented on MAGNOLIA-2293:
---------------------------------------

{{startPath}} is a member variable. Surely the proper course of action is to release the value of *all* member variables in the {{release()}} method of the tag no?

> startLevel of simpleSearch is ignored
> -------------------------------------
>
> Key: MAGNOLIA-2293
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2293
> Project: Magnolia
> Issue Type: Bug
> Components: taglibs
> Affects Versions: 3.6, 3.6.1, 3.6.3, 4.0.1
> Environment: Windows Vista Business SP1
> jdk1.6.0_07
> apache-tomcat-5.5.26
> magnolia-bundled-webapp-3.6.1
> Reporter: Oliver Knorr
> Assignee: Grégory Joseph
> Priority: Minor
> Fix For: 4.1.2
>
> Attachments: SimpleSearchTagPatch.diff
>
>
> The startLevel attribute of cmsu:simplesearch should limit the search only to the current website tree, but is ignored at least in Magnolia 3.6 and 3.6.1.
> Steps to reproduce:
> # Open the demo search page http://localhost:8080/magnoliaAuthor/help/search.html and search for "mail". 5 results from inside and outside the help tree should appear.
> # In webapps\magnoliaAuthor\templates\samples\templates\sample-search.jsp, replace the line
> <cmsu:simpleSearch query="${param.query}" var="results" />
> with the line
> <cmsu:simpleSearch query="${param.query}" var="results" startLevel="1" />
> # Try the search again. Expected result: one hit (/magnoliaAuthor/help/user-mailing-list.html),
> actual result: all the 5 results from the first test are shown.
> The reason seems to be info\magnolia\cms\taglibs\util\SimpleSearchTag.java: the startLevel is respected only in the obsolete generateXPathQuery() method, but not in the new generateSimpleQuery().
> I could fix the problem for me, by replacing
> {code}
> protected String generateSimpleQuery(String input) {
> // jcr and xpath escaping :
> final String escapedQuery = input.replace("'", "\\''");
> return "//*[@jcr:primaryType='mgnl:content']//*[jcr:contains(., '"+ escapedQuery +"')]";
> }
> {code}
> with the following (taking the code from generateXPathQuery()):
> {code}
> protected String generateSimpleQuery(String input) {
> // search only in a specific subtree
> startPath = "";
> if (this.startLevel != 0) {
> try {
> Content activePage = Resource.getActivePage();
> if (activePage != null) {
> startPath = StringUtils.strip(activePage.getAncestor(this.startLevel).getHandle(), "/"); //$NON-NLS-1$
> }
> }
> catch (RepositoryException e) {
> log.error(e.getMessage(), e);
> }
> }
> // jcr and xpath escaping :
> final String escapedQuery = input.replace("'", "\\''");
> return startPath+"//*[@jcr:primaryType='mgnl:content']//*[jcr:contains(., '"+ escapedQuery +"')]";
> }
> {code}

[JIRA] Commented: (MAGNOLIA-2671)
2009-11-25T06:57:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25122#action_25122 ]

Jan Haderka commented on MAGNOLIA-2671:
---------------------------------------

Let me guess: the issue actually occurs only when the tag is in the template after the {{cms:contentNodeIterator}}, but if you move the {{cmsu:simpleNavigation}} before the iterator, the issue will not occur. Is that correct?

> <cmsu:simpleNavigation relativeLevels="true" fails
> --------------------------------------------------
>
> Key: MAGNOLIA-2671
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2671
> Project: Magnolia
> Issue Type: Bug
> Components: taglibs
> Affects Versions: 4.0.1, 4.1.1
> Environment: Windows Vista Business SP1
> JDK 1.6.0_11
> apache-tomcat-5.5.26
> magnolia-bundled-webapp-4.0.1.war
> Reporter: Oliver Knorr
> Assignee: Fabrizio Giustina
> Fix For: 4.1.2, 4.2.x
>
>
> After upgrading from Magnolia 3.6.3 to 4.0.1, the tag {{<cmsu:simpleNavigation relativeLevels="true" startLevel="0" endLevel="1" />}} does not print out the list of subpages anymore.
> Like with MAGNOLIA-2669, the problem seems to be caused by the changes for MAGNOLIA-2642 as it disappears for me when I revert Resource.java to the previous revision from http://svn.magnolia-cms.com/view/community/magnolia/trunk/magnolia-taglib-cms/src/main/java/info/magnolia/cms/taglibs/Resource.java?revision=21024

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2957) multiple editCode controls cannot coexsit in the same dialog

2009-11-25T06:42:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25121#action_25121 ]

Hudson CI server commented on MAGNOLIA-2957:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-trunk #1135|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1135/]
: removed warning in javadoc about onclick handlers superseded by control's own handler as this is not the case anymore.

> multiple editCode controls cannot coexsit in the same dialog
> ------------------------------------------------------------
>
> Key: MAGNOLIA-2957
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2957
> Project: Magnolia
> Issue Type: Bug
> Components: gui
> Affects Versions: 4.2.1
> Reporter: Toby O'Rourke
> Assignee: Federico Grilli
> Fix For: 4.2.1
>
> Attachments: fix_multiple_edit_code_controls.patch
>
>
> DialogEditCode writes out a javascript function which replaces the onclick event of the form on which the control has been placed when codepress is used. When more than one control is placed in a form, this replacement overwrites itself such that only one control works properly. No data is saved from the other controls, the corresponding properties are subsequently removed from the JCR.
> The supplied patch chains the functions, thereby removing the problem. As a side effect it removes the limitation that enabling codepress supersedes the dialog's own specific event handler.

[JIRA] Commented: (MAGNOLIA-2957) multiple editCode controls cannot coexsit in the same dialog

2009-11-25T06:32:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25120#action_25120 ]

Hudson CI server commented on MAGNOLIA-2957:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-trunk #1134|http://hudson.magnolia-cms.com/job/magnolia_main-trunk/1134/]
: applied and tested patch provided by Toby O'Rourke

> multiple editCode controls cannot coexsit in the same dialog
> ------------------------------------------------------------
>
> Key: MAGNOLIA-2957
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2957
> Project: Magnolia
> Issue Type: Bug
> Components: gui
> Affects Versions: 4.2.1
> Reporter: Toby O'Rourke
> Assignee: Federico Grilli
> Fix For: 4.2.1
>
> Attachments: fix_multiple_edit_code_controls.patch
>
>
> DialogEditCode writes out a javascript function which replaces the onclick event of the form on which the control has been placed when codepress is used. When more than one control is placed in a form, this replacement overwrites itself such that only one control works properly. No data is saved from the other controls, the corresponding properties are subsequently removed from the JCR.
> The supplied patch chains the functions, thereby removing the problem. As a side effect it removes the limitation that enabling codepress supersedes the dialog's own specific event handler.

[JIRA] Resolved: (MAGNOLIA-2957) multiple editCode controls cannot coexsit in the same dialog

2009-11-25T06:26:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Federico Grilli resolved MAGNOLIA-2957.
---------------------------------------

Fix Version/s: 4.2.1
Resolution: Fixed

Thanks Toby.

> multiple editCode controls cannot coexsit in the same dialog
> ------------------------------------------------------------
>
> Key: MAGNOLIA-2957
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2957
> Project: Magnolia
> Issue Type: Bug
> Components: gui
> Affects Versions: 4.2.1
> Reporter: Toby O'Rourke
> Assignee: Federico Grilli
> Fix For: 4.2.1
>
> Attachments: fix_multiple_edit_code_controls.patch
>
>
> DialogEditCode writes out a javascript function which replaces the onclick event of the form on which the control has been placed when codepress is used. When more than one control is placed in a form, this replacement overwrites itself such that only one control works properly. No data is saved from the other controls, the corresponding properties are subsequently removed from the JCR.
> The supplied patch chains the functions, thereby removing the problem. As a side effect it removes the limitation that enabling codepress supersedes the dialog's own specific event handler.

[JIRA] Assigned: (MAGNOLIA-2957) multiple editCode controls cannot coexsit in the same dialog

2009-11-25T05:27:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Federico Grilli reassigned MAGNOLIA-2957:
-----------------------------------------

Assignee: Federico Grilli (was: Boris Kraft)

> multiple editCode controls cannot coexsit in the same dialog
> ------------------------------------------------------------
>
> Key: MAGNOLIA-2957
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2957
> Project: Magnolia
> Issue Type: Bug
> Components: gui
> Affects Versions: 4.2.1
> Reporter: Toby O'Rourke
> Assignee: Federico Grilli
> Attachments: fix_multiple_edit_code_controls.patch
>
>
> DialogEditCode writes out a javascript function which replaces the onclick event of the form on which the control has been placed when codepress is used. When more than one control is placed in a form, this replacement overwrites itself such that only one control works properly. No data is saved from the other controls, the corresponding properties are subsequently removed from the JCR.
> The supplied patch chains the functions, thereby removing the problem. As a side effect it removes the limitation that enabling codepress supersedes the dialog's own specific event handler.

[JIRA] Updated: (MAGNOLIA-2800) generated-resources folder ends up in jar files?

2009-11-25T05:00:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2800:
----------------------------------

Fix Version/s: 4.2.x
(was: 4.1.2)
Affects Version/s: 4.2.1

The issue is not specific to the 4.1 branch

> generated-resources folder ends up in jar files?
> ------------------------------------------------
>
> Key: MAGNOLIA-2800
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2800
> Project: Magnolia
> Issue Type: Bug
> Components: build
> Affects Versions: 4.1, 4.2.1
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Fix For: 4.2.x
>
>
> {noformat}$ unzip -l target/magnolia-taglib-utility-4.1.1-SNAPSHOT.jar |grep tld
> 39464 06-24-09 19:40 generated-resources/xdoclet/META-INF/taglib.tld
> 39464 06-24-09 19:40 META-INF/taglib.tld
> {noformat}

[JIRA] Updated: (MAGNOLIA-1959) Leopard (osx 10.5) issues

2009-11-25T04:38:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-1959:
----------------------------------

Fix Version/s: 4.2.x
(was: 4.1.2)

> Leopard (osx 10.5) issues
> -------------------------
>
> Key: MAGNOLIA-1959
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-1959
> Project: Magnolia
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Fix For: 4.2.x
>
>
> h3. Leopard's application level firewall :
> Leopard's firewall behaves significantly differently than the firewall shipped with OSX 10.4. The symptoms are that Tomcat seems unreachable ("kCFErrorDomainCFNetwork:302"), but unfortunately no log message *clearly* identifies the issue.
> It seems the behavior was different prior to OSX 10.5.3, but at least in 10.5.4 the following seems to work:
> - "allow incoming connections" for the Magnolia and Tomcat scripts ({{magnolia_control.sh}}, {{startup.sh}}, {{shutdown.sh}}, {{catalina.sh}}), as well as the Java binary (ie {{/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java}})
> - it seems sometimes necessary to "lock" and "unlock" the firewall settings pane, so as to force it to take the new settings into account.
> - if Magnolia was started, you'll have to kill it (-HUP works and shuts it down nicely) and restart.
> h4. More comments and questions
> - somehow, setting the firewall too "allow all" does not seem to help.
> - {{sudo launchctl remove com.apple.alf}} should remove the application-level firewall, but for some reason, this hasn't proved very useful. Will have to try again.
> h4. Log files to watch:
> * {{/var/log/system.log}}
> * {{/var/log/secure.log}}
> * {{/var/log/appfirewall.log}}
> h4. Some interesting links:
> * http://securosis.com/2007/11/01/investigating-the-leopard-firewall/
> * http://documentation.magnolia.info/administration.html#Knownissues which links back to here but has a nice little screenshot of Leopard's firewall configuration gui ;)
> h3. "Max.files opened"
> There might be some "max.files opened" issues, with settings which are different from Tiger(10.4), although this hasn't been reported in a while.
> There is unfortunately not much we can do about this issue at the moment, as far as we know.
> *Feel free to comment on your own experience below and contribute tips and tricks !*

[JIRA] Updated: (MAGNOLIA-2676) c2bdoc: links to javadoc

2009-11-25T04:36:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2676:
----------------------------------

Fix Version/s: 4.2.x
(was: 4.1.2)

> c2bdoc: links to javadoc
> ------------------------
>
> Key: MAGNOLIA-2676
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2676
> Project: Magnolia
> Issue Type: Sub-task
> Components: build
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Priority: Minor
> Fix For: 4.2.x
>
>
> It'd be nice if we had link to the corresponding javadoc. That will mean solving a few problems
> * base url (magnolia main, version vs other modules)
> * version (c2bdoc is currently not aware of the version of the artifact it's generating docu for)

[JIRA] Issue Comment Edited: (MAGNOLIA-2822) Snapshot bundles generate with duplicate jars !

2009-11-25T04:23:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25114#action_25114 ]

Jan Haderka edited comment on MAGNOLIA-2822 at 11/25/09 1:21 PM:
-----------------------------------------------------------------

Locally built snapshots of bundles from 4.1 branch do not suffer from this issue. Maybe it is related to hudson configuration? Should still be checked.

was (Author: had):
Locally build snapshots of bundles from 4.1 branch do not suffer from this issue. Maybe it is related to hudson configuration? Should still be checked.

> Snapshot bundles generate with duplicate jars !
> -----------------------------------------------
>
> Key: MAGNOLIA-2822
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2822
> Project: Magnolia
> Issue Type: Bug
> Components: build
> Reporter: Grégory Joseph
> Assignee: Grégory Joseph
> Priority: Critical
> Fix For: 4.2.x
>
>
> It would seem that snapshot bundles/wars contain duplicate jars (ie {{magnolia-core-4.1.1-20090724.184135-15.jar}} and {{magnolia-core-4.1.1-SNAPSHOT.jar}}) - at least those I just got from hudson.
> This shouldn't cause an issue with actual release, but still, snapshot builds should be valid !

[JIRA] Updated: (MAGNOLIA-2822) Snapshot bundles generate with duplicate jars !

2009-11-25T04:21:36Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Haderka updated MAGNOLIA-2822:
----------------------------------

Fix Version/s: 4.2.x
(was: 4.1.2)

Locally build snapshots of bundles from 4.1 branch do not suffer from this issue. Maybe it is related to hudson configuration? Should still be checked.

[JIRA] Created: (MAGNOLIA-2957) multiple editCode controls cannot coexsit in the same dialog

2009-11-25T04:10:36Z

multiple editCode controls cannot coexsit in the same dialog
------------------------------------------------------------

Key: MAGNOLIA-2957
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2957
Project: Magnolia
Issue Type: Bug
Components: gui
Affects Versions: 4.2.1
Reporter: Toby O'Rourke
Assignee: Boris Kraft
Attachments: fix_multiple_edit_code_controls.patch

DialogEditCode writes out a javascript function which replaces the onclick event of the form on which the control has been placed when codepress is used. When more than one control is placed in a form, this replacement overwrites itself such that only one control works properly. No data is saved from the other controls, the corresponding properties are subsequently removed from the JCR.

The supplied patch chains the functions, thereby removing the problem. As a side effect it removes the limitation that enabling codepress supersedes the dialog's own specific event handler.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.magnolia-cms.com/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <dev-list-unsubscribe@...>
----------------------------------------------------------------

[JIRA] Commented: (MAGNOLIA-2956) content2bean: make sure that the force creation flag is respected (4.1.2 only)

2009-11-25T04:01:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25112#action_25112 ]

Hudson CI server commented on MAGNOLIA-2956:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-4.1-branch #5|http://hudson.magnolia-cms.com/job/magnolia_main-4.1-branch/5/]
MAGNOLIA-2949, handle instantiation exceptions, backport of r29858

> content2bean: make sure that the force creation flag is respected (4.1.2 only)
> ------------------------------------------------------------------------------
>
> Key: MAGNOLIA-2956
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2956
> Project: Magnolia
> Issue Type: Sub-task
> Reporter: Jan Haderka
> Assignee: Jan Haderka
> Fix For: 4.1.2
>
>

[JIRA] Commented: (MAGNOLIA-2949) content2bean: make sure that the force creation flag is respected

2009-11-25T04:01:37Z

[ http://jira.magnolia-cms.com/browse/MAGNOLIA-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25111#action_25111 ]

Hudson CI server commented on MAGNOLIA-2949:
--------------------------------------------

Integrated in !http://hudson.magnolia-cms.com/nocacheImages/16x16/blue.gif! [magnolia_main-4.1-branch #5|http://hudson.magnolia-cms.com/job/magnolia_main-4.1-branch/5/]
, MAGNOLIA-2956 handle instantiation exceptions, backport of r29858

> content2bean: make sure that the force creation flag is respected
> -----------------------------------------------------------------
>
> Key: MAGNOLIA-2949
> URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-2949
> Project: Magnolia
> Issue Type: Improvement
> Components: core
> Affects Versions: 4.0.3, 4.1.1, 4.2
> Reporter: Philipp Bärfuss
> Assignee: Philipp Bärfuss
> Priority: Critical
> Fix For: 4.2.x
>
>
> The FactoryUtil.newInstance() method throws exceptions since MAGNOLIA-2552 and does not return null anymore. To keep the same behavior in the content2bean processor if the force creation flag is set to true we have to catch the exceptions and react accordingly.
> Otherwise the filter chain fails to instantiate if one of the classes is wrongly defined (even if it is somewhere deeper in the hierarchy). This is really dangerous.