[magnolia-dev] [JIRA] (MGNLUI-3956) Error with Content App using LinkField link to another content app

[JIRA (on behalf of Maxime Themens)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Maxime Themens created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia UI /  MGNLUI-3956 
 
 
 
  Error with Content App using LinkField link to another content app  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 5.4.6 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Attachments:
 

 stacktrace.txt 
 
 
 

Components:
 

 content app 
 
 
 

Created:
 

 20/Jul/16 10:33 PM 
 
 
 

Environment:
 

 Dev 
 
 
 

Labels:
 

 support 
 
 
 

Priority:
 
  Minor 
 
 
 

Reporter:
 
 Maxime Themens 
 
 
 

Security Level:
 

 Public 
 

[magnolia-dev] [JIRA] (NPMCLI-25) Local mgnl cli configuration should be used automatically

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-25 
 
 
 
  Local mgnl cli configuration should be used automatically  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 Currently it is not that easy to set a project to use a local mgnl cli configuration, and people could easily make mistakes and use the wrong cli configuration if they forget to change the configuration. This is because the config to be used is set globally via an environment  value  varialbe . Ideally running mgnl in a directory should use the local config if present. This is how the npm cli works.A few possible problematic scenarios:* I am working on two (or more) projects with custom configs. After a break I come back to a project, but when I start using the cli it's creating files based on the config from another project.* I am working on a project in a team. A teammate checked in the mgnl cli configuration, I get the project and start working but did not know that I had to set the ENV variable to use this config and therefore I'm using the wrong one.* I set an ENV variable via the 'export' command, but come back to the project later or in another tab and local configuration is no longer used.Some of these are partially mitigated by the helpful INFO message that the CLI gives{code}INFO: MGNLCLI_HOME env variable is set. Using prototypes at /Users/czimmermann/Documents/a-projects/lightdev-lab/mgnl-cli/test4{code}Proposal:When running the mgnl command, search up the directory tree for the existance of an mgnl cli config file. If none exists, then use the global one. Perhaps an optional simple text file could point to an mgnl cli config to use. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 

[magnolia-dev] [JIRA] (NPMCLI-25) Local mgnl cli configuration should be used automatically

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-25 
 
 
 
  Local mgnl cli configuration should be used automatically  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 When running the mgnl command, search up the directory tree for the existance of an mgnl cli config file. If none exists, then fall back to the global one defined by the MGNLCLI_HOME, or eventually to the global one deliverd during the global npm install. *Reason:* Currently it is not that easy to set a project to use a local mgnl cli configuration, and people could easily make mistakes and use the wrong cli configuration if they forget to change the configuration. This is because the config to be used is set globally via an environment varialbe. Ideally running mgnl in a directory should use the local config if present. This is how the npm cli works.A few possible problematic scenarios:* I am working on two (or more) projects with custom configs. After a break I come back to a project, but when I start using the cli it's creating files based on the config from another project.* I am working on a project in a team. A teammate checked in the mgnl cli configuration, I get the project and start working but did not know that I had to set the ENV variable to use this config and therefore I'm using the wrong one.* I set an ENV variable via the 'export' command, but come back to the project later or in another tab and local configuration is no longer used.Some of these are partially mitigated by the helpful INFO message that the CLI gives{code}INFO: MGNLCLI_HOME env variable is set. Using prototypes at /Users/czimmermann/Documents/a-projects/lightdev-lab/mgnl-cli/test4{code} Proposal:When running the mgnl command, search up the directory tree for the existance of an mgnl cli config file. If none exists, then use the global one. Perhaps an optional simple text file could point to an mgnl cli config to use. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 

[magnolia-dev] [JIRA] (NPMCLI-27) Own config file for mgnl-cli instead of package.json

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-27 
 
 
 
  Own config file for mgnl-cli instead of package.json  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 There are problems with using the package.json file to store the configuration for the CLI, now that it is installed globally, and new "instances" of configuration can be created with "mgnl setup". Configuration nodes specific to the mgnl cli (setupMagnolia, config, lightModuleName, lightDevFoldersInModule, lightDevCopyResources) should be removed from the master package.json and stored in a new file "mgnl-cli.json". When "mgnl setup" is run, this file should be copied to current directory, but package.json should not be copied.The _prototypes directory should also be renamed to "mgnl-cli-prototypes" because the name is not specific enough and will be confusing when copied into project directories with "mgnl setup". * Reasons**  When having a local mgnl-cli configuration in your project, It is incorrect to use package.json because in this context it is not an npm module. Also, it's simply confusing to have an additional package.json, especially if you are working on an npm module, which should be a common practice with light development. * The contents of the package.json get alphabetically re-ordered and additional meta information is added via npm processes which make the file hard to work with, plus it stores a lot of irrelevant information. Configuration for * Much of  the  mgnl cli should be stored in a new file  package .  Maybe "mgnl-cli. json " or "mgnl  info (dependencies, devDependencies) is irrelevant in this context - cli and therefore confusing . yaml" depending * Based  on  its format  analysis of _javascript_ cli's - having a dedicated config file for the CLI is standard practice .  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
   

[magnolia-dev] [JIRA] (NPMCLI-39) Remove jquery from default configuration

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-39 
 
 
 
  Remove jquery from default configuration  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 20/Jul/16 5:15 PM 
 
 
 

Labels:
 

 quickwin 
 
 
 

Priority:
 
  Neutral 
 
 
 

Reporter:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 
A specific jquery version should not be included in the default configuration for the CLI.  Remove jquery from dependencies and from lightDevCopyResources 
Reason: A dev may or may not want jquery in my project.  A dev wants to choose the version of jquery.  Even if a dev wants Jquery, they would only want it in one of my projects light-modules, not all of them. 
Note: The feature and the default value made more sense when mgnl cli was installed locally instead of globally because the configuration was right there to edit - and was typically related to one light module. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
   

[magnolia-dev] [JIRA] (NPMCLI-36) Improve descriptions for create-component

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-36 
 
 
 
  Improve descriptions for create-component  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 Some of the "create-component" self documentation is not clear.Fix to:Creates a component and optionally makes it available (or autogenerated) in a given area of a page. E.g. mgnl create-component foo -a myPage@main -p /path/to/module-a, --available <[moduleName:][relPath/]page@area> Make available on page in area-g, --autogenerate <[moduleName:][relPath/]page@area> Autogenerate on page in area  
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (NPMCLI-33) lightDevCopyResources concept is broken by global install

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-33 
 
 
 
  lightDevCopyResources concept is broken by global install  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 *TLDR*lightDevCopyResources concept is broken now that mgnl is installed globally.For now  to avoid confusion , remove the lightDevCopyResources configuration from the default configuration,  to avoid confusion  and jquery from the package . json dependencies. *Details*The lightDevCopyResources configuration copies a file from the cli's node_modules directory to a light modules resource directory. This allows one to take advantage of npm to download an  npm dependency declared in package.json "dependencies" (- ie jquery), and then copy that file into any new light module. Of course, for npm to download that declared dependency, one must run "npm install" on the cli project. So if a user wanted to use a new resource, they cannot just alter the cli configuration and run "mgnl create-light-module", they need to know that they must "npm install" again.However, now that the mgnl cli is typically (very conveniently) installed globally so that one can run "mgnl" from any location - this mechanism is broken and confusing.What is broken is that @magnolia/cli is only installed once, and so its declared npm dependencies are only installed that one time. If I now run "mgnl setup" to get the cli files to customize, I can only get different npm "dependencies" (for example angular, or to select different version of jquery), and therefore lightDevCopyResources, with confusing side-effects:* Changing the "dependencies" in the local package.json created by "mgnl setup", will have no effect. Even if I were to run "npm install" on this local package.json - the dependencies would not be available to lightDevCopyResources. (because it accesses the global directory.)* Changing the "dependencies" on the globally installed package.json, and trying to rerun "npm install" might be possible but I could not figure out how to do it. Even if it worked, then you would change the version of a module - and all projects would get that version - which might not be what you want. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
   

[magnolia-dev] [JIRA] (NPMCLI-33) lightDevCopyResources concept is broken by global install

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-33 
 
 
 
  lightDevCopyResources concept is broken by global install  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 

Labels:
 
 quickwin 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (NPMCLI-33) lightDevCopyResources concept is broken by global install

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-33 
 
 
 
  lightDevCopyResources concept is broken by global install  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 *TLDR ;  *lightDevCopyResources concept is broken now that mgnl is installed globally.For now, remove the lightDevCopyResources configuration from the default configuration, to avoid confusion.*Details*The lightDevCopyResources configuration copies a file from the cli's node_modules directory to a light modules resource directory. This allows one to take advantage of npm to download an  npm dependency declared in package.json "dependencies" (- ie jquery), and then copy that file into any new light module. Of course, for npm to download that declared dependency, one must run "npm install" on the cli project. So if a user wanted to use a new resource, they cannot just alter the cli configuration and run "mgnl create-light-module", they need to know that they must "npm install" again.However, now that the mgnl cli is typically (very conveniently) installed globally so that one can run "mgnl" from any location - this mechanism is broken and confusing.What is broken is that @magnolia/cli is only installed once, and so its declared npm dependencies are only installed that one time. If I now run "mgnl setup" to get the cli files to customize, I can only get different npm "dependencies" (for example angular, or to select different version of jquery), and therefore lightDevCopyResources, with confusing side-effects:* Changing the "dependencies" in the local package.json created by "mgnl setup", will have no effect. Even if I were to run "npm install" on this local package.json - the dependencies would not be available to lightDevCopyResources. (because it accesses the global directory.)* Changing the "dependencies" on the globally installed package.json, and trying to rerun "npm install" might be possible but I could not figure out how to do it. Even if it worked, then you would change the version of a module - and all projects would get that version - which might not be what you want. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
   

[magnolia-dev] [JIRA] (NPMCLI-38) Simple way for module to include required resources in page

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-38 
 
 
 
  Simple way for module to include required resources in page  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 20/Jul/16 3:55 PM 
 
 
 

Priority:
 
  Neutral 
 
 
 

Reporter:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 
There should be a mechanism for a module to easily provide its web resources to the pages. 
With package.json, modules can have dependencies to libraries like jquery, etc. It will be useful if the CLI can assist with making these resources available automatically, so a user of a light module can use the components it provides with no or minimal configuration. 
Previously this was solved with the lightDevCopyResources configuration - but that has issues now that mgnl is installed globally. See linked ticket. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 

[magnolia-dev] [JIRA] (NPMCLI-33) lightDevCopyResources concept is broken by global install

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-33 
 
 
 
  lightDevCopyResources concept is broken by global install  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 

Account:
 
 null (null) 
 
 
 
 
 
 
 
 
 
 *TLDR; *lightDevCopyResources concept is broken now that mgnl is installed globally.For now, remove the lightDevCopyResources configuration from the default configuration, to avoid confusion.*Details* The lightDevCopyResources configuration copies a file from the cli's node_modules directory to a light modules resource directory. This allows one to take advantage of npm to download an  npm dependency declared in package.json "dependencies" (- ie jquery), and then copy that file into any new light module. Of course, for npm to download that declared dependency, one must run "npm install" on the cli project. So if a user wanted to use a new resource, they cannot just alter the cli configuration and run "mgnl create-light-module", they need to know that they must "npm install" again.However, now that the mgnl cli is typically (very conveniently) installed globally so that one can run "mgnl" from any location - this mechanism is broken and confusing.What is broken is that @magnolia/cli is only installed once, and so its declared npm dependencies are only installed that one time. If I now run "mgnl setup" to get the cli files to customize, I can only get different npm "dependencies" (for example angular, or to select different version of jquery), and therefore lightDevCopyResources, with confusing side-effects:* Changing the "dependencies" in the local package.json created by "mgnl setup", will have no effect. Even if I were to run "npm install" on this local package.json - the dependencies would not be available to lightDevCopyResources. (because it accesses the global directory.)* Changing the "dependencies" on the globally installed package.json, and trying to rerun "npm install" might be possible but I could not figure out how to do it. Even if it worked, then you would change the version of a module - and all projects would get that version - which might not be what you want. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 

[magnolia-dev] [JIRA] (NPMCLI-34) Command 'create-light-module' cannot handle absolute path

[JIRA (on behalf of Federico Grilli)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Federico Grilli updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-34 
 
 
 
  Command 'create-light-module' cannot handle absolute path  
 
 
 
 
 
 
 
 
 

Change By:
 
 Federico Grilli 
 
 
 

Summary:
 
 command Command  'create-light-module' cannot handle absolute path 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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-3951) Backport - German language is causing design irregularities

[JIRA (on behalf of Federico Grilli)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Federico Grilli updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia UI /  MGNLUI-3951 
 
 
 
  Backport - German language is causing design irregularities  
 
 
 
 
 
 
 
 
 

Change By:
 
 Federico Grilli 
 
 
 

Assignee:
 
 Federico Grilli 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (NPMCLI-6) do not duplicate areas

[on behalf of Tomáš Gregovský]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Tomáš Gregovský updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-6 
 
 
 
  do not duplicate areas  
 
 
 
 
 
 
 
 
 

Change By:
 
 Tomáš Gregovský 
 
 
 

Assignee:
 
 Tomáš Gregovský 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (NPMCLI-6) do not duplicate areas

[on behalf of Tomáš Gregovský]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Tomáš Gregovský updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-6 
 
 
 
  do not duplicate areas  
 
 
 
 
 
 
 
 
 

Change By:
 
 Tomáš Gregovský 
 
 
 
 
 
 
 
 
 
 currently add-availability script when it doesn't find proper area in yaml configuration (page definition) will create this configuration and into ftl file will add freemarker code to render that area. Unfortunately for pages we have one ftl file - main.ftl and if add-availability for compA into homePage it will does it (add area configuration, add ftl to render area). But then if add-availability for compB to standardPage which share same main.ftl, then this area is added into ftl again (duplication).So modify add-availability script to first check if that area '[#cms.area name="< areaNam areaName >" ' (do not close, there can be extra parameters for area) already exist in ftl file. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (NPMCLI-37) Install shows deprecation warnings including "RegExp DoS issue"

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-37 
 
 
 
  Install shows deprecation warnings including "RegExp DoS issue"  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Task 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 20/Jul/16 2:07 PM 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 
Evalute dependencies and upgrade as appropriate to remove deprecation warnings. 
Warnings shown: npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue npm WARN deprecated to-iso-string@0.0.2: to-iso-string has been deprecated, use @segment/to-iso-string instead. npm WARN deprecated jade@0.26.3: Jade has been renamed to pug, please install the latest version of pug instead of jade npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue 
To Reproduce - check out code from git to a new location. And install with command: npm --registry=https://npm.magnolia-cms.com/repository/npm install 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
   

[magnolia-dev] [JIRA] (NPMCLI-36) Improve descriptions for create-component

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-36 
 
 
 
  Improve descriptions for create-component  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 

Labels:
 
 quickwin 
 
 
 

Account:
 
 null (null) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (NPMCLI-36) Improve descriptions for create-component

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-36 
 
 
 
  Improve descriptions for create-component  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 20/Jul/16 1:55 PM 
 
 
 

Priority:
 
  Neutral 
 
 
 

Reporter:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 
Some of the "create-component" self documentation is not clear. 
Fix to: Creates a component and optionally makes it available (or autogenerated) in a given area of a page. E.g. mgnl create-component foo -a myPage@main -p /path/to/module 
-a, --available <[moduleName:][relPath/]page@area> Make available on page in area -g, --autogenerate <[moduleName:][relPath/]page@area> Autogenerate on page in area 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

  

[magnolia-dev] [JIRA] (NPMCLI-27) Own config file for mgnl-cli instead of package.json

[JIRA (on behalf of Christopher Zimmermann)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Christopher Zimmermann updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-27 
 
 
 
  Own config file for mgnl-cli instead of package.json  
 
 
 
 
 
 
 
 
 

Change By:
 
 Christopher Zimmermann 
 
 
 
 
 
 
 
 
 
 There are problems with using the package.json file to store the configuration for the CLI , now that it is installed globally, and new "instances" of configuration can be created with "mgnl setup" .  * When having a local mgnl -cli  configuration in your project, It is incorrect to use package.json because in this context it is not an npm module. Also, it's simply confusing to have an additional package.json, especially if you are working on an npm module, which should be a common practice with light development. * The contents of the package.json get alphabetically re-ordered and additional meta information is added via npm processes which make the file hard to work with, plus it stores a lot of irrelevant information.Configuration for the mgnl cli should be stored in a new file. Maybe "mgnl-cli.json" or "mgnl-cli.yaml" depending on its format. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (NPMCLI-34) command 'create-light-module' cannot handle absolute path

[JIRA (on behalf of Federico Grilli)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Federico Grilli updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-34 
 
 
 
  command 'create-light-module' cannot handle absolute path  
 
 
 
 
 
 
 
 
 

Change By:
 
 Federico Grilli 
 
 
 

Story Points:
 
 1 
 
 
 

Account:
 
 null (null) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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-1600) URI decoding is not required anymore

[JIRA (on behalf of Philip Mundt)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Philip Mundt updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia UI /  MGNLUI-1600 
 
 
 
  URI decoding is not required anymore  
 
 
 
 
 
 
 
 
 

Change By:
 
 Philip Mundt 
 
 
 

Assignee:
 
 Philip Mundt 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (OAUTH-2) OAuth integration

[JIRA (on behalf of Philip Mundt)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Philip Mundt updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia OAuth Support /  OAUTH-2 
 
 
 
  OAuth integration  
 
 
 
 
 
 
 
 
 

Change By:
 
 Philip Mundt 
 
 
 

Assignee:
 
 Philip Mundt 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (MGNLCACHE-138) Platform outages ostensibly relating to licensing issues

[JIRA (on behalf of Isobel Bradshaw)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Isobel Bradshaw created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia Cache Module /  MGNLCACHE-138 
 
 
 
  Platform outages ostensibly relating to licensing issues  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Affects Versions:
 

 5.4.4 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Attachments:
 

 magnolia-screenshot.png 
 
 
 

Created:
 

 20/Jul/16 10:37 AM 
 
 
 

Priority:
 
  Blocker 
 
 
 

Reporter:
 
 Isobel Bradshaw 
 
 
 
 
 
 
 
 
 
 
We have experienced some outages which seem to suggest issues with the license. I've attached a screen grab from Pulse to illustrate the issue. The client (TalkTalk) has an Enteprise Standard license which should cover the functionality we are using (which is quite minimal), but even when using another partner's development license, the issue seems to recur. We can supply logs and any other content you need. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 

[magnolia-dev] [JIRA] (NPMCLI-35) Error when creating component with -a availability option, outside the light module

[JIRA (on behalf of Federico Grilli)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Federico Grilli updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia CLI npm module  /  NPMCLI-35 
 
 
 
  Error when creating component with -a availability option, outside the light module  
 
 
 
 
 
 
 
 
 

Change By:
 
 Federico Grilli 
 
 
 

Story Points:
 
 1 
 
 
 

Account:
 
 null (null) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (MGNLGROOVY-143) Rescue app is broken due to i18n not being set up

[JIRA (on behalf of Ilgun Ilgun)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ilgun Ilgun updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia Groovy Module /  MGNLGROOVY-143 
 
 
 
  Rescue app is broken due to i18n not being set up  
 
 
 
 
 
 
 
 
 

Change By:
 
 Ilgun Ilgun 
 
 
 
 
 
 
 
 
 
 Vaadin {{Terminal}} used in there tries to grab a {{SimpleTranslator}}, which is backed by {{TranslationService}}, which in turn requires the {{I18nModule}} via provider.h3. ObservationsIMO problem is not the {{TranslationService}} is being instantiated properly or not. The problem appears to be the {{ModulesStartedEvent}} is not thrown and thus {{TranslationServiceImpl#messageBundles}} is null and therefore we have the NPE.Had the {{ModulesStartedEvent}} fired in the rescue app solves the situation thus proves the observations above (With reverting I18nModule#isDebug in {{TranslationServiceImpl}} ). {{TranslationServiceImpl#messageBundles}} used to be populated upon each request and rightfully changed with MAGNOLIA-6556 in a way that {{ModulesStartedEvent}}  is consumed in the {{TranslationServiceImpl}}'s constructor and leads to population of the {{TranslationServiceImpl#messageBundles}}. h3. Proposed solution1) Having {{TranslationServiceImpl#messageBundles}} populated explicitly in the rescue app via {{TranslationService#reloadMessageBundles()}}2) Occurrences of {{i18nModuleProvider.get().isDebug()}} replaced with a method which returns false if i18nModuleProvider returns null or throws {{ProvisionException}}. https://git h3 .  Steps to reproduce - Use a repository that is working with version 5.3 of magnolia . - cms  Stop Mgnl and start a mgnl with version 5 . com/projects/MODULES/repos/groovy/commits/98d2042e755bd179ad9f5ba82141ba1e133b2a84 4.7 on the 5.3 Mgnl repository  https://git    *+Be sure to configure the web . magnolia xml to enable the groovy rescue servlet+* - cms.com/projects/PLATFORM/repos/main/commits/a9ce156383c836dfe503974e6604e1f44572847e  When the server is up and running no groovy rescue servlet appears 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
  

[magnolia-dev] [JIRA] (MGNLUI-3955) Switching authoring locale changes values of non-i18ned fields

[on behalf of Ervín Výstup]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ervín Výstup updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Magnolia UI /  MGNLUI-3955 
 
 
 
  Switching authoring locale changes values of non-i18ned fields  
 
 
 
 
 
 
 
 
 

Change By:
 
 Ervín Výstup 
 
 
 

Affects Version/s:
 
 5.4.5 
 
 
 

Affects Version/s:
 
 5.4.4 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (CFGUI-19) Make filter combos captions human-friendly

[JIRA (on behalf of Aleksandr Pchelintcev)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Aleksandr Pchelintcev updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Definitions app /  CFGUI-19 
 
 
 
  Make filter combos captions human-friendly  
 
 
 
 
 
 
 
 
 

Change By:
 
 Aleksandr Pchelintcev 
 
 
 

Assignee:
 
 Aleksandr Pchelintcev 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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] (CFGUI-20) Make appearance of filter combos lighter so that when they are used n conjunction with labels they form some sort of a sentence

[JIRA (on behalf of Aleksandr Pchelintcev)]

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Aleksandr Pchelintcev updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Definitions app /  CFGUI-20 
 
 
 
  Make appearance of filter combos lighter so that when they are used n conjunction with labels they form some sort of a sentence  
 
 
 
 
 
 
 
 
 

Change By:
 
 Aleksandr Pchelintcev 
 
 
 

Assignee:
 
 Aleksandr Pchelintcev 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   




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: