Don't Allow Publish Dupes

Favorite-off Notification-off
20 Thumb-up Thumb-down
Idea by irifkin about 1 year ago Favorite-off - Open

Although I continue to tell my Web editors not to keep clicking publish and to view the queue, some of them repeatedly publish the same assets because they don’t see the change on their website. I suggest showing the user an error message that says something like: This asset was just published by you and is still in the publish queue.

I’m not sure if it should allow them to publish it again or make them wait. Or maybe they’ll need to cancel the previous publish job.

All I know is that I hate seeing a dozen publish jobs for the same folder, slowing down publishing for everyone.

20 comments

  • 0 points Thumb-up Thumb-down Favorite-off by bradley.wagner about 1 year ago Permalink
    Would it possible to give these users the ability to cancel publish jobs (Role Abilities) and teach them to cancel the duplicate jobs in the interim?
  • 0 points Thumb-up Thumb-down Favorite-off by irifkin about 1 year ago Permalink
    Giving the users the ability to cancel their own jobs doesn't help
    -- why would they learn to cancel if they aren't all learning to not
    publish repeatedly.


    Giving everyone the ability to cancel everyone's
    publish jobs would solve some issues surrounding this problem, but
    would most likely introduce new concerns. For example how would one Web editor know if a site being published twice is a duplicate or going to different destinations?
  • 0 points Thumb-up Thumb-down Favorite-off by bradley.wagner about 1 year ago Permalink
    So is their rationale that if they keep hitting publish the job in the publish queue already will go faster? Are they expecting it to have some other effect beyond just creating yet another publish job?

    Or do they not have access to the publish queue at all and don't know that it hasn't been published yet?
  • 1 point Thumb-up Thumb-down Favorite-off by DaveW about 1 year ago Permalink
    They don't understand, even when previously instructed, that publishing is not instantaneous and is serial not parallel.  They don't think that someone could be publishing a folder with 1000 items before them, and it could take their job 20 minutes to be even addressed.  Thus, they hit publish again, again, and again. 
  • 0 points Thumb-up Thumb-down Favorite-off by irifkin about 1 year ago Permalink
    Thanks DaveW. That's it exactly.

    They have access to the publish queue and I have been instructing them to use it. It's just hard to get all 500 Web editors to listen and remember.
  • 1 point Thumb-up Thumb-down Favorite-off by len.lanphar about 1 year ago Permalink

    From the user perspective, they hit publish and for some reason the content isn't showing up on their site. If they don't know (or don't remember) to check the publish queue, they will likely have theories such as "maybe I meant to hit the publish button but forgot, or maybe something didn't 'take'." This leads to hitting publish again.

    Another use case where this turns up is the user submits something to the publish queue, and then after they submit they notice a typo on a page, so they fix the typo and republish. If the first job is still pending, there are now 2 of the same job in the queue.

  • 0 points Thumb-up Thumb-down Favorite-off by bradley.wagner about 1 year ago Permalink
    Ok, that makes sense. I think it's probably a good rule to not allow a job to be placed in the queue while the exact same job is already in the queue ahead of it.
  • 0 points Thumb-up Thumb-down Favorite-off by slota.benoit about 1 year ago Permalink
    It could be great too with SOAP script.
  • 1 point Thumb-up Thumb-down Favorite-off by natetanr 11 months ago Permalink
    What if they could see some sort of message when they first publish and they could continue to work and then the message would change once the job was published. The message would remain on the page and would refresh with ajax regardless of where they were at or where they were working.
  • 0 points Thumb-up Thumb-down Favorite-off by wabaus 11 months ago Permalink
    I like the idea of some AJAX model that gives users visible near-real-time messages that don't stop them from working. This would be good for publish-complete as well as a system broadcast when the server is about to go down.
  • 0 points Thumb-up Thumb-down Favorite-off by wabaus 11 months ago Permalink
    Default User Preference should be to view the Publish Queue after publishing. Or at least a System- or Site-level method for me to make this our default when we create users. Currently, our users have to choose this -- which we try to get them to do during training.
  • 0 points Thumb-up Thumb-down Favorite-off by harlen 4 months ago Permalink
    I agree with the most recent comment.
  • 0 points Thumb-up Thumb-down Favorite-off by rgriffith 4 months ago Permalink
    It almost seems like there would need to be a combination of some type of publish job duplication checking and a better feedback mechanism. Perhaps something similar to the Firefox Download Status Bar plugin (https://addons.mozilla.org/en-US/firefox/addon/26). Upon publishing, an unobtrusive bar would appear to give them an easier way to view the status of their publish job.
  • 1 point Thumb-up Thumb-down Favorite-off by bradley.wagner 4 months ago Permalink
    I think I'd opt for a warning message when a publish is attempted that says the asset is already in the publish queue and provides a link to the queue for user's with access.
  • 0 points Thumb-up Thumb-down Favorite-off by johnsons4.scranton 25 days ago Permalink
    GMV.  Even after departments with larger sites are told to publish only after all changes are made, to spare the queue, they are still "publish happy".  Here is our scenario:  We have a department who edits and publishes almost daily in the CMS, and it makes sense that they also have one of the largest websites in the CMS.  It takes about 10-12 minutes to publish their entire folder, and I've seen them publish it multiple times in a row (not to mention we do automatically publish it for them a little after midnight daily to refresh their news). 

    Sometimes, I receive emails and phone calls from other departments asking if "the CMS is working" because their page or site hasn't been published in about 5 or 10 minutes.  9.5 times out of 10, it's a larger department folder jamming the queue, so I delete the duplicate publishes. I don't want to be the publish police, so a warning message to the offending user would be great!
  • 0 points Thumb-up Thumb-down Favorite-off by lroberson 25 days ago Permalink
    I really think a way to set viewing the publish queue after publish submission as the global, default preference for newly created users would go a long way toward solving our problems with this.

    Consider the training issues everyone so far has mentioned. You really have to put something in their face if you want them to use it -- our contributors can't be trained to view the publish queue on their own or that they should wait for a message to show up in their inbox either.

    It would also let them get back to other important things (Minesweeper?) instead of hitting the publish tab constantly or refreshing their site every 20 seconds until their change shows up.

    As to the other options on the table:

    If you cancel a previous, identical publish job automatically, you're bumping any change they might have needed to get out in a timely manner further down the line. I don't like this -- we have a lot of news sites and especially in an urgent or emergency situation the buck is going to stop at my desk when there's a fire or another disaster or a really embarrassing error in a press release and the news editors can't get updates out and they have to phone me (wherever I am) out of desperation -- I'm guessing that point is about 20-30 minutes after they wanted to get their update out.

    If you warn them, that's fine, but are they really going to understand the implications of the question you're asking? The publish process is still a black box to them if they don't see the queue.

    • 0 points Thumb-up Thumb-down Favorite-off by bradley.wagner 24 days ago Permalink
      Is it useful to view the publish queue if you cannot cancel duplicate jobs though? In the 6.x series, there is only a single ability called "Cancel publish jobs" which allows you to cancel any publish job. 

      Seems like you'd still want to prevent them from even being queued still because otherwise your admins/managers will be getting emails/phone calls asking them to cancel all the duplicate jobs a user just queued.
      • 0 points Thumb-up Thumb-down Favorite-off by ericepps 24 days ago Permalink
        I think there's two issues here:
        1. People who keep clicking publish because they don't see their change on the web yet--for these cases, showing the publish queue after publish would likely help. They would have some feedback that shows them that "it worked."
        2. Duplicate jobs that back up for other reasons, such as the ones I described in my (similar) suggestion: http://success.hannonhill.com/cascade-server-ideas/eliminate-duplicate-queued-publisher-jobs#comment_354083. For these, there would need to be some way to eliminate duplicates. Perhaps, after reading this comment stream, a checkbox on Publish Sets for "Do not allow duplicate publish jobs in queue" would be a good solution.
      • 0 points Thumb-up Thumb-down Favorite-off by lroberson 24 days ago Permalink
        That depends on a few things:

        Whether the publish job is one that represents a snapshot of when it is submitted and whether, while running, a publish job will catch updates for files it hasn't reached yet. Knowing how Cascade behaves in these situations is also important to deciding whether dupe publish jobs should be canceled.

        Eric, below, did a good job of separating the two issues with dupe jobs dragging the system down.
      • 0 points Thumb-up Thumb-down Favorite-off by TimothyGilman 24 days ago Permalink
        I agree with ericepps.  There is value in viewing the publish queue (even if you don't have permission to change the order or delete) so that you know your job has been added to the queue and so that you know when your change will appear on the live site.  (My thoughts below address this issue.)

              A lot of our users don't know there is a queue and expect that their change will show up quickly (especially since sometimes it does show up quickly).

              I have considered having our users set the option that takes them to publish queue after every publish, which would give them immediate feedback that there job is queued up and thus they will be able to see its progress, and thus prevent them from publishing multiple times.  I haven't yet done this given the following considerations:
              - The refresh of the page causes a loss of focus on any open window.  Once the publisher is AJAXified (http://success.hannonhill.com/cascade-server-ideas/ajaxify-publisher-status), I expect this to be better.
              - There is no easy way to set the default option (to go to the publish queue after a publish) globally.
              - One negative is that by taking the user to the publish queue, they have been moved from the page they were working on.  And if they have more than one page to publish, it might be a little more work to go back to each one.  However, I can see that once they get accustomed to the fact that publish jobs are in a queue and may take some time, they could change their option to not go to the queue after every publish.

        I hope my thoughts are helpful in seeing how I might deal with the issue of users doing multiple publishes, given the current setup.  If there were a feature to prevent publish dupes, I would gladly accept it.  :-)

No attachments


* 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.  

Sign in

Follow us on Twitter

Current Category