Dominik Marks 4 Years Ago - Edited What can we expect from the rolling release feature in terms of upgrade processes? To update from 7.3.0 GA1 to 7.3.1 GA2 do we still have to shut down 7.3.0, run the upgrade tool and start up 7.3.1? Or can we just shut down 7.3.0 and start up 7.3.1 immediately and everything is done? If not, is that a planned feature? Please sign in to reply. Reply as... Cancel Krzysztof Gołębiowski Dominik Marks 4 Years Ago - Edited We have a new experimental environment in our company, that initially was built on the last GA release of 7.2, then migrated to 7.3 GA1. A few days ago I tried to migrate it to 7.3 GA2 using the standard upgrade-tool and even though it was mostly successful (there were some issues with messageboards that we don't use at all) the final portal was broken. There were many weird exceptions in logs during runtime, and entire Web Content together with all the articles was gone. I didn't want to lose my time on fixing upgrade issues and as there is not much functionality on that site, I just scrapped the old instance and installed everything on fresh Liferay GA3. Be careful when doing your upgrade :) Please sign in to reply. Reply as... Cancel James Hinkey Dominik Marks 4 Years Ago Hi Dominik, Upgrading via the Docker image accomplishes what you're looking for. See https://learn.liferay.com/dxp-7.x/installation-and-upgrades/upgrading-liferay-dxp/upgrade-basics/upgrading-via-docker.html. Please sign in to reply. Reply as... Cancel Jorge Ferrer Dominik Marks 4 Years Ago You can achieve that by setting the following portal property to true: # # Set this to true to execute the upgrade process when the portal starts and # modules are activated. # # Env: LIFERAY_UPGRADE_PERIOD_DATABASE_PERIOD_AUTO_PERIOD_RUN # upgrade.database.auto.run=false This actually used to be true by default, but in many production environment that turned out to be undesirable because more control is desired over changes to the database model, which is why we now recommend using the upgrade tool. But if this is valid for your case, it's a simpler process. Please sign in to reply. Reply as... Cancel Mike Bigelow Jorge Ferrer 4 Years Ago - Edited Hi, I'm installing 7.3.1 GA2 atm, and curious about the upgrade process when 7.3.2 is released. 1. Is this setting all this is required to upgrade both the files and DB? upgrade.database.auto.run= false 2. Is it set in the portal-ext.properties file followed by a shutdown/startup? 3. Any other requirements to upgrade in the future 7.3.1 to 7.3.2? Please sign in to reply. Reply as... Cancel James Hinkey Mike Bigelow 4 Years Ago Hi Mike, 1. It only upgrades the DB. It's best to check the Upgrade Overview (linked below) to determine what else might need upgrading in your DXP installation. 2. It's recommended to use the -e LIFERAY_UPGRADE_PERIOD_DATABASE_PERIOD_AUTO_PERIOD_RUN=true argument for the auto run over using a portal property, because it's easy to forget to disable the property once you've set it. :-) ... running the database upgrade again by mistake may cause issues. 3. I'm not sure whether there will be new upgrade requirements for 7.3.2. We're not expecting any at this time. Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira James Hinkey 4 Years Ago Regarding the point 3, it won't any other requirements to upgrade to the GA3 or future GAs. Please sign in to reply. Reply as... Cancel Mike Bigelow James Hinkey 4 Years Ago - Edited To confirm only these steps below in the link are required to upgrade later on? (unless a new upgrade requirement is listed). And these steps "Upgrading Via Docker" will perform all files & DB? https://learn.liferay.com/dxp-7.x/installation-and-upgrades/upgrading-liferay-dxp/upgrade-basics/upgrading-via-docker.html Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira Mike Bigelow 4 Years Ago Hi Mike, If you mean document library files when you says "files", yes, the upgrade takes care of it (although there are no modifications in this matter during the upgrade between 7.3 GAs. If you mean Liferay jar files, then, if you use the latest docker image to upgrade, yes, the updated jars for latest GA will be available. I hope it helps. Cheers! Please sign in to reply. Reply as... Cancel
Krzysztof Gołębiowski Dominik Marks 4 Years Ago - Edited We have a new experimental environment in our company, that initially was built on the last GA release of 7.2, then migrated to 7.3 GA1. A few days ago I tried to migrate it to 7.3 GA2 using the standard upgrade-tool and even though it was mostly successful (there were some issues with messageboards that we don't use at all) the final portal was broken. There were many weird exceptions in logs during runtime, and entire Web Content together with all the articles was gone. I didn't want to lose my time on fixing upgrade issues and as there is not much functionality on that site, I just scrapped the old instance and installed everything on fresh Liferay GA3. Be careful when doing your upgrade :) Please sign in to reply. Reply as... Cancel
James Hinkey Dominik Marks 4 Years Ago Hi Dominik, Upgrading via the Docker image accomplishes what you're looking for. See https://learn.liferay.com/dxp-7.x/installation-and-upgrades/upgrading-liferay-dxp/upgrade-basics/upgrading-via-docker.html. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Dominik Marks 4 Years Ago You can achieve that by setting the following portal property to true: # # Set this to true to execute the upgrade process when the portal starts and # modules are activated. # # Env: LIFERAY_UPGRADE_PERIOD_DATABASE_PERIOD_AUTO_PERIOD_RUN # upgrade.database.auto.run=false This actually used to be true by default, but in many production environment that turned out to be undesirable because more control is desired over changes to the database model, which is why we now recommend using the upgrade tool. But if this is valid for your case, it's a simpler process. Please sign in to reply. Reply as... Cancel Mike Bigelow Jorge Ferrer 4 Years Ago - Edited Hi, I'm installing 7.3.1 GA2 atm, and curious about the upgrade process when 7.3.2 is released. 1. Is this setting all this is required to upgrade both the files and DB? upgrade.database.auto.run= false 2. Is it set in the portal-ext.properties file followed by a shutdown/startup? 3. Any other requirements to upgrade in the future 7.3.1 to 7.3.2? Please sign in to reply. Reply as... Cancel James Hinkey Mike Bigelow 4 Years Ago Hi Mike, 1. It only upgrades the DB. It's best to check the Upgrade Overview (linked below) to determine what else might need upgrading in your DXP installation. 2. It's recommended to use the -e LIFERAY_UPGRADE_PERIOD_DATABASE_PERIOD_AUTO_PERIOD_RUN=true argument for the auto run over using a portal property, because it's easy to forget to disable the property once you've set it. :-) ... running the database upgrade again by mistake may cause issues. 3. I'm not sure whether there will be new upgrade requirements for 7.3.2. We're not expecting any at this time. Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira James Hinkey 4 Years Ago Regarding the point 3, it won't any other requirements to upgrade to the GA3 or future GAs. Please sign in to reply. Reply as... Cancel Mike Bigelow James Hinkey 4 Years Ago - Edited To confirm only these steps below in the link are required to upgrade later on? (unless a new upgrade requirement is listed). And these steps "Upgrading Via Docker" will perform all files & DB? https://learn.liferay.com/dxp-7.x/installation-and-upgrades/upgrading-liferay-dxp/upgrade-basics/upgrading-via-docker.html Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira Mike Bigelow 4 Years Ago Hi Mike, If you mean document library files when you says "files", yes, the upgrade takes care of it (although there are no modifications in this matter during the upgrade between 7.3 GAs. If you mean Liferay jar files, then, if you use the latest docker image to upgrade, yes, the updated jars for latest GA will be available. I hope it helps. Cheers! Please sign in to reply. Reply as... Cancel
Mike Bigelow Jorge Ferrer 4 Years Ago - Edited Hi, I'm installing 7.3.1 GA2 atm, and curious about the upgrade process when 7.3.2 is released. 1. Is this setting all this is required to upgrade both the files and DB? upgrade.database.auto.run= false 2. Is it set in the portal-ext.properties file followed by a shutdown/startup? 3. Any other requirements to upgrade in the future 7.3.1 to 7.3.2? Please sign in to reply. Reply as... Cancel James Hinkey Mike Bigelow 4 Years Ago Hi Mike, 1. It only upgrades the DB. It's best to check the Upgrade Overview (linked below) to determine what else might need upgrading in your DXP installation. 2. It's recommended to use the -e LIFERAY_UPGRADE_PERIOD_DATABASE_PERIOD_AUTO_PERIOD_RUN=true argument for the auto run over using a portal property, because it's easy to forget to disable the property once you've set it. :-) ... running the database upgrade again by mistake may cause issues. 3. I'm not sure whether there will be new upgrade requirements for 7.3.2. We're not expecting any at this time. Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira James Hinkey 4 Years Ago Regarding the point 3, it won't any other requirements to upgrade to the GA3 or future GAs. Please sign in to reply. Reply as... Cancel Mike Bigelow James Hinkey 4 Years Ago - Edited To confirm only these steps below in the link are required to upgrade later on? (unless a new upgrade requirement is listed). And these steps "Upgrading Via Docker" will perform all files & DB? https://learn.liferay.com/dxp-7.x/installation-and-upgrades/upgrading-liferay-dxp/upgrade-basics/upgrading-via-docker.html Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira Mike Bigelow 4 Years Ago Hi Mike, If you mean document library files when you says "files", yes, the upgrade takes care of it (although there are no modifications in this matter during the upgrade between 7.3 GAs. If you mean Liferay jar files, then, if you use the latest docker image to upgrade, yes, the updated jars for latest GA will be available. I hope it helps. Cheers! Please sign in to reply. Reply as... Cancel
James Hinkey Mike Bigelow 4 Years Ago Hi Mike, 1. It only upgrades the DB. It's best to check the Upgrade Overview (linked below) to determine what else might need upgrading in your DXP installation. 2. It's recommended to use the -e LIFERAY_UPGRADE_PERIOD_DATABASE_PERIOD_AUTO_PERIOD_RUN=true argument for the auto run over using a portal property, because it's easy to forget to disable the property once you've set it. :-) ... running the database upgrade again by mistake may cause issues. 3. I'm not sure whether there will be new upgrade requirements for 7.3.2. We're not expecting any at this time. Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira James Hinkey 4 Years Ago Regarding the point 3, it won't any other requirements to upgrade to the GA3 or future GAs. Please sign in to reply. Reply as... Cancel Mike Bigelow James Hinkey 4 Years Ago - Edited To confirm only these steps below in the link are required to upgrade later on? (unless a new upgrade requirement is listed). And these steps "Upgrading Via Docker" will perform all files & DB? https://learn.liferay.com/dxp-7.x/installation-and-upgrades/upgrading-liferay-dxp/upgrade-basics/upgrading-via-docker.html Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira Mike Bigelow 4 Years Ago Hi Mike, If you mean document library files when you says "files", yes, the upgrade takes care of it (although there are no modifications in this matter during the upgrade between 7.3 GAs. If you mean Liferay jar files, then, if you use the latest docker image to upgrade, yes, the updated jars for latest GA will be available. I hope it helps. Cheers! Please sign in to reply. Reply as... Cancel
Alberto Chaparro Terleira James Hinkey 4 Years Ago Regarding the point 3, it won't any other requirements to upgrade to the GA3 or future GAs. Please sign in to reply. Reply as... Cancel
Mike Bigelow James Hinkey 4 Years Ago - Edited To confirm only these steps below in the link are required to upgrade later on? (unless a new upgrade requirement is listed). And these steps "Upgrading Via Docker" will perform all files & DB? https://learn.liferay.com/dxp-7.x/installation-and-upgrades/upgrading-liferay-dxp/upgrade-basics/upgrading-via-docker.html Please sign in to reply. Reply as... Cancel Alberto Chaparro Terleira Mike Bigelow 4 Years Ago Hi Mike, If you mean document library files when you says "files", yes, the upgrade takes care of it (although there are no modifications in this matter during the upgrade between 7.3 GAs. If you mean Liferay jar files, then, if you use the latest docker image to upgrade, yes, the updated jars for latest GA will be available. I hope it helps. Cheers! Please sign in to reply. Reply as... Cancel
Alberto Chaparro Terleira Mike Bigelow 4 Years Ago Hi Mike, If you mean document library files when you says "files", yes, the upgrade takes care of it (although there are no modifications in this matter during the upgrade between 7.3 GAs. If you mean Liferay jar files, then, if you use the latest docker image to upgrade, yes, the updated jars for latest GA will be available. I hope it helps. Cheers! Please sign in to reply. Reply as... Cancel
Christoph Rabel 4 Years Ago - Edited I tried the new version a bit: 1) Master pages I'd like to know a bit about the plans here. Is it (or will it be) possible to specify multiple dropzone areas? That way I could allow different elements per drop zone (e.g. header, content, footer). Another nice feature would be to have permissions for dropzones. Some editors could be allowed to configure the whole page, others only some parts of the page. Maybe even get rid of the need to create a theme altogether. The header, including navigation, login, whatever, could become one or more widgets and only the top level editor can change them. Others are restricted to content. Btw.: My question here is also a bit driven by the dashboard usecase. In the last couple months I had discussions with 4 different, unrelated customers who want a dashboard for end users. All with different usecases and specific needs but the requirement that endusers can configure their dashboard page, add/remove widgets. Maybe the dashboard usecase can/should be addressed in a different way, but I just thought about it. 2) Asset Libraries GREAT feature. Love it. For most customers, we have sites that are just "storage". A very nice feature would be to be able to set default permissions. Liferay permissions are complicated; great, powerful, but complicated. We have resolved that by using extra sites per "group". e.g. a marketeer site with marketing only documents. Only site members see the content, can create content there and so on. The nice thing is: A news created there is automatically only visible to marketeers. So, they can't err with the permissions. So, I would like to be able to define default permissions for all assets in Asset Libraries. 3) Ability to define navigation menus in Global to share them across all sites I tried it and I found it very limited (at least so far). The problem I see: Let's say, I create a footer menu. To add the links to that global menu, I have to copy the links and the names (not to forget possible translations) and add them one by one to that global menu. Uh. Then, whenever a linked page is renamed/url changes/deleted, I have to update the global menu too. Of course, I will never forget to do that ... I probably will ignore that feature. We currently merge the whole navigation of sites into the parent site (e.g. in the Department menu, the editor adds a page "Department X" and we automatically insert the navigation tree from the Department X site there). And in Department X we show the navigation from the parent. Swell would be the option to create navigation menus AND then use them as "pages" in other sites. With that I could create navigation menus where e.g. each tab contains the navigation menu of the subsite. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Hey Christoph, Thanks so much for trying out the new version and providing such detailed feedback. > 1) Master pages We have several features in mind for the next phase of master pages, but we wanted to analyze the initial usage and feedback to decide on priorities. > Is it (or will it be) possible to specify multiple dropzone areas? That way I could allow different elements per drop zone (e.g. header, content, footer). Yes, that's something we even debated to provide during the first phase. But it adds complexity (and requires some changes in how dragging in the page editor works) so we decided to wait and ensure that it's necessary. Could you create a Feature Request for it? > Another nice feature would be to have permissions for dropzones. Some editors could be allowed to configure the whole page, others only some parts of the page. This is something that needs to be thought through. We know from experience how overdoing permissions leads to a lot of flexibility that few people use due to how hard it is to get it right. What would be super-useful is if you could create a feature request describing the need (not the solution) and add real-world specific examples of the different types of users and the desired permissions for each. This type of information helps us find the simplest solution possible to solve the need. > Maybe even get rid of the need to create a theme altogether. The header, including navigation, login, whatever, could become one or more widgets and only the top level editor can change them. Others are restricted to content. We do have plans to leverage master pages, fragments and a new feature coming next called the style editor to reduce a lot the need to create full blown themes (the current ones). Looking forward for your feedback once we roll it out (probably by GA4 or so) > My question here is also a bit driven by the dashboard usecase. In the last couple months I had discussions with 4 different, unrelated customers who want a dashboard for end users. All with different usecases and specific needs but the requirement that endusers can configure their dashboard page, add/remove widgets. > Maybe the dashboard usecase can/should be addressed in a different way, but I just thought about it. Yeah, dashboards might require a different way of building a page. It's something that we are not prioritizing right now, but it would be very interesting to hear more from you about the use cases you are finding. > 2) Asset Libraries > GREAT feature. Love it. For most customers, we have sites that are just "storage". Awesome, thanks for the feedback. I've forwarded it to the product managers and team lead in charge for this. > 3) Ability to define navigation menus in Global to share them across all sites > I tried it and I found it very limited (at least so far). The problem I see: > Let's say, I create a footer menu. To add the links to that global menu, I have to copy the links and the names (not to forget possible translations) and add them one by one to that global menu. Uh. > Then, whenever a linked page is renamed/url changes/deleted, I have to update the global menu too. Of course, I will never forget to do that ... Understood. One idea would be to allow adding a Menu Item of type page to the global navigation menus and let the user select a site first and then the page. We would need to think through which sites to show for selection, but otherwise it wouldn't be too hard to implement. Would this make global menus useful for your use cases? > Swell would be the option to create navigation menus AND then use them as "pages" in other sites. > With that I could create navigation menus where e.g. each tab contains the navigation menu of the subsite. You mean to support composition of menus from other menus, right? This could be done by adding a new type of Menu Item which is a link to another menu. We would need to think through the permissions aspects of which other menus would be selectable (if they are from other sites), but otherwise I think it's doable. Please go ahead and create a feature request for this as well. Thanks Christoph! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited Hi Jorge, I have created two feature requests: https://issues.liferay.com/browse/LPS-111889 https://issues.liferay.com/browse/LPS-111891 I understand the problem with the dropzones and also the reluctance about permissions. After writing the feature requests, I mulled it a bit and I mostly had a "Theme 2.0" in mind. (I wrote a bit about the issues I have with the current themes here: https://liferay.dev/forums/-/message_boards/message/114387658 ) My main idea was, instead of creating a theme, I create the master page, add a header area, with logo, navigation, ...; a content area and a footer area (with sitemap, social links , ...). This master page will be my new "theme". It is quite possible that implementing the above features simply makes my feature requests obsolete. --- The main dashboard usecase: One of our potential customers provides multiple services and his clients have subscribed to a number of them. The services differ per end client. Each client should have a freely configurable dashboard with the widgets they have subscribed too. Which widgets can be used by the client is defined by an account manager. On top of that, those account managers should be able to "preconfigure" these widgets for the clients. The clients should not be able to configure them, only to add/order/remove them. I think, this is the most complicated of the possible usecases we have. But all have in common that end users should be able to add widgets to their pages. They should not be allowed to do a lot of configuration (maybe minor things like changing colors). Furter usecases: - Undo - Reset --- Menus: - Selecting pages from other sites Yes, that would be helpful. It would increase consistency. Deleting a page would not lead to a broken link in that menu. I still think that a general composition feature would be the most useful thing. I have added a feature request (maybe it is a bit to "solution" oriented, but I hope the idea is clear) https://issues.liferay.com/browse/LPS-111895 Note: I am not sure, if it is better to link to a page (in the default navigation) in another site or to a navigation menu. Both have their merits. Btw.: Yes, the permission thing is tricky. So far we could "get away" with implementing only two usescases: a) The admin sets the same permissions on "linking page" and the site. That way, we could avoid checking the site permissions, we just looked at the page. b) The admin specified the parent site and we simply list the viewable subsites in the menu. Here we never look into the sites, we just link to the sites default url. We use that for "dynamic site lists" like working groups where the user can be member. The customers could so far live very well with some restrictions. To have only one main menu for all sites was worth it. Best wishes, Christoph Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Hey Christoph, Thanks for your reply and for creating the feature requests. I've replied in each of them. Regarding the Dashboard, my first impression is that your needs are a bit specific and I can't identify features generic enough that we could add to the roadmap yet. Regarding themes, the ideas that we have for lite themes as a combination of styles+fragments+templates should solve many of the pain points you mention in your post. They will be easier to build, deploy/import and maintain :) Jorge Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited Hi, Themes: I think so too. Once I can define a header and a footer, I am pretty much golden. There are some missing pieces, e.g. fonts, or how to change the technical head of a page, but I can see already that I can get pretty far without ever creating a theme. Dashboard: I have described the most complicated dashboard usecase we had so far. I am not sure, what you can do here, I just wanted to mention it, since the topic came up quite often in the last couple of months. I have not tested it, but I think, the most common usecases could already be implemented using master pages. I can create simple widgets (with no or very simple configuration options) and create a master page allowing only those suitable widgets. This should work pretty well. Permissions could be tricky, I probably need to remove either the owner permissions on the dashboard pages or give them a different owner or something like that. Where I have a difficult time is the usability. While it is well suited for editors, it isn't so nice for untrained users, sometimes even without IT experience. They need to go to edit mode, use the menus on the side, publish, ... I believe, in a "dashboard mode", edit mode has to be handled differently and without publishing. One dashboard I know has a large "+" card at the bottom, clicking it allows me to select a widget type. New widgets are always added to the end. I can always freely drag & drop them around. Something like that would be nice for dashboards. Please sign in to reply. Reply as... Cancel Christoph Rabel Christoph Rabel 4 Years Ago - Edited I just noticed that I can't edit headings on a master page. I have added a row above the dropzone. Then I added a Heading. But I could not change the text. Interestingly, it let me add a link to the heading and specify a color for the font. When I created a page from that master page, the link was gone, the color worked. I tried it with a button and an image too, seems to work there. I could edit the button text and select an image. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago That's not the expected behavior. You should be able to edit the heading and any other editable and fragment just like in a regular page. Also, everything set up should be preserved when creating a page out of the master page. If you can reproduce the behavior consistently, please file a bug in JIRA. Please check if there are any Js errors in the console and include them in the ticket if that's the case. Thanks! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Christoph Rabel 4 Years Ago Hey Christoph, Thanks so much for trying out the new version and providing such detailed feedback. > 1) Master pages We have several features in mind for the next phase of master pages, but we wanted to analyze the initial usage and feedback to decide on priorities. > Is it (or will it be) possible to specify multiple dropzone areas? That way I could allow different elements per drop zone (e.g. header, content, footer). Yes, that's something we even debated to provide during the first phase. But it adds complexity (and requires some changes in how dragging in the page editor works) so we decided to wait and ensure that it's necessary. Could you create a Feature Request for it? > Another nice feature would be to have permissions for dropzones. Some editors could be allowed to configure the whole page, others only some parts of the page. This is something that needs to be thought through. We know from experience how overdoing permissions leads to a lot of flexibility that few people use due to how hard it is to get it right. What would be super-useful is if you could create a feature request describing the need (not the solution) and add real-world specific examples of the different types of users and the desired permissions for each. This type of information helps us find the simplest solution possible to solve the need. > Maybe even get rid of the need to create a theme altogether. The header, including navigation, login, whatever, could become one or more widgets and only the top level editor can change them. Others are restricted to content. We do have plans to leverage master pages, fragments and a new feature coming next called the style editor to reduce a lot the need to create full blown themes (the current ones). Looking forward for your feedback once we roll it out (probably by GA4 or so) > My question here is also a bit driven by the dashboard usecase. In the last couple months I had discussions with 4 different, unrelated customers who want a dashboard for end users. All with different usecases and specific needs but the requirement that endusers can configure their dashboard page, add/remove widgets. > Maybe the dashboard usecase can/should be addressed in a different way, but I just thought about it. Yeah, dashboards might require a different way of building a page. It's something that we are not prioritizing right now, but it would be very interesting to hear more from you about the use cases you are finding. > 2) Asset Libraries > GREAT feature. Love it. For most customers, we have sites that are just "storage". Awesome, thanks for the feedback. I've forwarded it to the product managers and team lead in charge for this. > 3) Ability to define navigation menus in Global to share them across all sites > I tried it and I found it very limited (at least so far). The problem I see: > Let's say, I create a footer menu. To add the links to that global menu, I have to copy the links and the names (not to forget possible translations) and add them one by one to that global menu. Uh. > Then, whenever a linked page is renamed/url changes/deleted, I have to update the global menu too. Of course, I will never forget to do that ... Understood. One idea would be to allow adding a Menu Item of type page to the global navigation menus and let the user select a site first and then the page. We would need to think through which sites to show for selection, but otherwise it wouldn't be too hard to implement. Would this make global menus useful for your use cases? > Swell would be the option to create navigation menus AND then use them as "pages" in other sites. > With that I could create navigation menus where e.g. each tab contains the navigation menu of the subsite. You mean to support composition of menus from other menus, right? This could be done by adding a new type of Menu Item which is a link to another menu. We would need to think through the permissions aspects of which other menus would be selectable (if they are from other sites), but otherwise I think it's doable. Please go ahead and create a feature request for this as well. Thanks Christoph! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited Hi Jorge, I have created two feature requests: https://issues.liferay.com/browse/LPS-111889 https://issues.liferay.com/browse/LPS-111891 I understand the problem with the dropzones and also the reluctance about permissions. After writing the feature requests, I mulled it a bit and I mostly had a "Theme 2.0" in mind. (I wrote a bit about the issues I have with the current themes here: https://liferay.dev/forums/-/message_boards/message/114387658 ) My main idea was, instead of creating a theme, I create the master page, add a header area, with logo, navigation, ...; a content area and a footer area (with sitemap, social links , ...). This master page will be my new "theme". It is quite possible that implementing the above features simply makes my feature requests obsolete. --- The main dashboard usecase: One of our potential customers provides multiple services and his clients have subscribed to a number of them. The services differ per end client. Each client should have a freely configurable dashboard with the widgets they have subscribed too. Which widgets can be used by the client is defined by an account manager. On top of that, those account managers should be able to "preconfigure" these widgets for the clients. The clients should not be able to configure them, only to add/order/remove them. I think, this is the most complicated of the possible usecases we have. But all have in common that end users should be able to add widgets to their pages. They should not be allowed to do a lot of configuration (maybe minor things like changing colors). Furter usecases: - Undo - Reset --- Menus: - Selecting pages from other sites Yes, that would be helpful. It would increase consistency. Deleting a page would not lead to a broken link in that menu. I still think that a general composition feature would be the most useful thing. I have added a feature request (maybe it is a bit to "solution" oriented, but I hope the idea is clear) https://issues.liferay.com/browse/LPS-111895 Note: I am not sure, if it is better to link to a page (in the default navigation) in another site or to a navigation menu. Both have their merits. Btw.: Yes, the permission thing is tricky. So far we could "get away" with implementing only two usescases: a) The admin sets the same permissions on "linking page" and the site. That way, we could avoid checking the site permissions, we just looked at the page. b) The admin specified the parent site and we simply list the viewable subsites in the menu. Here we never look into the sites, we just link to the sites default url. We use that for "dynamic site lists" like working groups where the user can be member. The customers could so far live very well with some restrictions. To have only one main menu for all sites was worth it. Best wishes, Christoph Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Hey Christoph, Thanks for your reply and for creating the feature requests. I've replied in each of them. Regarding the Dashboard, my first impression is that your needs are a bit specific and I can't identify features generic enough that we could add to the roadmap yet. Regarding themes, the ideas that we have for lite themes as a combination of styles+fragments+templates should solve many of the pain points you mention in your post. They will be easier to build, deploy/import and maintain :) Jorge Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited Hi, Themes: I think so too. Once I can define a header and a footer, I am pretty much golden. There are some missing pieces, e.g. fonts, or how to change the technical head of a page, but I can see already that I can get pretty far without ever creating a theme. Dashboard: I have described the most complicated dashboard usecase we had so far. I am not sure, what you can do here, I just wanted to mention it, since the topic came up quite often in the last couple of months. I have not tested it, but I think, the most common usecases could already be implemented using master pages. I can create simple widgets (with no or very simple configuration options) and create a master page allowing only those suitable widgets. This should work pretty well. Permissions could be tricky, I probably need to remove either the owner permissions on the dashboard pages or give them a different owner or something like that. Where I have a difficult time is the usability. While it is well suited for editors, it isn't so nice for untrained users, sometimes even without IT experience. They need to go to edit mode, use the menus on the side, publish, ... I believe, in a "dashboard mode", edit mode has to be handled differently and without publishing. One dashboard I know has a large "+" card at the bottom, clicking it allows me to select a widget type. New widgets are always added to the end. I can always freely drag & drop them around. Something like that would be nice for dashboards. Please sign in to reply. Reply as... Cancel Christoph Rabel Christoph Rabel 4 Years Ago - Edited I just noticed that I can't edit headings on a master page. I have added a row above the dropzone. Then I added a Heading. But I could not change the text. Interestingly, it let me add a link to the heading and specify a color for the font. When I created a page from that master page, the link was gone, the color worked. I tried it with a button and an image too, seems to work there. I could edit the button text and select an image. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago That's not the expected behavior. You should be able to edit the heading and any other editable and fragment just like in a regular page. Also, everything set up should be preserved when creating a page out of the master page. If you can reproduce the behavior consistently, please file a bug in JIRA. Please check if there are any Js errors in the console and include them in the ticket if that's the case. Thanks! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Christoph Rabel Jorge Ferrer 4 Years Ago - Edited Hi Jorge, I have created two feature requests: https://issues.liferay.com/browse/LPS-111889 https://issues.liferay.com/browse/LPS-111891 I understand the problem with the dropzones and also the reluctance about permissions. After writing the feature requests, I mulled it a bit and I mostly had a "Theme 2.0" in mind. (I wrote a bit about the issues I have with the current themes here: https://liferay.dev/forums/-/message_boards/message/114387658 ) My main idea was, instead of creating a theme, I create the master page, add a header area, with logo, navigation, ...; a content area and a footer area (with sitemap, social links , ...). This master page will be my new "theme". It is quite possible that implementing the above features simply makes my feature requests obsolete. --- The main dashboard usecase: One of our potential customers provides multiple services and his clients have subscribed to a number of them. The services differ per end client. Each client should have a freely configurable dashboard with the widgets they have subscribed too. Which widgets can be used by the client is defined by an account manager. On top of that, those account managers should be able to "preconfigure" these widgets for the clients. The clients should not be able to configure them, only to add/order/remove them. I think, this is the most complicated of the possible usecases we have. But all have in common that end users should be able to add widgets to their pages. They should not be allowed to do a lot of configuration (maybe minor things like changing colors). Furter usecases: - Undo - Reset --- Menus: - Selecting pages from other sites Yes, that would be helpful. It would increase consistency. Deleting a page would not lead to a broken link in that menu. I still think that a general composition feature would be the most useful thing. I have added a feature request (maybe it is a bit to "solution" oriented, but I hope the idea is clear) https://issues.liferay.com/browse/LPS-111895 Note: I am not sure, if it is better to link to a page (in the default navigation) in another site or to a navigation menu. Both have their merits. Btw.: Yes, the permission thing is tricky. So far we could "get away" with implementing only two usescases: a) The admin sets the same permissions on "linking page" and the site. That way, we could avoid checking the site permissions, we just looked at the page. b) The admin specified the parent site and we simply list the viewable subsites in the menu. Here we never look into the sites, we just link to the sites default url. We use that for "dynamic site lists" like working groups where the user can be member. The customers could so far live very well with some restrictions. To have only one main menu for all sites was worth it. Best wishes, Christoph Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Hey Christoph, Thanks for your reply and for creating the feature requests. I've replied in each of them. Regarding the Dashboard, my first impression is that your needs are a bit specific and I can't identify features generic enough that we could add to the roadmap yet. Regarding themes, the ideas that we have for lite themes as a combination of styles+fragments+templates should solve many of the pain points you mention in your post. They will be easier to build, deploy/import and maintain :) Jorge Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited Hi, Themes: I think so too. Once I can define a header and a footer, I am pretty much golden. There are some missing pieces, e.g. fonts, or how to change the technical head of a page, but I can see already that I can get pretty far without ever creating a theme. Dashboard: I have described the most complicated dashboard usecase we had so far. I am not sure, what you can do here, I just wanted to mention it, since the topic came up quite often in the last couple of months. I have not tested it, but I think, the most common usecases could already be implemented using master pages. I can create simple widgets (with no or very simple configuration options) and create a master page allowing only those suitable widgets. This should work pretty well. Permissions could be tricky, I probably need to remove either the owner permissions on the dashboard pages or give them a different owner or something like that. Where I have a difficult time is the usability. While it is well suited for editors, it isn't so nice for untrained users, sometimes even without IT experience. They need to go to edit mode, use the menus on the side, publish, ... I believe, in a "dashboard mode", edit mode has to be handled differently and without publishing. One dashboard I know has a large "+" card at the bottom, clicking it allows me to select a widget type. New widgets are always added to the end. I can always freely drag & drop them around. Something like that would be nice for dashboards. Please sign in to reply. Reply as... Cancel Christoph Rabel Christoph Rabel 4 Years Ago - Edited I just noticed that I can't edit headings on a master page. I have added a row above the dropzone. Then I added a Heading. But I could not change the text. Interestingly, it let me add a link to the heading and specify a color for the font. When I created a page from that master page, the link was gone, the color worked. I tried it with a button and an image too, seems to work there. I could edit the button text and select an image. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago That's not the expected behavior. You should be able to edit the heading and any other editable and fragment just like in a regular page. Also, everything set up should be preserved when creating a page out of the master page. If you can reproduce the behavior consistently, please file a bug in JIRA. Please check if there are any Js errors in the console and include them in the ticket if that's the case. Thanks! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Christoph Rabel 4 Years Ago Hey Christoph, Thanks for your reply and for creating the feature requests. I've replied in each of them. Regarding the Dashboard, my first impression is that your needs are a bit specific and I can't identify features generic enough that we could add to the roadmap yet. Regarding themes, the ideas that we have for lite themes as a combination of styles+fragments+templates should solve many of the pain points you mention in your post. They will be easier to build, deploy/import and maintain :) Jorge Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited Hi, Themes: I think so too. Once I can define a header and a footer, I am pretty much golden. There are some missing pieces, e.g. fonts, or how to change the technical head of a page, but I can see already that I can get pretty far without ever creating a theme. Dashboard: I have described the most complicated dashboard usecase we had so far. I am not sure, what you can do here, I just wanted to mention it, since the topic came up quite often in the last couple of months. I have not tested it, but I think, the most common usecases could already be implemented using master pages. I can create simple widgets (with no or very simple configuration options) and create a master page allowing only those suitable widgets. This should work pretty well. Permissions could be tricky, I probably need to remove either the owner permissions on the dashboard pages or give them a different owner or something like that. Where I have a difficult time is the usability. While it is well suited for editors, it isn't so nice for untrained users, sometimes even without IT experience. They need to go to edit mode, use the menus on the side, publish, ... I believe, in a "dashboard mode", edit mode has to be handled differently and without publishing. One dashboard I know has a large "+" card at the bottom, clicking it allows me to select a widget type. New widgets are always added to the end. I can always freely drag & drop them around. Something like that would be nice for dashboards. Please sign in to reply. Reply as... Cancel Christoph Rabel Christoph Rabel 4 Years Ago - Edited I just noticed that I can't edit headings on a master page. I have added a row above the dropzone. Then I added a Heading. But I could not change the text. Interestingly, it let me add a link to the heading and specify a color for the font. When I created a page from that master page, the link was gone, the color worked. I tried it with a button and an image too, seems to work there. I could edit the button text and select an image. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago That's not the expected behavior. You should be able to edit the heading and any other editable and fragment just like in a regular page. Also, everything set up should be preserved when creating a page out of the master page. If you can reproduce the behavior consistently, please file a bug in JIRA. Please check if there are any Js errors in the console and include them in the ticket if that's the case. Thanks! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Christoph Rabel Jorge Ferrer 4 Years Ago - Edited Hi, Themes: I think so too. Once I can define a header and a footer, I am pretty much golden. There are some missing pieces, e.g. fonts, or how to change the technical head of a page, but I can see already that I can get pretty far without ever creating a theme. Dashboard: I have described the most complicated dashboard usecase we had so far. I am not sure, what you can do here, I just wanted to mention it, since the topic came up quite often in the last couple of months. I have not tested it, but I think, the most common usecases could already be implemented using master pages. I can create simple widgets (with no or very simple configuration options) and create a master page allowing only those suitable widgets. This should work pretty well. Permissions could be tricky, I probably need to remove either the owner permissions on the dashboard pages or give them a different owner or something like that. Where I have a difficult time is the usability. While it is well suited for editors, it isn't so nice for untrained users, sometimes even without IT experience. They need to go to edit mode, use the menus on the side, publish, ... I believe, in a "dashboard mode", edit mode has to be handled differently and without publishing. One dashboard I know has a large "+" card at the bottom, clicking it allows me to select a widget type. New widgets are always added to the end. I can always freely drag & drop them around. Something like that would be nice for dashboards. Please sign in to reply. Reply as... Cancel Christoph Rabel Christoph Rabel 4 Years Ago - Edited I just noticed that I can't edit headings on a master page. I have added a row above the dropzone. Then I added a Heading. But I could not change the text. Interestingly, it let me add a link to the heading and specify a color for the font. When I created a page from that master page, the link was gone, the color worked. I tried it with a button and an image too, seems to work there. I could edit the button text and select an image. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago That's not the expected behavior. You should be able to edit the heading and any other editable and fragment just like in a regular page. Also, everything set up should be preserved when creating a page out of the master page. If you can reproduce the behavior consistently, please file a bug in JIRA. Please check if there are any Js errors in the console and include them in the ticket if that's the case. Thanks! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Christoph Rabel Christoph Rabel 4 Years Ago - Edited I just noticed that I can't edit headings on a master page. I have added a row above the dropzone. Then I added a Heading. But I could not change the text. Interestingly, it let me add a link to the heading and specify a color for the font. When I created a page from that master page, the link was gone, the color worked. I tried it with a button and an image too, seems to work there. I could edit the button text and select an image. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago That's not the expected behavior. You should be able to edit the heading and any other editable and fragment just like in a regular page. Also, everything set up should be preserved when creating a page out of the master page. If you can reproduce the behavior consistently, please file a bug in JIRA. Please check if there are any Js errors in the console and include them in the ticket if that's the case. Thanks! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Christoph Rabel 4 Years Ago That's not the expected behavior. You should be able to edit the heading and any other editable and fragment just like in a regular page. Also, everything set up should be preserved when creating a page out of the master page. If you can reproduce the behavior consistently, please file a bug in JIRA. Please check if there are any Js errors in the console and include them in the ticket if that's the case. Thanks! Please sign in to reply. Reply as... Cancel Christoph Rabel Jorge Ferrer 4 Years Ago - Edited I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Christoph Rabel Jorge Ferrer 4 Years Ago - Edited I tried it again, I can consistently reproduce the issue. BUT I have also downloaded master now and I can't reproduce anything of it there. I guess, whatever the problem is, it is already fixed. Please sign in to reply. Reply as... Cancel Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Jorge Ferrer Christoph Rabel 4 Years Ago Thanks for checking in both versions. Please go ahead and report it as a bug if you can reproduce it again in any future release. Please sign in to reply. Reply as... Cancel
Lee Jordan 3 Years Ago - Edited It's getting better, the WEM is still not feature complete. We've got to have 100% features ported from widget pages for widgets in content pages. The trouble is whatever we upgrade to (and clearly Liferay as a platform is in a state of flux and not stable ), the trouble really is we will be stuck with whatever version we land on for 4 years. It's not good to have both widget pages and content pages, we need a full move to content pages eventually, or renaming the things to be "Classic Pages" and "Modern Pages". The terminology is still too obscure for most users and most users will want to use web content on content pages because of the wording alone. Look and feel menu currently is the biggest thing missing from widgets (portlets) on content pages, and there are no portlet toppers when not in edit mode. You can't "edit web content" in edit mode and the plus menu that allows fast access to add a new template to a web content has yet to find its way to Content Pages. Please provide a timeline and a target version of Liferay that will have this massive change to Web Experience Management feature complete. Overall in 7.3 it's 80% there, the next 20% will be hard but it must be done. We must make this change over to content pages with backwards compatibility, we can't continue to split use cases between two types of pages. The changes were announced a long time ago, this has been a long journey and a worthwhile one, but please let's not stop at 80% done, let's push through and get to 100%. Please sign in to reply. Reply as... Cancel