[magnolia-dev] [JIRA] (MGNLCKEDIT-14) Make link browser open selected path in tree
Stefan Baur
created MGNLCKEDIT-14
Make link browser open selected path in tree
Issue Type:
Improvement
Affects Versions:
1.0.2
Assignee:
Jaroslav Simak
Created:
14/Oct/14 4:19 PM
Description:
Hi there
I just had to fix this issue for our current project.
I have looked at the old fck editor and implemented the feature the same way...
The following changes were necessary:
Implement public String select() {} in CKRepositoryBrowserPage to call setSelectedPath()
Update filebrowser and imagebrowser urls in config
config.filebrowserLinkBrowseUrl = cfg.contextPath + "/.magnolia/pages/ckRepositoryBrowser.html?contextPath=" + cfg.contextPath + "";
config.filebrowserImageBrowseUrl = cfg.contextPath + "/.magnolia/pages/ckRepositoryBrowser.html?contextPath=" + cfg.contextPath + "selectedRepository=dms";
Add CKRepositoryBrowserPage.html ("show" template) to read the absoluteURI from opener.CKEDITOR and update the window.location.href
Project:
CKEditor module
Priority:
Major
Reporter:
Stefan Baur
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] (MGNLCKEDIT-14) Make link browser open selected path in tree
Stefan Baur updated MGNLCKEDIT-14 Make link browser open selected path in tree Change By: Stefan Baur (14/Oct/14 4:28 PM) Visible to: [cbalaguer] 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] (MGNLCKEDIT-14) Make link browser open selected path in tree
Stefan Baur updated MGNLCKEDIT-14 Make link browser open selected path in tree Change By: Stefan Baur (14/Oct/14 5:24 PM) Attachment: CKRepositoryBrowserPage.html Attachment: CKRepositoryBrowserPage.java 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] (MGNLCKEDIT-15) CKRepositoryBrowserPageSelect: make popup larger
Stefan Baur created MGNLCKEDIT-15 CKRepositoryBrowserPageSelect: make popup larger Issue Type: Improvement Affects Versions: 1.0.2 Assignee: Jaroslav Simak Created: 14/Oct/14 5:29 PM Description: Hi Could you update the size of the popup window to a bigger size? I use this: window.resizeTo(800, 935); also, the iframe height must be adapted: iframe id="frmTree" name="frmTree" src="" class="code-quote">"" width="100%" height="800" frameborder="0" marginheight="0" marginwidth="0" scrolling="no"/ Project: CKEditor module Priority: Neutral Reporter: Stefan Baur 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] (MGNLCACHE-75) Make if possible to use different values for cacheConfigurationName and cache name.
Stefan Baur created MGNLCACHE-75 Make if possible to use different values for cacheConfigurationName and cache name. Issue Type: Improvement Assignee: Unassigned Created: 12/Sep/14 2:19 PM Description: Hi Currently, info.magnolia.module.cache.filter.CacheFilter#onCacheModuleStart uses cacheConfigurationName to read the cache configuration and to create the cache. This means that you force the usage of a different cache per cache filter. If you have to setup multi site caching (https://documentation.magnolia-cms.com/display/DOCS/Advanced+Cache+module#AdvancedCachemodule-Multisitecacheconfiguration), you will end up with N cache filters and N cache configurations. Maybe a second property cacheName on the filter will do the magic. And you can always fallback to cacheConfigurationName if cacheName is not set. Cheers, Stefan Project: Magnolia Cache Module Priority: Neutral Reporter: Stefan Baur 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] (BLOSSOM-180) Blossom Incompatible with Magnolia 5.3
Stefan Baur updated BLOSSOM-180 Blossom Incompatible with Magnolia 5.3 For my Maven Project I have created this patch class in webapp/src/main/java: BlossomFormDialogPresenter.java Change By: Stefan Baur (07/Jul/14 11:50 AM) Attachment: BlossomFormDialogPresenter.java 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] Created: (DOCU-355) Footer area is called main
Footer area is called main Key: DOCU-355 URL: http://jira.magnolia-cms.com/browse/DOCU-355 Project: Documentation Issue Type: Bug Security Level: Public Components: content Reporter: Stefan Baur Assignee: Antti Hietala http://documentation.magnolia-cms.com/reference/areas.html In the picture, the footer area is called main. -- 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-4583) Provide Util method to prevent request caching
Provide Util method to prevent request caching -- Key: MAGNOLIA-4583 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-4583 Project: Magnolia Issue Type: Improvement Security Level: Public Components: cache Affects Versions: 4.4.9 Reporter: Stefan Baur Attachments: CacheUtil.java Provide a convenience Helper Method to set the cache exclude header. -- 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: (MGNLDMS-236) magnolia.utf8.enabled not working in DMS
magnolia.utf8.enabled not working in DMS Key: MGNLDMS-236 URL: http://jira.magnolia-cms.com/browse/MGNLDMS-236 Project: Magnolia DMS Module Issue Type: Bug Affects Versions: 1.6.1, 1.5.4 Reporter: Stefan Baur Assignee: Philipp Bärfuss If magnolia.utf8.enabled is set to true, the DMS allows unicode characters in node names. Once you create a node with say öäü, the node cannot be edited anymore. Neighter delete, move, rename or dialog save is working anymore. This is true for folders and actual DMS items. -- 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] Updated: (MAGNOLIA-4447) DMS folder with special characters (öäü with magnolia.utf8.enabled=true) introduce incomplete linking of fck editor images
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Baur updated MAGNOLIA-4447:
--
Description:
Normally, the fck editor saves images in this format:
src=${link:{uuid:{f466d306-ff0c-4921-a06f-40a27f17e22f},repository:{dms},handle:{/TESTING/images/Satellite_image_of_Iceland_in_September},nodeData:{},extension:{jpg}}}
If the folder name contains a special character like öäü (e.g. Jubiläum), the
image is saved differently:
src=/dms/TESTING/Jubilauml;um/Satellite_image_of_Iceland_in_September.jpg
In the second case, the moving of the image will cause the link to break, as
there is no UUID stored to resolve the new location.
I assume there is a problem in the DMS to resolve folder content with special
characters. So this might sctually be a DMS problem or have to do with such one.
was:
Normally, the fck editor saves images in this format:
src=${link:{uuid:{f466d306-ff0c-4921-a06f-40a27f17e22f},repository:{dms},handle:{/TESTING/images/Satellite_image_of_Iceland_in_September},nodeData:{},extension:{jpg}}}
If the folder name contains a special character like öäü (e.g. Jubiläum), the
image is saved diferently:
src=/dms/TESTING/Jubilauml;um/Satellite_image_of_Iceland_in_September.jpg
In the second case, the moving of the image will cause the link to break, as
there is no UUID stored to resolve the new location.
I assume there is a problem in the DMS to resolve folder content with special
characters. So this might sctually be a DMS problem or have to do with such one.
DMS folder with special characters (öäü with magnolia.utf8.enabled=true)
introduce incomplete linking of fck editor images
--
Key: MAGNOLIA-4447
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-4447
Project: Magnolia
Issue Type: Bug
Security Level: Public
Components: fckeditor
Affects Versions: 4.4.8, 4.5.2
Reporter: Stefan Baur
Normally, the fck editor saves images in this format:
src=${link:{uuid:{f466d306-ff0c-4921-a06f-40a27f17e22f},repository:{dms},handle:{/TESTING/images/Satellite_image_of_Iceland_in_September},nodeData:{},extension:{jpg}}}
If the folder name contains a special character like öäü (e.g. Jubiläum), the
image is saved differently:
src=/dms/TESTING/Jubilauml;um/Satellite_image_of_Iceland_in_September.jpg
In the second case, the moving of the image will cause the link to break, as
there is no UUID stored to resolve the new location.
I assume there is a problem in the DMS to resolve folder content with special
characters. So this might sctually be a DMS problem or have to do with such
one.
--
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-4447) DMS folder with special characters (öäü with magnolia.utf8.enabled=true) introduce incomplete linking of fck editor images
DMS folder with special characters (öäü with magnolia.utf8.enabled=true)
introduce incomplete linking of fck editor images
--
Key: MAGNOLIA-4447
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-4447
Project: Magnolia
Issue Type: Bug
Security Level: Public
Components: fckeditor
Affects Versions: 4.5.2, 4.4.8
Reporter: Stefan Baur
Normally, the fck editor saves images in this format:
src=${link:{uuid:{f466d306-ff0c-4921-a06f-40a27f17e22f},repository:{dms},handle:{/TESTING/images/Satellite_image_of_Iceland_in_September},nodeData:{},extension:{jpg}}}
If the folder that contains the image contains a special character like öäü
(e.g. Jubiläum), the image is saved diferently:
src=/dms/TESTING/Jubilauml;um/Satellite_image_of_Iceland_in_September.jpg
In the second case, the moving of the image will cause the link to break, as
there is no UUID stored to resolve the new location.
I assume there is a problem in the DMS to resolve folder content with special
characters. So this might sctually be a DMS problem or have to do with such one.
--
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] Updated: (MAGNOLIA-4447) DMS folder with special characters (öäü with magnolia.utf8.enabled=true) introduce incomplete linking of fck editor images
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-4447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Baur updated MAGNOLIA-4447:
--
Description:
Normally, the fck editor saves images in this format:
src=${link:{uuid:{f466d306-ff0c-4921-a06f-40a27f17e22f},repository:{dms},handle:{/TESTING/images/Satellite_image_of_Iceland_in_September},nodeData:{},extension:{jpg}}}
If the folder name contains a special character like öäü (e.g. Jubiläum), the
image is saved diferently:
src=/dms/TESTING/Jubilauml;um/Satellite_image_of_Iceland_in_September.jpg
In the second case, the moving of the image will cause the link to break, as
there is no UUID stored to resolve the new location.
I assume there is a problem in the DMS to resolve folder content with special
characters. So this might sctually be a DMS problem or have to do with such one.
was:
Normally, the fck editor saves images in this format:
src=${link:{uuid:{f466d306-ff0c-4921-a06f-40a27f17e22f},repository:{dms},handle:{/TESTING/images/Satellite_image_of_Iceland_in_September},nodeData:{},extension:{jpg}}}
If the folder that contains the image contains a special character like öäü
(e.g. Jubiläum), the image is saved diferently:
src=/dms/TESTING/Jubilauml;um/Satellite_image_of_Iceland_in_September.jpg
In the second case, the moving of the image will cause the link to break, as
there is no UUID stored to resolve the new location.
I assume there is a problem in the DMS to resolve folder content with special
characters. So this might sctually be a DMS problem or have to do with such one.
DMS folder with special characters (öäü with magnolia.utf8.enabled=true)
introduce incomplete linking of fck editor images
--
Key: MAGNOLIA-4447
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-4447
Project: Magnolia
Issue Type: Bug
Security Level: Public
Components: fckeditor
Affects Versions: 4.4.8, 4.5.2
Reporter: Stefan Baur
Normally, the fck editor saves images in this format:
src=${link:{uuid:{f466d306-ff0c-4921-a06f-40a27f17e22f},repository:{dms},handle:{/TESTING/images/Satellite_image_of_Iceland_in_September},nodeData:{},extension:{jpg}}}
If the folder name contains a special character like öäü (e.g. Jubiläum), the
image is saved diferently:
src=/dms/TESTING/Jubilauml;um/Satellite_image_of_Iceland_in_September.jpg
In the second case, the moving of the image will cause the link to break, as
there is no UUID stored to resolve the new location.
I assume there is a problem in the DMS to resolve folder content with special
characters. So this might sctually be a DMS problem or have to do with such
one.
--
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] Updated: (MAGNOLIA-3986) MgnlDynamicTable move functions
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Baur updated MAGNOLIA-3986:
--
Visible to: [and...@vexeddigital.com, dkummer] (was: [dkummer])
MgnlDynamicTable move functions
---
Key: MAGNOLIA-3986
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3986
Project: Magnolia
Issue Type: New Feature
Security Level: Public
Components: admininterface
Affects Versions: 4.4.4
Reporter: Stefan Baur
Assignee: Philipp Bärfuss
Original Estimate: 1m
Remaining Estimate: 1m
I have created move functions for the MgnlDynamicTable javascript lib.
The following functions can be added to
/mgnl-resources/js-classes/mgnl/controls/DynamicTable.js
The functions have been tested on
- Safari 5.1.2 (Win7x64)
- FF 10 (Win7x64)
- Chrome 17.0.963.56 (Win7x64)
- IE 9 (Win7x64)
- IE 6 7 (WinXP, separate in a VM, not with multipleIE)
{code:javascript|title=DynamicTable.js}
/* ###
### Move an Object from one index to another. includes savety checks
### */
MgnlDynamicTable.prototype.move = function (from, to){
if(from == to || from == null || from == 'undefined' || to == null || to
== 'undefined') {
//do nothing
} else if (from to) { //move down
var index = from;
var objectToMove = this.objects[from];
var to = Math.min(to, this.objects.length-1); //safety...
while(index to) {
var nextIndex = index+1;
var nextObject = this.objects[nextIndex];
this.set(index, nextObject);
index = nextIndex;
}
this.set(to, objectToMove);
} else { //move up
var index = from;
var objectToMove = this.objects[from];
var to = Math.max(to, 0); //safety...
while(index to) {
var nextIndex = index-1;
var nextObject = this.objects[nextIndex];
this.set(index, nextObject);
index = nextIndex;
}
this.set(to, objectToMove);
}
}
/* ###
### Move an Object up
### */
MgnlDynamicTable.prototype.moveUp = function (index){
this.move(index, index-1);
}
/* ###
### Move an Object down
### */
MgnlDynamicTable.prototype.moveDown = function (index){
this.move(index, index+1);
}
{code}
--
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] Updated: (MGNLDATA-145) Renaming of folder throws error: Can't rename: No dialog handler for [null] found
[ http://jira.magnolia-cms.com/browse/MGNLDATA-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Baur updated MGNLDATA-145: - Visible to: [and...@vexeddigital.com, dkummer] (was: [dkummer]) Renaming of folder throws error: Can't rename: No dialog handler for [null] found - Key: MGNLDATA-145 URL: http://jira.magnolia-cms.com/browse/MGNLDATA-145 Project: Magnolia Data Module Issue Type: Bug Affects Versions: 1.6.3 Reporter: Stefan Baur The error occurs if you: 1) Create a data type and allow folders 2) Create a folder within the newly created type 3) try to rename the folder. A javascript alert tells you: Can't rename: No dialog handler for [null] found The folder is renamed correctly regardless of the warning. This might be related to MGNLDATA-130 -- 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-3986) MgnlDynamicTable move functions
MgnlDynamicTable move functions
---
Key: MAGNOLIA-3986
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3986
Project: Magnolia
Issue Type: New Feature
Security Level: Public
Components: admininterface
Affects Versions: 4.4.4
Reporter: Stefan Baur
Assignee: Philipp Bärfuss
I have created move functions for the MgnlDynamicTable javascript lib.
The following functions can be added to
/mgnl-resources/js-classes/mgnl/controls/DynamicTable.js
The functions have been tested on
- Safari 5.1.2 (Win7x64)
- FF 10 (Win7x64)
- Chrome 17.0.963.56 (Win7x64)
- IE 9 (Win7x64)
- IE 6 7 (WinXP, separate in a VM, not with multipleIE)
{code:javascript|title=DynamicTable.js}
/* ###
### Move an Object from one index to another. includes savety checks
### */
MgnlDynamicTable.prototype.move = function (from, to){
if(from == to || from == null || from == 'undefined' || to == null || to ==
'undefined') {
//do nothing
} else if (from to) { //move down
var index = from;
var objectToMove = this.objects[from];
var to = Math.min(to, this.objects.length-1); //safety...
while(index to) {
var nextIndex = index+1;
var nextObject = this.objects[nextIndex];
this.set(index, nextObject);
index = nextIndex;
}
this.set(to, objectToMove);
} else { //move up
var index = from;
var objectToMove = this.objects[from];
var to = Math.max(to, 0); //safety...
while(index to) {
var nextIndex = index-1;
var nextObject = this.objects[nextIndex];
this.set(index, nextObject);
index = nextIndex;
}
this.set(to, objectToMove);
}
}
/* ###
### Move an Object up
### */
MgnlDynamicTable.prototype.moveUp = function (index){
this.move(index, index-1);
}
/* ###
### Move an Object down
### */
MgnlDynamicTable.prototype.moveDown = function (index){
this.move(index, index+1);
}
{code}
--
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: (MGNLDATA-145) Renaming of folder throws error: Can't rename: No dialog handler for [null] found
Renaming of folder throws error: Can't rename: No dialog handler for [null] found - Key: MGNLDATA-145 URL: http://jira.magnolia-cms.com/browse/MGNLDATA-145 Project: Magnolia Data Module Issue Type: Bug Affects Versions: 1.6.3 Reporter: Stefan Baur Assignee: Philipp Bärfuss The error occurs if you: 1) Create a data type and allow folders 2) Create a folder within the newly created type 3) try to rename the folder. A javascript alert tells you: Can't rename: No dialog handler for [null] found The folder is renamed correctly regardless of the warning. This might be related to MGNLDATA-130 -- 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-3949) Enable the enabled flag in DefaultSubscription bean
Enable the enabled flag in DefaultSubscription bean - Key: MAGNOLIA-3949 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3949 Project: Magnolia Issue Type: Improvement Security Level: Public Components: activation Affects Versions: 4.4.4 Reporter: Stefan Baur Assignee: Philipp Bärfuss Currently, the bean info.magnolia.module.exchangesimple.DefaultSubscription return true for isEnabled(). It would be nice to actually being able to disable a subscription on a configuration level. -- 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-3860) CacheModuleLifecycleListener references are not deleted on cache module restart
CacheModuleLifecycleListener references are not deleted on cache module restart
---
Key: MAGNOLIA-3860
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3860
Project: Magnolia
Issue Type: Bug
Security Level: Public
Components: cache
Affects Versions: 4.4.4
Reporter: Stefan Baur
I have a class listening to the cache module startup event like:
CacheModule.getInstance().register(new CacheModuleLifecycleListener() {
public void onCacheModuleStart() {
doStuff();
}
});
If a cache module reload is triggered (by changing content in the cache
config), doStuff() will be called twice, and after again triggering a reload,
doStuff() will be called three times.
I could work around this by overriding hashCode() and equals() in my
CacheModuleLifecycleListener, but thought this could be fixed anyway.
Will it need a reset of the listeners Map in
info.magnolia.module.cache.CacheModule#stop ?
Regards,
Stefan
--
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
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-3770) Create the possibility to prevent caching of a page.
Create the possibility to prevent caching of a page. Key: MAGNOLIA-3770 URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3770 Project: Magnolia Issue Type: Improvement Affects Versions: 4.4.3 Reporter: Stefan Baur Priority: Major In both large projects that I implemented for now, I needed a solution to exclude a template from caching. As a workaround, I created an url voter to exclude specific urls by regex patterns, but this is a hardcoded version that does not always work nicely. At the moment, it is only possible to exclude requests from cache BEFORE the filter chain is processed to the end. This means, that the decision of caching or not cannot be influenced by any code after the CacheFilter, because the CachePolicyBehaviour and the according Executor have already been chosen. I could imagine the possibility to call CacheFilter.getInstance().excludeRequestFromCache() //(or something similar in MgnlContext) from anywhere in the code. Unfortunately I do not see how this could be achieved after investigating the caching code for quite a while. So I can't include a suggestion or even a patch. Thanks fo help Stefan -- 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 To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-3746) Inbox page preview (with GET parameter mgnlVersion=) renders the page in wrong mode.
Inbox page preview (with GET parameter mgnlVersion=) renders the page in wrong
mode.
Key: MAGNOLIA-3746
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3746
Project: Magnolia
Issue Type: Bug
Affects Versions: 4.4.3
Reporter: Stefan Baur
If page is rendered with the mgnlVersion= GET parameter, alls edit bars are
hidden and the page looks like in preview mode. You reach this state by
clicking Show Content in the inbox.
The page looks like in preview mode (because all green bars are hidden), but
all freemarker code inside of [#if mgnl.editMode] statements is executed all
the same. This causes some rendering problems, and displays hintl like in
formGroupEdit.ftl :: 10
[#if mgnl.editMode]
${i18n['form.note.field']}
[/#if]
to be displayed, even though the user doesnt seem to be in the edit mode.
It seems to me, that the aggregationState returns a wrong value here:
info.magnolia.cms.core.AggregationState#isPreviewMode
--
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
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3746) Inbox page preview (with GET parameter mgnlVersion=) renders the page in wrong mode.
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Baur updated MAGNOLIA-3746:
--
Description:
If page is rendered with the mgnlVersion= GET parameter, alls edit bars are
hidden and the page looks like in preview mode. You reach this state by
clicking Show Content in the inbox.
The page looks like in preview mode (because all green bars are hidden), but
all freemarker code inside of {code} [#if mgnl.editMode]{code} statements is
executed all the same. This causes some rendering problems, and displays hintl
like in
{code:title=formGroupEdit.ftl, Line 10|borderStyle=solid}
[#if mgnl.editMode]
${i18n['form.note.field']}
[/#if]
{code}
to be displayed, even though the user doesnt seem to be in the edit mode.
It seems to me, that the aggregationState returns a wrong value here:
info.magnolia.cms.core.AggregationState#isPreviewMode
was:
If page is rendered with the mgnlVersion= GET parameter, alls edit bars are
hidden and the page looks like in preview mode. You reach this state by
clicking Show Content in the inbox.
The page looks like in preview mode (because all green bars are hidden), but
all freemarker code inside of [#if mgnl.editMode] statements is executed all
the same. This causes some rendering problems, and displays hintl like in
formGroupEdit.ftl :: 10
[#if mgnl.editMode]
${i18n['form.note.field']}
[/#if]
to be displayed, even though the user doesnt seem to be in the edit mode.
It seems to me, that the aggregationState returns a wrong value here:
info.magnolia.cms.core.AggregationState#isPreviewMode
Inbox page preview (with GET parameter mgnlVersion=) renders the page in
wrong mode.
Key: MAGNOLIA-3746
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3746
Project: Magnolia
Issue Type: Bug
Affects Versions: 4.4.3
Reporter: Stefan Baur
If page is rendered with the mgnlVersion= GET parameter, alls edit bars are
hidden and the page looks like in preview mode. You reach this state by
clicking Show Content in the inbox.
The page looks like in preview mode (because all green bars are hidden), but
all freemarker code inside of {code} [#if mgnl.editMode]{code} statements
is executed all the same. This causes some rendering problems, and displays
hintl like in
{code:title=formGroupEdit.ftl, Line 10|borderStyle=solid}
[#if mgnl.editMode]
${i18n['form.note.field']}
[/#if]
{code}
to be displayed, even though the user doesnt seem to be in the edit mode.
It seems to me, that the aggregationState returns a wrong value here:
info.magnolia.cms.core.AggregationState#isPreviewMode
--
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
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Updated: (MAGNOLIA-3746) Inbox page preview (with GET parameter mgnlVersion=) renders the page in wrong mode.
[
http://jira.magnolia-cms.com/browse/MAGNOLIA-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Baur updated MAGNOLIA-3746:
--
Description:
If page is rendered with the mgnlVersion= GET parameter, alls edit bars are
hidden and the page looks like in preview mode. You reach this state by
clicking Show Content in the inbox.
The page looks like in preview mode (because all green bars are hidden), but
all freemarker code inside of {code} [#if mgnl.editMode]{code} statements is
executed all the same.
This causes some rendering problems, and displays hints like in
{code:title=formGroupEdit.ftl, Line 10|borderStyle=solid}
[#if mgnl.editMode]
${i18n['form.note.field']}
[/#if]
{code}
to be displayed, even though the user doesnt seem to be in the edit mode.
It seems to me, that the aggregationState returns a wrong value here:
info.magnolia.cms.core.AggregationState#isPreviewMode
was:
If page is rendered with the mgnlVersion= GET parameter, alls edit bars are
hidden and the page looks like in preview mode. You reach this state by
clicking Show Content in the inbox.
The page looks like in preview mode (because all green bars are hidden), but
all freemarker code inside of {code} [#if mgnl.editMode]{code} statements is
executed all the same. This causes some rendering problems, and displays hintl
like in
{code:title=formGroupEdit.ftl, Line 10|borderStyle=solid}
[#if mgnl.editMode]
${i18n['form.note.field']}
[/#if]
{code}
to be displayed, even though the user doesnt seem to be in the edit mode.
It seems to me, that the aggregationState returns a wrong value here:
info.magnolia.cms.core.AggregationState#isPreviewMode
Inbox page preview (with GET parameter mgnlVersion=) renders the page in
wrong mode.
Key: MAGNOLIA-3746
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3746
Project: Magnolia
Issue Type: Bug
Affects Versions: 4.4.3
Reporter: Stefan Baur
If page is rendered with the mgnlVersion= GET parameter, alls edit bars are
hidden and the page looks like in preview mode. You reach this state by
clicking Show Content in the inbox.
The page looks like in preview mode (because all green bars are hidden), but
all freemarker code inside of {code} [#if mgnl.editMode]{code} statements
is executed all the same.
This causes some rendering problems, and displays hints like in
{code:title=formGroupEdit.ftl, Line 10|borderStyle=solid}
[#if mgnl.editMode]
${i18n['form.note.field']}
[/#if]
{code}
to be displayed, even though the user doesnt seem to be in the edit mode.
It seems to me, that the aggregationState returns a wrong value here:
info.magnolia.cms.core.AggregationState#isPreviewMode
--
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
To unsubscribe, E-mail to: dev-list-unsubscr...@magnolia-cms.com
[magnolia-dev] [JIRA] Created: (MAGNOLIA-3741) Javascript error when previewing a page that is marked as deleted.
Javascript error when previewing a page that is marked as deleted.
---
Key: MAGNOLIA-3741
URL: http://jira.magnolia-cms.com/browse/MAGNOLIA-3741
Project: Magnolia
Issue Type: Bug
Components: admininterface
Affects Versions: 4.4.3
Reporter: Stefan Baur
Assignee: Philipp Bärfuss
When previewing a page that has been marked as deleted a javascript exception
is thrown in Internet Explorer 8. The javascript exception does not occur in
IE7 or Firefox 3.6. Other browsers weren't tested.
The javascript exception is:
Line: 2671
Error: Object doesn't support this property or method
On line 2671 you'll find the following command:
$('#softLockingInfoIcon').qtip({
I presume that the qtip library (which is loaded dynamically) isn't available
when the browser gets to line 2671. Also the error shows up on about 4 out of 5
refreshes, so I'm quite sure it has something to do with the loaded procedure.
--
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: (MGNLFORM-86) Password paragraph has wrong markup (label and input are nested)
Password paragraph has wrong markup (label and input are nested) Key: MGNLFORM-86 URL: http://jira.magnolia-cms.com/browse/MGNLFORM-86 Project: Magnolia Form Module Issue Type: Bug Affects Versions: 1.2.2 Reporter: Stefan Baur Assignee: Tobias Mattsson Attachments: formPassword.ftl the input filed for the password is nested into the label. this breaks the design in my project and I dont understand why this should be needed. in case of a normal textfield the markup seems correct PASSWORD: label for=sdfsdf class= id=sdfsdf_label span sdf /span input type=password value= id=sdfsdf name=sdfsdf /label TEXTFIELD: label for=subject span Subject /span /label input type=text maxlength=50 value= id=subject name=subject I have included my fixed ftl file. -- 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: (MGNLSTK-763) Subtemplates are not merged with the prototype
Subtemplates are not merged with the prototype
--
Key: MGNLSTK-763
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-763
Project: Magnolia Standard Templating Kit
Issue Type: Bug
Components: templates
Affects Versions: 1.4.1
Reporter: Stefan Baur
Assignee: Philipp Bärfuss
A subtemplate definition (in my case print) defined in the template prototype
in the site definition is not taken into account in rendering. If I instead
move the subtemplates node to my template definition, it instantly works. This
means, that I have to copy the subtemplate definition to each template.
Otherwise, I could define it centrally.
Am I missing something, or is there another reason why this doesent work?
here is my NodeOperation that creates the subtemplate definition:
public static NodeOperation addSubTemplateNode(final String subTemplateName,
final String subTemplateFileName) {
return new AbstractNodeOperation() {
protected Content doExec(Content context, ErrorHandler
errorHandler) throws RepositoryException {
Content subTemplatesNode =
ContentUtil.getOrCreateContent(context, subTemplates, context.getItemType());
Content subTemplateNode =
ContentUtil.getOrCreateContent(subTemplatesNode, subTemplateName,
context.getItemType());
subTemplateNode.setNodeData(class,
info.magnolia.module.templatingkit.templates.STKTemplate);
subTemplateNode.setNodeData(extension, subTemplateName);
subTemplateNode.setNodeData(modelClass,
info.magnolia.module.templatingkit.templates.STKTemplateModel);
subTemplateNode.setNodeData(templatePath,
subTemplateFileName);
subTemplateNode.setNodeData(type,
BALOISE_TEMPLATE_RENDERER_NAME);
subTemplateNode.setNodeData(i18nBasename,
BALOISE_INTERNET_I18N_BASENAME);
return subTemplateNode;
}
};
}
--
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: (MGNLSTK-712) enable the parameters-feature also for the Area class.
enable the parameters-feature also for the Area class.
Key: MGNLSTK-712
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-712
Project: Magnolia Standard Templating Kit
Issue Type: New Feature
Affects Versions: 1.3.4
Reporter: Stefan Baur
Assignee: Philipp Bärfuss
Priority: Minor
For templates and paragraphs, we have the feature of adding parameters and
accessing those values just by ${def.key} (instead of def.parameters.key).
It would be very nice, if this was possible also for Areas (for example:
def.footer.parameters.key)
--
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: (MGNLSTK-677) Exception in STKPager::getPageItem()
[
http://jira.magnolia-cms.com/browse/MGNLSTK-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=30099#action_30099
]
Stefan Baur commented on MGNLSTK-677:
-
nice. will this update be included in further releases?
Exception in STKPager::getPageItem()
Key: MGNLSTK-677
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-677
Project: Magnolia Standard Templating Kit
Issue Type: Bug
Components: paragraphs
Affects Versions: 1.3.4
Reporter: Stefan Baur
Assignee: Ondřej Chytil
Priority: Trivial
Fix For: 1.3.x
Attachments: STKPager.java.patch
Original Estimate: 0.25h
Remaining Estimate: 0.25h
the following line
subList = ((List)items).subList(offset, limit);
generates an exception
java.lang.IllegalArgumentException: fromIndex(4) toIndex(2)
if offset is larger than limit.
FIX:
public Collection getPageItems() {
Collection subList = items;
int offset = getOffset();
if(count 0) {
int limit = maxResultsPerPage + offset;
if(items.size() limit) {
limit = count;
}
if(offset limit){
subList = ((List)items).subList(offset, limit);
}else{
subList = items;
}
}
return subList;
}
This error happens if the GET Parameter currentPage is set (for example from
an old session or an old link), but there are not enought items in the
current Collection.
--
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: (MGNLSTK-677) Exception in STKPager::getPageItem()
[
http://jira.magnolia-cms.com/browse/MGNLSTK-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=30020#action_30020
]
Stefan Baur commented on MGNLSTK-677:
-
yes, you are right.
you should return the last available sublist instead.
or the first?
Exception in STKPager::getPageItem()
Key: MGNLSTK-677
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-677
Project: Magnolia Standard Templating Kit
Issue Type: Bug
Components: paragraphs
Affects Versions: 1.3.4
Reporter: Stefan Baur
Assignee: Ondřej Chytil
Priority: Trivial
Fix For: 1.3.x
Original Estimate: 0.25h
Remaining Estimate: 0.25h
the following line
subList = ((List)items).subList(offset, limit);
generates an exception
java.lang.IllegalArgumentException: fromIndex(4) toIndex(2)
if offset is larger than limit.
FIX:
public Collection getPageItems() {
Collection subList = items;
int offset = getOffset();
if(count 0) {
int limit = maxResultsPerPage + offset;
if(items.size() limit) {
limit = count;
}
if(offset limit){
subList = ((List)items).subList(offset, limit);
}else{
subList = items;
}
}
return subList;
}
This error happens if the GET Parameter currentPage is set (for example from
an old session or an old link), but there are not enought items in the
current Collection.
--
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: (MGNLSTK-6 78) Conditional Comments für CSS und JS Dateien
[ http://jira.magnolia-cms.com/browse/MGNLSTK-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Baur updated MGNLSTK-678: Issue Type: New Feature (was: Bug) Conditional Comments für CSS und JS Dateien Key: MGNLSTK-678 URL: http://jira.magnolia-cms.com/browse/MGNLSTK-678 Project: Magnolia Standard Templating Kit Issue Type: New Feature Components: base system Affects Versions: 1.3.4 Reporter: Stefan Baur Assignee: Philipp Bärfuss Original Estimate: 0.5d Remaining Estimate: 0.5d It would be very nice, if the bean info.magnolia.module.templatingkit.resources.Resource had a property for conditional comments. If the property is set, the file is rendered in a conditional comment. Example for js: !--[if lte IE 6] script src=js/DD_belatedPNG_0.0.8a-min.js type=text/javascript/script ![endif]-- Example for css: !--[if lte IE 6] link href=stylesheets/ie6.css rel=stylesheet type=text/css / ![endif]-- -- 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: (MGNLSTK-677) Exception in STKPager::getPageItem()
Exception in STKPager::getPageItem()
Key: MGNLSTK-677
URL: http://jira.magnolia-cms.com/browse/MGNLSTK-677
Project: Magnolia Standard Templating Kit
Issue Type: Bug
Components: paragraphs
Affects Versions: 1.3.4
Reporter: Stefan Baur
Assignee: Philipp Bärfuss
Priority: Trivial
the following line
subList = ((List)items).subList(offset, limit);
generates an exception
java.lang.IllegalArgumentException: fromIndex(4) toIndex(2)
if offset is larger than limit.
FIX:
public Collection getPageItems() {
Collection subList = items;
int offset = getOffset();
if(count 0) {
int limit = maxResultsPerPage + offset;
if(items.size() limit) {
limit = count;
}
if(offset limit){
subList = ((List)items).subList(offset, limit);
}else{
subList = items;
}
}
return subList;
}
This error happens if the GET Parameter currentPage is set (for example from an
old session or an old link), but there are not enought items in the current
Collection.
--
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: (MGNLSTK-661) maximale Anzahl von Paragraphen in den Areas konfigurierbar machen (Area.java)
maximale Anzahl von Paragraphen in den Areas konfigurierbar machen (Area.java) -- Key: MGNLSTK-661 URL: http://jira.magnolia-cms.com/browse/MGNLSTK-661 Project: Magnolia Standard Templating Kit Issue Type: New Feature Affects Versions: 1.3.1 Reporter: Stefan Baur Assignee: Philipp Bärfuss Priority: Minor Es wäre schön, wenn man die maximale Anzahl von Paragraphen in einer Area per config übergeben könnte. Diese Lösung wäre flexibler als z.B. das Singleton Template. Man könnte beispielsweise 4 verschiedene paragraphen zur Auswahl stellen, aber trotzdem nach zwei erfassten Paragraphen keinen weiteren mehr zulassen (newbar nicht mehr anzeigen). Auf diese Weise könnte man mit dem Standard Template/Model ganz einfach die verschiedensten Szenarien abdecken, ohne jeweils ein neues ftl alegen zu müssen und eigene Template- und Model-Klassen zu schreiben. Aus meiner (noch etwas eingeschränkten) Sicht solte sich sowohl der Implementierung- wie auch der Test-aufwand in Grenzen halten. Es stellt sich eventuell die Frage, wie oder ob man diese Funktionalität für Promos einbauen könnte. Da spielt ja die Vererbung noch mit... -- 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: (MGNLSTK-661) maximale Anzahl von Paragraphen in den Areas konfigurierbar machen (Area.java)
[ http://jira.magnolia-cms.com/browse/MGNLSTK-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=29002#action_29002 ] Stefan Baur commented on MGNLSTK-661: - I just realized, that I had to write in English. Summary: Enable the configuration of maximum Paragraphs for Areas to provide flexible functionality in templating. You would be able to configure 4 available paragraphs, but enable the author just to add 2 paragraphs (no matter wich ones). the effort should not be too big. maybe there are issues with paragraph inheritence for example in the promos area... maximale Anzahl von Paragraphen in den Areas konfigurierbar machen (Area.java) -- Key: MGNLSTK-661 URL: http://jira.magnolia-cms.com/browse/MGNLSTK-661 Project: Magnolia Standard Templating Kit Issue Type: New Feature Affects Versions: 1.3.1 Reporter: Stefan Baur Assignee: Philipp Bärfuss Priority: Minor Es wäre schön, wenn man die maximale Anzahl von Paragraphen in einer Area per config übergeben könnte. Diese Lösung wäre flexibler als z.B. das Singleton Template. Man könnte beispielsweise 4 verschiedene paragraphen zur Auswahl stellen, aber trotzdem nach zwei erfassten Paragraphen keinen weiteren mehr zulassen (newbar nicht mehr anzeigen). Auf diese Weise könnte man mit dem Standard Template/Model ganz einfach die verschiedensten Szenarien abdecken, ohne jeweils ein neues ftl alegen zu müssen und eigene Template- und Model-Klassen zu schreiben. Aus meiner (noch etwas eingeschränkten) Sicht solte sich sowohl der Implementierung- wie auch der Test-aufwand in Grenzen halten. Es stellt sich eventuell die Frage, wie oder ob man diese Funktionalität für Promos einbauen könnte. Da spielt ja die Vererbung noch mit... -- 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: (MGNLSTK-637) STKUtil does not return 'null' to freemarker when DAMException is caught
[ http://jira.magnolia-cms.com/browse/MGNLSTK-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=28931#action_28931 ] Stefan Baur commented on MGNLSTK-637: - I agree. This little fix would be a nice improvement. STKUtil does not return 'null' to freemarker when DAMException is caught Key: MGNLSTK-637 URL: http://jira.magnolia-cms.com/browse/MGNLSTK-637 Project: Magnolia Standard Templating Kit Issue Type: Improvement Components: base system Affects Versions: 1.3.1 Reporter: Christian Ringele Assignee: Philipp Bärfuss STKUtil.java line 144 163: When a DAMException is caught, a RuntimeException is thrown, but null is not returned. When choosing from DMS (uuidLink Control) a folder instead an image, freemarker template does not get a 'null' as return. This makes this case much harder to handle in the template. -- 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
