[magnolia-dev] [JIRA] (MGNLREST-89) Empty arrays coming through as null in JSON

[JIRA (on behalf of Nickolaus Wing)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nickolaus Wing created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Magnolia REST Framework /  MGNLREST-89  
 
 
  Empty arrays coming through as null in JSON   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 1.2.1  
 
 
Assignee: 
 Unassigned  
 
 
Created: 
 11/May/17 1:40 AM  
 
 
Labels: 
 apiteam  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Nickolaus Wing  
 

  
 
 
 
 

 
 Related to MGNLREST-83, another change we noticed after the latest updates is that nodes with no children come through with  { nodes: null }  instead of  { nodes: [] } . This is a change from the previous behavior and can break code that assumes an array in all cases.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  

[magnolia-dev] [JIRA] (MGNLREST-84) Custom endpoints no longer show up in REST Tools (Swagger UI)

[JIRA (on behalf of Nickolaus Wing)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nickolaus Wing created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Magnolia REST Framework /  MGNLREST-84  
 
 
  Custom endpoints no longer show up in REST Tools (Swagger UI)   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 1.2  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 tools  
 
 
Created: 
 15/Feb/17 1:23 AM  
 
 
Priority: 
  Major  
 
 
Reporter: 
 Nickolaus Wing  
 

  
 
 
 
 

 
 I wrote and contributed the forge module "magnolia-rest-queries" that adds a RESTful interface for executing JCR queries. After this latest swagger update my endpoint no longer appears in the REST Tools interface. I checked /.rest/swagger.json and it is also missing from there. The module configures itself according to the documentation provided here: https://documentation.magnolia-cms.com/display/DOCS/REST+API#RESTAPI-Exposingyourownendpoints It was working well in 5.4.x. It looks like the new Swagger re-organized things and now you're generating /.rest/swagger.json instead of /.rest/api-docs. I would guess that the code that generates swagger.json is failing to look in other module configurations for a /rest-endpoints/ node, but that is simply a guess. RESTful requests to the endpoint do continue to work correctly.  
 

  
 
 
 
 

 
 
 

 

[magnolia-dev] [JIRA] (MGNLREST-83) JSON output suddenly changed without changing API version number

[JIRA (on behalf of Nickolaus Wing)]

Title: Message Title


 
 
 
 

 
 
 

 
   
 Nickolaus Wing created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Magnolia REST Framework /  MGNLREST-83  
 
 
  JSON output suddenly changed without changing API version number   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Affects Versions: 
 1.2  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 services  
 
 
Created: 
 13/Feb/17 10:21 PM  
 
 
Labels: 
 apiteam  
 
 
Priority: 
  Critical  
 
 
Reporter: 
 Nickolaus Wing  
 

  
 
 
 
 

 
 We are in the process of upgrading from 5.4.x to 5.5.1, and our QA revealed that all of our RESTful integrations are broken, because the 'nodes' and 'properties' keys on each node have been renamed to 'node' and 'property'.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 
  

[magnolia-dev] [JIRA] (MGNLUI-3864) Allow multiple reorder actions with keyboard on MultiValueField

[JIRA (on behalf of Nickolaus Wing)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Nickolaus Wing updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia UI /  MGNLUI-3864 
 
 
 
  Allow multiple reorder actions with keyboard on MultiValueField  
 
 
 
 
 
 
 
 
 

Change By:
 
 Nickolaus Wing 
 
 
 

Attachment:
 
 multifield.patch 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




For list details, see: http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: 

[magnolia-dev] [JIRA] (MGNLUI-3864) Allow multiple reorder actions with keyboard on MultiValueField

[JIRA (on behalf of Nickolaus Wing)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Nickolaus Wing created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia UI /  MGNLUI-3864 
 
 
 
  Allow multiple reorder actions with keyboard on MultiValueField  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Affects Versions:
 

 5.4.5 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Attachments:
 

 multifield.patch 
 
 
 

Components:
 

 dialogs, forms 
 
 
 

Created:
 

 27/Apr/16 11:49 PM 
 
 
 

Priority:
 
  Minor 
 
 
 

Reporter:
 
 Nickolaus Wing 
 
 
 

Security Level:
 

 Public 
 
 
 
 
 
 
 
 
 
 
We just noticed you added re-ordering to the MultiValueFieldDefinition. It's great to have! We had already implemented it on our own, so we are going to eliminate our subclass and use yours. The only thing we did that you didn't was the following: 
When you use keyboard navigation to tab 

[magnolia-dev] [JIRA] (MGNLUI-3832) Page Editor iframe sized incorrectly

[JIRA (on behalf of Nickolaus Wing)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Nickolaus Wing created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia UI /  MGNLUI-3832 
 
 
 
  Page Editor iframe sized incorrectly  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 5.4.4 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Components:
 

 page editor 
 
 
 

Created:
 

 24/Mar/16 5:19 PM 
 
 
 

Environment:
 

 Chrome. Observed in Windows 7 on several machines with optional-touch monitors. 
 
 
 

Priority:
 
  Critical 
 
 
 

Reporter:
 
 Nickolaus Wing 
 
 
 

Security Level:
 

 Public 
 
 
 
 
 
 
 
 
 
 
It appears there is some _javascript_/Vaadin code that is resizing the page editor iframe on page load. In the presence of a touch-capable monitor, somehow on Chrome it is making an incorrect guess that the device is a tablet and setting the iframe height to something very large, which makes it impossible 

[magnolia-dev] [JIRA] (MGNLMIGRATION-230) Older template definitions may have NodeData 'path' that should be renamed to templateScript

[JIRA (on behalf of Nickolaus Wing)]

Nickolaus Wing
 created  MGNLMIGRATION-230


Older template definitions may have NodeData path that should be renamed to templateScript















Issue Type:


Bug



Affects Versions:


1.2.x



Assignee:


Unassigned


Attachments:


MigrationUtil.patch



Components:


Migration Task



Created:


04/Mar/13 7:55 PM



Description:


Apparently our templates were defined long ago when the path to the template script was given by the NodeData named "path".  The migration task does "template" - "templateScript" and "templatePath" - "templateScript" but does not do "path" - "templateScript".

Patch is simple and included.




Project:


Magnolia Migration



Priority:


Major




Reporter:


Nickolaus Wing



Original Estimate:


20m





Remaining Estimate:


20m




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira








Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] (MGNLMIGRATION-230) Older template definitions may have NodeData 'path' that should be renamed to templateScript

[JIRA (on behalf of Nickolaus Wing)]

Nickolaus Wing
 updated  MGNLMIGRATION-230


Older template definitions may have NodeData path that should be renamed to templateScript
















Change By:


Nickolaus Wing
(04/Mar/13 10:54 PM)




Attachment:


MigrationUtil.patch



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira








Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] (MGNLMIGRATION-230) Older template definitions may have NodeData 'path' that should be renamed to templateScript

[JIRA (on behalf of Nickolaus Wing)]

Nickolaus Wing
 updated  MGNLMIGRATION-230


Older template definitions may have NodeData path that should be renamed to templateScript
















Change By:


Nickolaus Wing
(04/Mar/13 10:53 PM)




Attachment:


MigrationUtil.patch



























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira








Forlistdetails,see:http://www.magnolia-cms.com/community/mailing-lists.html
Alternatively,useourforums:http://forum.magnolia-cms.com/
Tounsubscribe,E-mailto:dev-list-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3841) Mime type resolution fails when running in jetty due to ;jsessionid being included in the path

[JIRA (on behalf of Nickolaus Wing)]

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

Nickolaus Wing updated MAGNOLIA-3841:
-

Attachment: ContentTypeFilter.java.diff

Here is a simple patch file (against today's trunk) to resolve the issue.  
Should work fine for all containers, no matter which behavior they choose.

 Mime type resolution fails when running in jetty due to ;jsessionid being 
 included in the path
 --

 Key: MAGNOLIA-3841
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3841
 Project: Magnolia
  Issue Type: Bug
  Security Level: Public
  Components: core
Affects Versions: 4.4.5
Reporter: Tobias Mattsson
Assignee: Philipp Bärfuss
 Attachments: ContentTypeFilter.java.diff


 When running integration tests for 4.5 trunk they log this message:
 INFO  info.magnolia.cms.beans.config.MIMEMapping : Cannot find MIME type for 
 extension html;jsessionid=4611ywu6o2i9
 The reason for this is that jetty includes the part of the path after ; in 
 request.getRequestURI().
 Apparently JBoss AS also does this.

-- 
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/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Created: (MAGNOLIA-3883) Same-Name Sibling possible when moving page in admincentral

[JIRA (on behalf of Nickolaus Wing)]

Same-Name Sibling possible when moving page in admincentral
---

 Key: MAGNOLIA-3883
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3883
 Project: Magnolia
  Issue Type: Bug
  Security Level: Public
  Components: admininterface
Affects Versions: 4.4.5, 4.4.4, 4.4.3, 4.4.2, 4.4.1, 4.4
Reporter: Nickolaus Wing
Assignee: Philipp Bärfuss
Priority: Major
 Attachments: AdminTreeMVCHandler.java.patch

Steps to reproduce:

1) Create two pages, parent1 and parent2
2) Create two subpages in each, subpage1 and subpage2
3) Move parent2/subpage2 BETWEEN parent1/subpage1 and parent1/subpage2

