Your comments

This is all part of a giant security move on BLOX admin accounts - both staff and superusers. Neither the password nor the 2FA code should be entered through the frontend where the template system or 3rd party widgets could be added to intercept or capture these two critical pieces of data. As such, forcing admin users to login to the BLOX admin user interface provides a locked-down experience free from that concern.

Yeah, I had suggested that we will re-label as Staff Login to see if that clears up confusion. The problem with a dedicated login page for staff is that it doesn't fit into the login workflow in all cases. Federated login workflows through the Townnews Now mobile app and paywall workflow in particular become burdensome because you would need to bail out of that process entirely, login, and then restart your workflow from just before you were forced to login.

The workflow for staff/super users is to login through the BLOX admin - which may have TOTP enabled optionally. Once logged, in - they would be redirect back and will be logged in.

We might consider switching to the other workflow you mention - but keep in mind that will affect most of your end-users as well - and they aren't going to have two-factor authentication - so you'll be making most of the end users suffer through a two screen login for no reason.

The admin link is not for consumers - it's for site staff and for superusers. The wording perhaps needs to be changed - but when two-factor authentication is released - you will not be able to login to the frontend using your staff account without following that link and logging in via the BLOX admin.

The bottom bar was removed to maximize the work space. The preview options have been moved under the site selection in the top bar. In the upper right, select the site domain name and the selection screen should offer the preview options.

We can switch the icon for the PDF asset to be just the logo instead of the filled background. At some point in the near future, the PDF, Zip, and Flash asset types are going to be replaced with just the File asset type. The file asset type has awareness of different subtypes much like video assets do today. Additionally, the youtube asset type will be going away as it will be merged into the standard video asset type. The reduced icon set would make the icon choices limited to article, image, collection, audio, file, html, poll, table, link, and video - which are all distinct enough. A nice thing that can now be done is you can zoom the browser in and make those icons bigger and crisper - they are still being sized at the moment for smaller monitors.

There is no practical way of blocking users in a metered wall scenario - only in a hard paywall (or registration wall) situation can something be done. Regarding, I'm going to be requesting a hard block on the scraper from that site. It uses a vendor called diffbot which does not appear to honor robots.txt. This will block from the whole cluster.

If none of the photos can be used for photo fulfillment, the property to disable the photo buy option could be set as a destination job option.

Kyle - are you loading the photos through a job?

The system actually attempts to purge the server cache of an editorial asset page (not index or front pages) if it is saved and is recent (in the last 24 hours) - this happens every time it is saved and is independent of using any flags. The editorial page must be an article, collection, or video. There is still a throttle in play and browsers are still instructed to use the cache copy for 5 minutes. You should be able to manually force a refresh with shift-refresh.

A change we have considered is reducing the public cache TTL to a minute for assets less than 24 hours as well so that the browser will ask more often if the server copy has been updated rather than waiting a whole 5 minutes regardless of when it was fetched.