nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Multiple workareas?

mmb

Hi

in the SitePublisher 7.2 dev manual it repeatedly states that "SitePublisher only supports 1 workarea per branch".

Does this mean within the LiveSite branches under the /iw-admin store or in the managed sites branches under the /default/main store?

Does this mean that concurrent development in SitePublisher/LiveSite is not possible using traditional multiple workareas & associated permissions?

If this is the case, could someone please suggest how an organisation with a high volume of change website, changed constantly by multiple teams, can efficiently work under this model?

Thanks
- mark

Find more posts tagged with

Comments

vpatel

Hi

in the SitePublisher 7.2 dev manual it repeatedly states that "SitePublisher only supports 1 workarea per branch".

Does this mean within the LiveSite branches under the /iw-admin store or in the managed sites branches under the /default/main store?

Does this mean that concurrent development in SitePublisher/LiveSite is not possible using traditional multiple workareas & associated permissions?

If this is the case, could someone please suggest how an organisation with a high volume of change website, changed constantly by multiple teams, can efficiently work under this model?

Thanks
- mark

This is primarily meant for /default/main store where you actually create sites/content.

How would your org work with high volume, that would depend on a variety of factors/requirements. Probably hard to answer that in a forum.

mmb

Ok thanks for the reply.

The question was more for a confirmation that only 1 workarea per branch is allowed in the /default/main branches.

This would mean for a given site, if there were different teams that required the ability to update the same content, they would all have to work in the same workarea.

This seems a regression in terms of traditional functionality where 2 teams could have their own workareas in the same branch and avoid overwriting each others work.

Thanks
mark

REPORT_ScriptedDataSets.rptdesign

srosewall

How would your org work with high volume, that would depend on a variety of factors/requirements. Probably hard to answer that in a forum.

This is an important point - let's see if we can tease out some details from you to get our creative juices flowing.

When you say you would have multiple teams updating the same content, do you mean the underlying structured content (DCRs)? And do you mean that different people would be working on the same DCRs?

There are a couple of considerations here; if you have different content catagories/types being edited by different teams, then you can ring fence those catagories/types with security controls to make sure the right groups have access to the right content - use in-workarea security control to seggregate content from different users rather than whole-workarea restrictions (use submit.cfg to enforce automatically).

Editing the same DCRs? Then you'll potentially have conflicts regardless of how many workareas you've got, and it could be argued that having only one version available will reduce the opportunity for conflicts. Perhaps there's an argument that says that you should analyse your data and split it into convenient chunks that allows for the most flexibility.

And if you've got your data model right, creating/editing content could (should?) be a separate activity to editing the Site / Pages etc. The ideal design approach for SitePublisher (IMHO) is to limit the number of pages in use (not a page per content item), to externalise any stylesheets, CSS etc., and to use fixed area layouts and templates to organise the positioning of components on a page.

If you get the mix right, then you may (should?) find that your content contributors are only interacting with FormsPublisher, and SitePublisher is only used by a limited audience to add extra functionality and change the look-n-feel (with even some of those activities externalised).

Thinking laterally (dangerous I know, but let's push the envelope shall we!) - I've yet to have the use case to try this out, but in theory you could have your templatedata and other assets in other branches with multiple workareas if you really needed to, especially if you are using a data model where the content is brought into a page as a result of a query to a repository (LSCS or database). Note: direct linking to DCRs probably wouldn't work with this approach though without an amount of customisation.

My understanding of the background is that the main issue with having multiple workareas is that it results in multiple SiteMaps for what is in effect the same Site. This is not a good thing, and if nothing else, confuses the SiteMap tab something horrible.

And managing different versions of pages is probably problematic what with internal IDs, and references to components and templates.

AFIK though, everything else in the workarea's up for grabs.

Note: you can use the Test area in the iwadmin store to do development work on components and templates related to a site prior to releasing them to the wider World - you create a copy of a site and use the area as a sandbox, that might help mitigate some of your crunch.

Adam Stoller

...
When you say you would have multiple teams updating the same content, do you mean the underlying structured content (DCRs)? And do you mean that different people would be working on the same DCRs?
...
Editing the same DCRs? Then you'll potentially have conflicts regardless of how many workareas you've got, and it could be argued that having only one version available will reduce the opportunity for conflicts.

I cannot comment on the SP/LS aspects of this thread, as I really haven't worked with SP/LS yet (or at least not to the extent that I have anything very useful to contribute) - but with respect to editing DCRs in multiple workareas .... TeamSite has never allowed a single DCR to be edited in multiple workareas on the same branch - nor by multiple users in the same workarea at the same time (lock-holder only) - so this is (depending on how you look at it) a non-issue or an old-issue.

cecilb63

We use multiple workareas under a branch to allow parallel development. For example, we may have content that changes daily in the production system. For that we use a workarea named HEAD. All authors use this workarea as they see fit for day to day changes.

At times we have a new release and changes need to be made in parallel to the changes in the HEAD workarea. For this we create another workarea, named usually after the release month. Using this other workarea, we can change DCRs and content during the development cycle without interfering with the day to day activities. When the release goes lives, it is fairly easy to merge the changes into staging, at which point the HEAD brand does a 'get latest' and everything else is in sync.

Note from each of these workareas, we can deploy our content to any environment we want. We have dev,test,ete,uat,perf,prod environment which we can deploy to from any workarea anytime. (as we see fit)

With LiveSite, which we are in the process of installing, we plan to use the same arrangement.

Am I hearing that LiveSite doesn't support multi-workareas per branch?

mmb

Firstly, thanks for the replies. They are a great help in researching any potential limitations with this model.

I understand the situation with regards to the historical failings of merging DCRs etc between workareas we have been working with them for years.

Its just good to know one way or the other what the situation is.

So in reply to cecilb63: It sounds as though you are in the same situation and will need to review your release processes for any potential migration to LiveSite.

Thanks
mark