parent1 now has two pages named subpage2, which causes various other 
problems.

I traced this down to a queer bit of logic in 
magnolia-module-admininterface/.../AdminTreeMVCHandler.java.

In the pasteNode() method, in the section pertaining to PASTETYPE_ABOVE and 
PASTETYPE_BELOW, it decides to do an end run around the copyMoveNode() method 
ONLY when moving, and ONLY when the pastetype is above or below.  

For instance, if you were to replace step 3 above with: 
3) Move parent2/subpage2 onto parent1

In that case, copyMoveNode() would be used and everything would work fine.

From browsing the SVN changelog, this behavior has apparently been in place 
since at least 2006.

I've included a patch file (against trunk) with the recommended fix.

-- 
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/community/mailing-lists.html
Alternatively, use our forums: http://forum.magnolia-cms.com/
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Created: (MAGNOLIA-3654) When activating, lastaction metadata is not updated on public side

[JIRA (on behalf of Nickolaus Wing)]

When activating, lastaction metadata is not updated on public side
--

 Key: MAGNOLIA-3654
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3654
 Project: Magnolia
  Issue Type: Bug
  Components: activation
Affects Versions: 4.4.2
 Environment: All
Reporter: Nickolaus Wing
Assignee: Philipp Bärfuss
 Attachments: ReceiveFilter.java.patch, ReceiveFilterTest.java.patch

