Please submit your ideas on how to improve Cascade Server.
-
2
Publish Job should trigger next Job in Queue
When a publish job completes, it should trigger the server to check the queue again.
Polling the queue every 30 seconds causes a delay of many minutes when the queue is stacked with many jobs.Example: if there are 12 jobs in the queue that take 8 seconds each, polling would require just over 6 minutes to complete them all. Having one job poll for the next job would reduce this to a maximum of 2 min 5 sec (assuming 29 seconds for the first poll, then 8 × 12 seconds of actual publish time) with typical times even less. -
0
Destination option: publish drafts
Our last CMS had this concept of approved versions, so you could make several changes to an asset, creating new versions, and eventually someone with the approver ability would come along and approve a specific version of the asset. Then what is analgous to destinations was configurable to only publish the latest approved or publish the latest (regardless of approval).
This was a really nice feature that we miss. Management types typically like to look at and approve content in their browser, not in the CMS, so being able to configure a destination to publish drafts to a staging location would be valuable. -
-1
Preview Site? Not Just Page?
Is there no way to just browse the site before publishing? There’s no way to see all the publishable assets at once?
You have to go to each and every page and then click preview, then you have to go to edit > system to find out if the page is publishable or not.
It is imperative to be able to preview the site before publishing!
-
0
Drag & Drop Templates/Formats? Not Just XSL/Velocity?
It is certainly powerful to use XSL/Velocity to work with indices, metadata, and data definitions.
Having drag & drop templating/formatting would be even better. Basically a UI front end for the templates/formats.
One
problem with just XSL/Velocity is that it hides markup and styles. Part
of the XHTML template is located outside the template. It doesn’t
validate XHTML until runtime! And, you can’t preview the styles until
runtime!What is the point of WYSIWYG when your template doesn’t display anything at all, because nothing is generated until runtime?
-
2
Simplify process of adding assets to publish sets
One idea that I have for improving the process of creating and editing publish sets would be to provide the ability to add more than one asset (regardless of asset type) at a time during a creation or edit operation. I find it annoying having to submit changes and then starting another edit operation in order to add another asset to a publish set.
-
0
More clarifying information for error messages written in log files
My request is really more like an enhancement of current functionality. It would be beneficial to system administrators to have more descriptive information about error messages created by the system. For instance, error messages similar to this one would provide the site, page’s name, data definition name, and/or content type name that caused the error.
ERROR [StructuredDataRenderWorker] Could not render wysiwyg data as a valid xml documnt. Attempting to clean wysiwyg xml and build again: The entity “nbsp” was referenced, but not declared.
Another example of an error message needing more information is the one below. I would suggest adding the name of the transport’s parent site and the transport’s name.
ERROR [TransmitCallbackImpl] Shuttle reported error: Error occurred during SFTP transport: Permission denied -
1
Ability to limit file extensions allowed in the system.
One idea I feel would be beneficial is the ability for site-level and system-level administrators to define the file extensions that can be uploaded. The extensions could be entered into a text input field as a comma separated list. The field can be left empty to signify allowing any type of file extension to be uploaded.
-
2
Unpublishing with Publish Sets
Idea
- Open
Publish Sets in Cascade are great and make it really easy to publish a lot of related content at once. It would be really cool if we could do the same thing with unpublish jobs. For example, if an organization has an annual event that passes, that organization may want to easily unpublish all content related to the event’s schedule, sign-up, etc. Allowing users to specify a publish “mode” (either publish or unpublish) would add extra flexibility to this already useful tool.
-
5
Site Migration and Administration Area Containers
I don’t know if this is a duplicate item, so please let me know. We are in the process of migrating our websites into Sites from the Global area, and have been doing some testing. Our plan has been to make the majority of Sites domain based, with all websites in one domain going to one Site. That is how our folder structure in the Global area was organized. One domain, however, can contain many directories within that domain, many of which had their own configuration sets, content types, data definitions, etc., all separated out with containers in the Administration area. When we actually performed a test migration, though, we discovered that all these items in there respective areas were removed from their containers, the entire structure flattened, and all duplicative names renamed (as in Genera 1, General 2, etc.). We would now have to figure out how to differentiate between nearly fifty items in each area that were formally identified by their now missing containers. Thankfully this was a test.
Why aren’t those containers preserved with the migration? Seems to me that if a configuration set and such are in containers they’re there for very good reasons. If an item is in a container, that container should be recreated in the new Site and their respective items placed there-in, even if not every item within that container is being migrated (which was not the case for us, but I could see it happening). -
-1
Create a Cassandra interface for Cascade
As you know, scalability is a huge issue for content management applications. Providing interfaces to lightweight, scalable DB solutions (like Cassandra and other noSQL solutions) would allow a broader, more automated deployment of Cascade in cases where scale is a limiting factor.
-
1
EditArea Code snippets
would be great to have code snippet support in the new code editor. My first snippet would be [system-asset] [/system-asset] :)
-
6
per-site configuration
There are several global preferences that we’d like to change on a per-site basis. For example:
- maximum assets in an index block
- maximum size of uploaded files
- number of versions to save -
2
Manual Configuration Set Targeting
When setting up a configuration set a user has to select each configuration by hand by browsing and selecting each configuration by browsing to each block. It would be VERY helpful to have an area where one could manually type in the selection by hand. I set up websites that are similar in nature and need to change the folder structure for all of the configuration sets with one folder difference, yet doing all this by hand every time I set up a website is slow and painful.
Better yet, it would be great if one could change the directory and each configuration would update.
For example:
current configuration points to:
Site1/CMS/ContentBlocks/blk1/
Site1/CMS/ContentBlocks/blk2/
Site1/CMS/ContentBlocks/blk3/change all to:
Site2/CMS/ContentBlocks/blk1/
Site2/CMS/ContentBlocks/blk2/
Site2/CMS/ContentBlocks/blk3/ -
3
Alternate display of user ids
The Global/Administration/Users page would benefit from showing Full Names along with the uid (or User Name). It could be as another column, or as a title attribute on the link to the user.
-
2
Show number of active publish jobs in page title.
I often have the publisher open in a second tab when I’m doing major changes. It would be helpful to have the number of active jobs shown in the title so I can quickly scan to see if my job’s published or not.
Something like:
(3) [ Publisher : Active Jobs ] Cascade….. -
1
Editting Pages with DD as XML option
This is option would definitely not be in the hands of the average user and would need to be set by role.
One thing I’ve noticed with very large pages utilizing Data Definitions is that it gets very long in the normal Edit display, just loading, and then trying to figure out where a code problem is causing a page to improperly display that may not appear obvious unless you go into the HTML code of each WYSIWYG you have in that particular page.It would be nice to do the backwards functionality of the newly implemented Data Definition Builder and have a button on the DD pages that allows a coder/developer to switch to straight XML code of that page. -
2
Expose data-definition fields and groups to indexing
We often need to use data from data definitions in index blocks, BUT we are indexing A LOT of data. If we index page XML inline, it slows down our entire system (as index blocks do not seem to be cached).
To avoid this, perhaps we could expose certain fields (via the data definition) to indexing, as we lose grouping, format types, permissions control and other important options if we have to move fields into the metadata. -
5
Allow user configuration to turn off advanced text editor and TinyMCE editor
I’m already receiving complaints about the system not saving the preference of the “Advanced Editor” checkbox. It’s checked every time, and users are expecting the state of the checkbox to save with the document.
While I personally love the new text editor, we have developers that would rather have a user preference allowing this to be turned off. This is very much the same as the desire for people to be able to turn off the wysiwyg (TinyMCE) editor. -
3
More Connectors (Facebook, MySpace, Etc)
The connector idea is great. I think you all have touched on something that is very powerful. It would save a lot of time if I could syndicate content from my web site out to all of my social media sites. So like twitter, allow the same thing for FaceBook, Myspace, etc.
-
5
Metadata inheritance
Change metadata so that it is assembled for the asset from multiple sets of metadata definitions. Allow metadata to be attached at the following levels:
- Asset — This is where most of the existing wired fields would be attached
- Site — Site wide metadata settings
- Template — Examples might be metadata options for control of layout
- Format — Every time this format is used attach these metadata options to the page
- Content Type — or perhaps metadata to go along with each Data Definition as well
- Folder -Would allow for folder specific settings
- Page - to maintain existing compatibility
- Asset — This is where most of the existing wired fields would be attached
* Note - To input code samples, click the pencil icon (this will remove the WYSIWYG) then be sure to start and end code sections with @@@ (three '@' signs). For more information on textile markup, click here.
