Why is Muse Publishing/Exporting/Uploading So Many Files?

[Zak_Williamson__Adobe_]

Typically when using Muse and re-publishing, exporting or uploading Muse will determine the set of pages changed since the prior publish, export or upload and only generate the files related to those pages. Muse will then compare a “fingerprint” of the newly generated files to fingerprints for the files previously published/exported/uploaded to detect whether there were any differences and will only actually upload (or write out) the files that contain changes.

So Why Is Muse Regenerating And Uploading Everything?!

When you take an update of Muse, the HTML, CSS and JavaScript code generated by Muse will have changed for any number of reasons (i.e. to support new features, to workaround bugs in recent updates to popular browsers, to improve page load performance, etc.) and the image processing may have also changed (i.e. to improve compression, to improve quality, to use CSS rather than images where possible, etc.). Since the files that make up a website are all interrelated, the files need to all be from the same version of Muse in order for your website to function correctly. Therefore, after an update of Muse your next publish, export or upload will generate all the files for your site and then upload only those files with actual changes. Once this process has been completed once and the .muse file has been saved, all subsequent publish, export and upload operations will only generate and upload the files related to changes you’ve made since the last publish, export or upload.

In short, after taking an update of Muse expect the next Publish, Export or Upload to be slow, but after that’s been completed and the .muse file has been saved, the next re-publish, export or upload will be back to normal, only generating files directly related to changes you’ve made.

[Leproducer]

That's not the case with me, even a small text change (such as a typo) will undergo hundreds of page upload every single time.  And no, I'm not talking about master pages, just regular pages.    Irrespective of new MUSE updates or reboots, the next republish is always lengthy.

[Zak_Williamson__Adobe_]

Leproducer‌ sounds like something we need to take a closer look at. To reproduce what you're seeing we'll need your .muse file and the "muse_manifest.xml" file from the server (or local folder if this is occurring during a second Export as HTML operation).

Is it possible your server is configured such that Muse cannot write to, or later read, the muse_manifest.xml file? If so, that could result in Muse always exporting and uploading more than necessary.

Please send the .muse file and muse_manifest.xml file at muse-support@adobe.com along with a link to this thread for context. If the files are larger than 20Mb you can use a service like Adobe SendNow, Dropbox, WeTransfer, etc. (If you use a service, please include your return e-mail address in the body of the message, since not all services include it in the sharing invite they send.) Thanks.

[Leproducer]

I use a  reputable server, but I cannot comment whether or not that could be the reason.  I have sent the files as per your request.

Thank you!

Joel.

[Zak_Williamson__Adobe_]

Thank you for sending your file. It enabled us to reproduce and fully understand two problem cases. Both problem cases primarily relate to items on master pages triggering the regeneration of more files than necessary during the export step of export/upload/publish. In most cases the regenerated files are identical to what was generated previously, so Muse recognizes there are no differences and doesn't actually export, upload or publish the new versions, so the performance hit is typically in the needless regeneration of excess files and not unnecessary uploads.

The first of the two bugs is triggered by the use of Insert HTML objects, Social widgets or other third party widgets on a master page. In some common workflow cases the initial draw of one of these items as part of the master page content displayed on a normal page can result in Muse marking every page with that master applied as needing to be regenerated for export. I believe this is the primary bug your file was hitting. We have a fix for this in testing for the next Muse update. If you'd like to test the fix before the official release of 2015.0.1, the Adobe Muse Prerelease Program is open to all subscribers who accept the terms of the Non-Disclosure Agreement. To join and download a Beta of the 2015.0.1 update, go to http://museprerelease.com.

The second bug can be triggered by the use of Web Fonts in some specific cases. If the fonts used in a .muse file are checked in the "Add Web Fonts" dialog, then they're loaded by Muse when Muse is launched. For those fonts this bug is avoided. However, if a .muse file is opened that uses Web Fonts that are not set to already appear in the Font menu, then Muse loads those fonts when they're first used to draw. In that case text frames may momentarily draw with a fallback font until the Web Font has been downloaded and activated. If the text frame's height, the text content within the frame and the differences between the real Web Font and the fallback font are such that the text frame temporarily changes in height (until the Web Font is activated) that will result in the page being falsely set as requiring regeneration at next export/upload/publish. If the text frame in question is on a master page, that will impact all pages that master is applied to.

This issue with Web Fonts is thankfully less common, since in most cases not all the required criteria are met to result in unnecessary regeneration of files during export. We're working on a change to address this, but it involves some larger changes and will take longer to thoroughly test. It therefore will not be part of the 2015.0.1 update. It will likely be part of the next major update of Muse.