We are using the exchange-simple module for activations, and tried to key off 
of mgnl:lastaction for one of our template features (a reminder when a page has 
gone unedited for a long time).  We wanted to key off of lastaction instead of 
lastmodified so that someone could simply re-activate to clear the reminder.

However, the author side of the activation transaction updates lastaction AFTER 
the activation completes successfully, so the public side is left with a 
one-activation-too-old lastaction date.

To fix it, I used the attached patch.  It only updates the lastaction, and only 
for the page, NOT for any of the content inside the page.  A more complete 
patch might also update the activatorid, and do it for all the content below 
the page (but not pages below the page).  I'll leave the more complex patch to 
you guys, if you decide it's worthwhile.  This one works for our purposes.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Created: (MAGNOLIA-3284) Fixed some webkit javascript errors in FCKEditor

[JIRA (on behalf of Nickolaus Wing)]

Fixed some webkit javascript errors in FCKEditor


 Key: MAGNOLIA-3284
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3284
 Project: Magnolia
  Issue Type: Bug
  Components: fckeditor
Affects Versions: 4.3.6
Reporter: Nickolaus Wing
Assignee: Boris Kraft
Priority: Minor
 Attachments: fckeditor.html.patch, fckeditorcode_gecko.js.patch

We tracked this down in response to a bug that eliminated the Browse Server 
button when you tried to create an image but didn't place focus in the editor 
before hitting the image button. The Selection object representing what's 
currently selected didn't have any ranges in it, raising an exception under 
webkit when it tried to call Selection.getRangeAt(0).

The other was a javascript exception that was always popping up on page load on 
webkit browsers (Chrome/Safari).

Patches are included (applied against today's magnolia trunk).

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3013) Moving paragraphs using edit bars not working properly in Internet Explorer (IE7 / IE8)

