Along the lines of Dave Benua’s Smart Preview, I’d like to see Smart Publish capabilities, minimizing the per-site setup for publishing. I know there are technical reasons why publishing isn’t simple, but that doesn’t mean it can’t be simpler.
Case in point: to publish the binary portion of each site, I have to create a separate content list (for each site) with a JEXL statement that specifies that images are binary. But everybody knows that images are binary. That statement has to include a condition to only publish “where jcr:path like ‘//Sites/MySites’”. But I’ve already specified the site ID, in several places it seems.
How much easier if I could click on the Publish arrow to indicate which site I want to publish, and the rest of the information would automatically be filled in. Every site could use the same content lists, only with the site ID inserted.
Part of the frustration in setting up publishing is that settings are located in so many places. For example, I’d like $rxs_navbase and $rxs_urlroot to be included in the site registration, not in a separate Variables listing.
Another frustration is that settings can’t easily be applied for all sites. Why does there need to be Location Schemes for both EI Home page link location and CI Home page link location, if they’re both “index.html”? There could be a variable that says “this is a home page,” to be treated like all other home pages, even if the templates are different for each site. The question should always be asked, “Can I make this feature work without requiring a specific site or template to specified?”
Many settings should be customizable only if desired but left as defaults if not changes are not desired. Creating content lists shouldn’t require JEXL coding. They should be displayed and edited as form fields. Users shouldn’t even see that JEXL code unless they click on an Advanced Settings button. In fact, in general I’d like Percussion developers to see how much configuration they could relegate to “advanced settings” and see how well they could create defaults that work without advanced settings.
Actually, I just noticed that location schemes do work this way, sort of. For example, if you only have one location scheme for the Home content type (in other words, after you delete the location schemes for EI_Home and CI_Home…), that scheme will be applied to all your home pages, no matter which templates they use. That’s encouraging.
We’ve got a bunch of stuff coming to simplify publishing in our “mako” release (probably 6.6, scheduled for the end of the year). I’ll try to see how much of it addresses some of the issues here, but I know the configuration and setup was a big area of focus.
Also, the trend we’re being asked for, seems to be more and more “publish on demand” meaning the actual end user (or WCM Admin/Power User) simply selects items and uses a menu to “Publish this Now” which not only transitions the item(s) to Public, but also triggers a publishing edition to run, passing in the IDs and so forth required.
One of the things we’ll be looking to do is preview some of those capabilities, perhaps right here in the forum.
I would certainly like to see enhancements made to publishing. As a partner this is the single most talked about issue I encounter when visiting clients. I think the reason is that it Rhythmyx can publish out alot of items when it seems that only a few have been updated. I know in earlier versions the TouchParentItem exit touched all items ALL parents and this could lead to excessive content lists but surely there must be way of acurately calculating the parent items even those that appear as a result of a JCR query.
Could Rhythmyx somehow execute all JCR slot querys and keep the results a cache? Then a action menu item for the user to update the cache in the same way the nav_reset works?
I made the mistake once of added an autoslot to the global template which meant when I ran an incremental edition it was pretty much a full.
Would it be possible to list a few of the publishing items that have been added to Rhythmyx 6.6?
I believe there is room to consider how increasingly interactive sites fit with a scheduled publishing model. I am not suggesting completely dynamically-generated sites (we’ve tried that and it has issues all of its own), and there are options such as database publishing, but UGC, for example, may need to appear quite quickly to create a reasonable response.
The problem there is if the item touches too many others and you end up with an ad hoc run for half the site, which is competing with other scheduled ones. Our publishing schedule is getting fairly full these days.
Being able to “public now” would be a great function (obviously only if workflow allows). Our users are frustrated with the delay.
“Publish Now” has been implemented as part of 6.5. It takes the selection of content items from the CX main view (individual or folders) and runs an edition which uses the sys_SelectedItemsGenerator generator.
Like any other action menu you specify the permissions based on role, community, workflow etc. If it’s a straight install of 6.5.2 then you should already have a menu item in the workbench name EI_Publish_Now. You can check by going here
Workbench > UI Elements Design > Content Explorer > Menu Entries > User > EI_Publish_Now
Just copy this item and in the command tab update the sys_editionid to match your edition that uses a sys_SelectedItemsGenerator content list.
Is this dependant on state and workflow permissions?
Yes kind of. You can restrict by Assignment Types eg Admin, Assignee, None and Reader but this is only the visibilty of the action menu item. You can select multiple content items and even folders. I would recommend only retricting by role.
Still depends really on how many items of other types the present one touches.
We are aware of the publish now functions but we are still ending up with UGC whose appearance is governed by publishing schedules, and not sure whether this answer is flexible enough long term.
Multi-threaded publishing is more important to us than “simpler” publishing. Is it true that multi-threaded publishing is a part of 6.5.3 or 6.6? And if so, which one?
A note about Publish Now… We’ve reworked Publish Now to call an Incremental Edition instead of something like the example Publish Now Edition. We’ve also written it to look up a site id so we don’t have to have 350 publish now action menus.
The only complaints I have about publishing center around the management GUI for Content Lists and Editions. Scenario, I have three content lists all associated with the same site that I need to edit. I get to page 5 where they are all next to each other. I edit the first, save the change, then get bounced back to page 1. Wash, rinse, repeat; and… one more time for good measure. Management of editions behaves the same way.
In the grand scheme of publishing being complicated, that ranks pretty near the bottom.
I edit the first, save the change, then get bounced back to page 1. Wash, rinse, repeat; and… one more time for good measure. Management of editions behaves the same way.
You can apply a filter to the lists of content lists and it’s still applied when you save items.
Editions are handled slightly different as this uses XML applications. Open up the XML Server > Applcations > System in the workbench and find
sys_pubEditions/editionlist.html
In the results pager you can change the number of items that appear on a single page and what it’s order by.
Make changes on a dev instance first to get the required results.
Multi-threaded publishing is coming in 6.6, along with a bunch of other changes including queue management, better logs, config, error handling, and a generally simpler model of operation - much of it focused on the “publish on demand” model (that is, continuous incremental operations often triggered by CMS users directly).
I’ll try to get the details of this into a more consumable state and start some kind of discussion on it here.