[JIRA (on behalf of Nickolaus Wing)]

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

Nickolaus Wing updated MAGNOLIA-3013:
-

Attachment: general2.patch

Here's a second patch to apply - I noticed that it was sometimes possible to 
move the mouse in IE7 before all the necessary objects were available, causing 
an error to be generated.

 Moving paragraphs using edit bars not working properly in Internet Explorer 
 (IE7 / IE8)
 ---

 Key: MAGNOLIA-3013
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3013
 Project: Magnolia
  Issue Type: Bug
  Components: gui
Affects Versions: 4.2.3
 Environment: Internet Explorer 7.0 and 8.0 under Windows.
Reporter: Hay Kranen
Assignee: Ondřej Chytil
Priority: Critical
 Attachments: general.patch, general2.patch


 When moving paragraphs using the 'move' button a bug occurs in both IE7 and 
 IE8. The green bar is floating approximately 150 pixels higher than were the 
 mouse cursor is, in some cases it's completely invisible. In Firefox / Safari 
 the bar is located where you expect it to be, right next to the mouse cursor.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3214) pageIterator does not correctly replace the current node after it finishes looping

[JIRA (on behalf of Nickolaus Wing)]

[ 
http://jira.magnolia-cms.com/browse/MAGNOLIA-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=28639#action_28639
 ] 

Nickolaus Wing commented on MAGNOLIA-3214:
--

I'd really like to see this patch get picked up - it's essential for our 
sidebar strategy, which I'm hoping to be able to package up as a standalone 
module.

 pageIterator does not correctly replace the current node after it finishes 
 looping
 

 Key: MAGNOLIA-3214
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3214
 Project: Magnolia
  Issue Type: Bug
Affects Versions: 4.3.1, 4.2.4
Reporter: Nickolaus Wing
Assignee: Boris Kraft
 Attachments: pageIterator.patch


 pageIterator relies on 
 info.magnolia.cms.taglibs.Resource.restoreCurrentActivePage() to restore the 
 current node after execution.  However, restoreCurrentActivePage() simply 
 assumes that you wish to set getMainContent() as the current node.  It seems 
 more friendly to save off the current content node before execution, and 
 restore it afterwards.
 The included patch does exactly that.  File to be patched is 
 magnolia-taglib-cms/.../pageIterator.java.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3013) Moving paragraphs using edit bars not working properly in Internet Explorer (IE7 / IE8)

[JIRA (on behalf of Nickolaus Wing)]

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

Nickolaus Wing updated MAGNOLIA-3013:
-

Attachment: general.patch

We ran into this problem as well.  It only happens when the window has been 
scrolled down a bit, and for us only seems to happen for paragraphs in our 
sidebar.  There may be some kind of style difference that helps trigger it, but 
I couldn't tell you which.

To fix it I changed getMousePos() to use the same method that the Prototype 
library uses to get the mouse position from the event.  It worked.  See the 
patch file I've included.

 Moving paragraphs using edit bars not working properly in Internet Explorer 
 (IE7 / IE8)
 ---

 Key: MAGNOLIA-3013
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3013
 Project: Magnolia
  Issue Type: Bug
  Components: gui
Affects Versions: 4.2.3
 Environment: Internet Explorer 7.0 and 8.0 under Windows.
Reporter: Hay Kranen
Assignee: Boris Kraft
 Attachments: general.patch


 When moving paragraphs using the 'move' button a bug occurs in both IE7 and 
 IE8. The green bar is floating approximately 150 pixels higher than were the 
 mouse cursor is, in some cases it's completely invisible. In Firefox / Safari 
 the bar is located where you expect it to be, right next to the mouse cursor.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Created: (MAGNOLIA-3214) pageIterator does not correctly replace the current node after it finishes looping

[JIRA (on behalf of Nickolaus Wing)]

pageIterator does not correctly replace the current node after it finishes 
looping


 Key: MAGNOLIA-3214
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3214
 Project: Magnolia
  Issue Type: Bug
Affects Versions: 4.2.4, 4.3.1
Reporter: Nickolaus Wing
Assignee: Boris Kraft
 Attachments: pageIterator.patch

pageIterator relies on 
info.magnolia.cms.taglibs.Resource.restoreCurrentActivePage() to restore the 
current node after execution.  However, restoreCurrentActivePage() simply 
assumes that you wish to set getMainContent() as the current node.  It seems 
more friendly to save off the current content node before execution, and 
restore it afterwards.

The included patch does exactly that.  File to be patched is 
magnolia-taglib-cms/.../pageIterator.java.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Created: (MAGNOLIA-3209) pageIterator no longer works unless the current node is a page

[JIRA (on behalf of Nickolaus Wing)]

pageIterator no longer works unless the current node is a page
--

 Key: MAGNOLIA-3209
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3209
 Project: Magnolia
  Issue Type: Bug
Affects Versions: 4.2.4, 4.3.1, 4.3
Reporter: Nickolaus Wing
Assignee: Boris Kraft


This is related to MAGNOLIA-2851 and MAGNOLIA-3007.  In the latter 
PageIterator.initContentIterator() was changed to begin with:

{code}
Content activePage = MgnlContext.getAggregationState().getCurrentContent();
{code}

This means that if you use the tag while a non-page content node is active, it 
will come up blank.  That struck me as very odd when I ran across it.  It seems 
more appropriate to change it to this:

{code}
Content activePage = MgnlContext.getAggregationState().getCurrentContent();
try {
  while (!activePage.getItemType().equals(ItemType.CONTENT)) {
activePage = activePage.getParent();
  }
} catch (Exception e) {
  // oh well
}
{code}

This will search up the tree until we find the page we're on, then iterate over 
its subpages.  The try/catch is there because getParent() can throw JCR 
exceptions.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Commented: (MAGNOLIA-1182) function $() name collision in javascript with prototype.js using IE

[JIRA (on behalf of Nickolaus Wing)]

[ 
http://jira.magnolia-cms.com/browse/MAGNOLIA-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=26932#action_26932
 ] 

Nickolaus Wing commented on MAGNOLIA-1182:
--

IE seems to have a separate parsing step for picking up function declarations, 
so wrapping a conditional around it doesn't do anything.  However, you can just 
change:

function $() { ... }

to

$ = function () { ... }

which is identical in functionality, while also forcing IE to respect the 
evaluation of the condition.

(This change occurs at the top of m-m-admininterface/.../admin-js/generic.js)

 function $() name collision in javascript with prototype.js using IE
 

 Key: MAGNOLIA-1182
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-1182
 Project: Magnolia
  Issue Type: Bug
  Components: admininterface
Affects Versions: 3.0 RC3
 Environment: Internet Explorer 6/7 (and probably lower versions), 
 pages that use prototype.js
Reporter: Andy McDowall
Assignee: Philipp Bärfuss
Priority: Minor

 The problem reported in issue 794 
 (http://jira.magnolia.info/browse/MAGNOLIA-794) still occurs in internet 
 explorer;
 the if(typeof != 'function') does not appear to prevent the re-definition of 
 the $() function in IE.
 A temporary (and hacky) fix (for those affected by this) is to re-declare the 
 $() function as specified in prototype.js after any cms:mainBar/ tags.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Issue Comment Edited: (MAGNOLIA-1182) function $() name collision in javascript with prototype.js using IE

[JIRA (on behalf of Nickolaus Wing)]

[ 
http://jira.magnolia-cms.com/browse/MAGNOLIA-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=26932#action_26932
 ] 

Nickolaus Wing edited comment on MAGNOLIA-1182 at 3/8/10 9:46 PM:
--

IE seems to have a separate parsing step for picking up function declarations, 
so wrapping a conditional around it doesn't do anything.  However, you can just 
change:

function $(element) { ... }

to

$ = function (element) { ... }

which is identical in functionality, while also forcing IE to respect the 
evaluation of the condition.

(This change occurs at the top of m-m-admininterface/.../admin-js/generic.js)

  was (Author: nwing):
IE seems to have a separate parsing step for picking up function 
declarations, so wrapping a conditional around it doesn't do anything.  
However, you can just change:

function $() { ... }

to

$ = function () { ... }

which is identical in functionality, while also forcing IE to respect the 
evaluation of the condition.

(This change occurs at the top of m-m-admininterface/.../admin-js/generic.js)
  
 function $() name collision in javascript with prototype.js using IE
 

 Key: MAGNOLIA-1182
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-1182
 Project: Magnolia
  Issue Type: Bug
  Components: admininterface
Affects Versions: 3.0 RC3
 Environment: Internet Explorer 6/7 (and probably lower versions), 
 pages that use prototype.js
Reporter: Andy McDowall
Assignee: Philipp Bärfuss
Priority: Minor

 The problem reported in issue 794 
 (http://jira.magnolia.info/browse/MAGNOLIA-794) still occurs in internet 
 explorer;
 the if(typeof != 'function') does not appear to prevent the re-definition of 
 the $() function in IE.
 A temporary (and hacky) fix (for those affected by this) is to re-declare the 
 $() function as specified in prototype.js after any cms:mainBar/ tags.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Issue Comment Edited: (MAGNOLIA-1182) function $() name collision in javascript with prototype.js using IE

[JIRA (on behalf of Nickolaus Wing)]

[ 
http://jira.magnolia-cms.com/browse/MAGNOLIA-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=26932#action_26932
 ] 

Nickolaus Wing edited comment on MAGNOLIA-1182 at 3/8/10 9:47 PM:
--

IE seems to have a separate parsing step for picking up function declarations, 
so wrapping a conditional around it doesn't do anything.  However, you can just 
change:

function $(element) { ... }

to

$ = function (element) { ... }

which is identical in functionality, while also forcing IE to respect the 
evaluation of the condition.

(This change occurs at the top of m-m-admininterface/.../admin-js/generic.js)

Edited to add: this remains a problem in IE8 running Magnolia 4.2.3.  We just 
bumped into it this past week.

  was (Author: nwing):
IE seems to have a separate parsing step for picking up function 
declarations, so wrapping a conditional around it doesn't do anything.  
However, you can just change:

function $(element) { ... }

to

$ = function (element) { ... }

which is identical in functionality, while also forcing IE to respect the 
evaluation of the condition.

(This change occurs at the top of m-m-admininterface/.../admin-js/generic.js)
  
 function $() name collision in javascript with prototype.js using IE
 

 Key: MAGNOLIA-1182
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-1182
 Project: Magnolia
  Issue Type: Bug
  Components: admininterface
Affects Versions: 3.0 RC3
 Environment: Internet Explorer 6/7 (and probably lower versions), 
 pages that use prototype.js
Reporter: Andy McDowall
Assignee: Philipp Bärfuss
Priority: Minor

 The problem reported in issue 794 
 (http://jira.magnolia.info/browse/MAGNOLIA-794) still occurs in internet 
 explorer;
 the if(typeof != 'function') does not appear to prevent the re-definition of 
 the $() function in IE.
 A temporary (and hacky) fix (for those affected by this) is to re-declare the 
 $() function as specified in prototype.js after any cms:mainBar/ tags.

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Created: (MAGNOLIA-3110) javascript document.write causing head elements to render in DOM body

[JIRA (on behalf of Nickolaus Wing)]

javascript document.write causing head elements to render in DOM body
-

 Key: MAGNOLIA-3110
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3110
 Project: Magnolia
  Issue Type: Bug
  Components: admininterface
Affects Versions: 4.2.3
 Environment: All browsers, XHTML 1.0 Strict
Reporter: Nickolaus Wing
Assignee: Philipp Bärfuss
Priority: Minor
 Attachments: inline.patch

In the admin-interface module, inline.js contains 3 document.write statements 
that create divs for later use by javascript.  If we use cms:links/ in the 
head of the page, this javascript will be included in the head.

Then, the browser will execute those document.writes during the loading of the 
head element, writing out divs that belong in the body.  This causes all 
known browsers to begin the body element immediately in their internal 
representation.  Thus all tags following cms:links/ will appear in the 
body, according to the DOM.

This has always been annoyingly messy when using something like firebug to 
examine a document, but it also caused serious problems when including 
Scriptaculous, which attempts to find itself in the head in order to include 
more files, which obviously it can't do if it's been moved to the body.

It can be solved with the attached patch, which moves the creation of these 
divs to the window.onload event (in a crossplatform, unobtrusive fashion).

The file to be patched is m-m-admininterface/.../admin-js/inline.js

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3110) javascript document.write causing head elements to render in DOM body

[JIRA (on behalf of Nickolaus Wing)]

[ 
http://jira.magnolia-cms.com/browse/MAGNOLIA-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=26937#action_26937
 ] 

Nickolaus Wing commented on MAGNOLIA-3110:
--

Yeah, I looked about for one for a little while and didn't find anything.  It's 
definitely a handy function to have around, but I put it right there to try to 
keep the patch tightly contained.  It should probably be placed adjacent to 
other similar utility functions in generic.js or something.

 javascript document.write causing head elements to render in DOM body
 -

 Key: MAGNOLIA-3110
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3110
 Project: Magnolia
  Issue Type: Bug
  Components: admininterface
Affects Versions: 4.2.3
 Environment: All browsers, XHTML 1.0 Strict
Reporter: Nickolaus Wing
Assignee: Philipp Bärfuss
Priority: Minor
 Fix For: 4.3

 Attachments: inline.patch

   Original Estimate: 0.38d
  Remaining Estimate: 0.38d

 In the admin-interface module, inline.js contains 3 document.write statements 
 that create divs for later use by javascript.  If we use cms:links/ in the 
 head of the page, this javascript will be included in the head.
 Then, the browser will execute those document.writes during the loading of 
 the head element, writing out divs that belong in the body.  This causes 
 all known browsers to begin the body element immediately in their internal 
 representation.  Thus all tags following cms:links/ will appear in the 
 body, according to the DOM.
 This has always been annoyingly messy when using something like firebug to 
 examine a document, but it also caused serious problems when including 
 Scriptaculous, which attempts to find itself in the head in order to 
 include more files, which obviously it can't do if it's been moved to the 
 body.
 It can be solved with the attached patch, which moves the creation of these 
 divs to the window.onload event (in a crossplatform, unobtrusive fashion).
 The file to be patched is m-m-admininterface/.../admin-js/inline.js

-- 
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-unsubscr...@magnolia-cms.com

[magnolia-dev] [JIRA] Commented: (MAGNOLIA-3110) javascript document.write causing head elements to render in DOM body

[JIRA (on behalf of Nickolaus Wing)]

[ 
http://jira.magnolia-cms.com/browse/MAGNOLIA-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=26939#action_26939
 ] 

Nickolaus Wing commented on MAGNOLIA-3110:
--

I submitted another admin-interface javascript patch in 
http://jira.magnolia-cms.com/browse/MAGNOLIA-1182.  I wasn't sure whether to 
update that (very old) ticket or create a new one.  Thought I'd draw your 
attention to it since the fix is right there in the same general area as this 
one.

 javascript document.write causing head elements to render in DOM body
 -

 Key: MAGNOLIA-3110
 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3110
 Project: Magnolia
  Issue Type: Bug
  Components: admininterface
Affects Versions: 4.2.3
 Environment: All browsers, XHTML 1.0 Strict
Reporter: Nickolaus Wing
Assignee: Philipp Bärfuss
Priority: Minor
 Fix For: 4.3

 Attachments: inline.patch

   Original Estimate: 0.38d
  Remaining Estimate: 0.38d

 In the admin-interface module, inline.js contains 3 document.write statements 
 that create divs for later use by javascript.  If we use cms:links/ in the 
 head of the page, this javascript will be included in the head.
 Then, the browser will execute those document.writes during the loading of 
 the head element, writing out divs that belong in the body.  This causes 
 all known browsers to begin the body element immediately in their internal 
 representation.  Thus all tags following cms:links/ will appear in the 
 body, according to the DOM.
 This has always been annoyingly messy when using something like firebug to 
 examine a document, but it also caused serious problems when including 
 Scriptaculous, which attempts to find itself in the head in order to 
 include more files, which obviously it can't do if it's been moved to the 
 body.
 It can be solved with the attached patch, which moves the creation of these 
 divs to the window.onload event (in a crossplatform, unobtrusive fashion).
 The file to be patched is m-m-admininterface/.../admin-js/inline.js

-- 
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-unsubscr...@magnolia-cms.com