We've had some issues with folks being unable to see the close button in the interstitial promo blocks. The problem is it's impossible to see on the block if it's black in front of an image, or if it's white against a default white background. It can be changed manually via css, but this would need to be changed anytime the layout of a promo block is changed. By adding the "light/dark" option to the close button text in the block options it would make it a quick adjustment that could be done via the admin panel. 

 1) What problem(s) does this idea solve? Why do you need this idea implemented? Provide as many problems or use cases as possible. Makes it easier for users to see the button and not got frustrated by being unable to close promo interstitial. Would make it easy for administrators to correct small design oversights. . 

 2) How often would you use this feature? All the time

3) How many people in your organization would use this feature? Every site manager and web staff -- appx 12-20. 

One of my colleagues brought this to my attention. I have played around with it, and it seems like a proper bug with the auto-save feature.

User 1: Makes edits to asset, window closes without proper save/close (due to needing to leave/shutdown, crash or whatever.) User 1 doesn't return to asset.

User 2: Makes further edits to asset, even publishes.

User 1: Returns to asset manager. Auto-save restore dialogue pops up. User 1 restores asset. Asset now reverts back to User 1 edits, overwriting everything User 2 did. Text and edits revert, flags and other settings are also reverted, such as the do not publish flag being set again. Even if User 1 selects "cancel," the asset is overwritten.

Has anyone else encountered this? What do you do to get around it? I don't see an option to turn off auto-save (for a short-term fix.) Maybe there should be a warning that there is a newer version available? Options could be:

There is a new version available!

• Discard
• Restore (Overwrite)
• Restore (New Asset)

I manage multiple sites and have multiple tabs open every day on two monitors. 

With the new interface, browser tab titles are longer and often hide the site they belong to (since the sitename is listed at the end of the browser tab title). 

If "Editorial" could be abbreviated to "Ed.", as well as taking out the space before and after the "/", would definitely help clear up some real estate on the browser tab titles. 

Design = Des. 
Community=Comm.
Marketplace=Mkt. 
Statistics = Stats.

If this annoys you, too, please click the vote button below to try to get this changed sooner instead of later. 

Thanks!

When I add a Child Asset to an article, but do not actually drop the Child Asset into the body of the article, I don't like what it does to the alignment of my page: it actually ADDS a "left rail" and shifts the entire text of the article to the right. But the only thing in the "left rail" is an image of that asset I added... so it looks really odd.

This is only an issue on desktop, not on mobile.

It creates an additional problem when I add an Article as a Child Asset to another Article. Now, since I'm in the Parent Article, it's not too much trouble to simply place each Child Article into the body of the Parent Article. But it has now affected the alignment in all of those Child Articles -- because it added the Parent Asset to the "left rail" for each of those Child Articles! So now I have to go back into each of the Child Articles and drop the new Parent into the body of those articles, to fix that alignment.

This is terribly cumbersome and awfully time-consuming, but it's necessary if I don't want most of my articles to be misaligned on desktop view.

The easy fix is to create a default that adds all Related Assets into a horizontal "block" at the end of each article.

Refreshed blox UI really taking off here. One thing bugging us a bit.

-- Searchable assets aren't color-coded anymore

It's just tough to scan thru and easily distinguish, esp pdf vs. img

See attached screenshot. Any suggestions or consideration to reverting back or adjusting?

Two days ago, I could broadcast to Twitter and Facebook. Today, with the upgraded look, broadcast isn't an option preparing an asset. I relied on that! Now it'll take extra time to schedule posts on both social media channels.

After a lot of back and forth with support we finally figured out why Infinity Scroll was not working on our main section pages:

"Blocks with infinity scroll enabled won't work with a dynamic setting (section tags set to 'Matches current URL or descendant'). There will need to be a hook set (setting a section, keyword, flag, etc.)."

This limitation does not appear to be documented anywhere at the present time.

This means Infinity Scroll will not work at all on the default Town News blocks that get assigned to every top level URL and all sub-sections (through inheritance) in the system. I assume most customers are using these across most areas of their sites.

Having to work around this will greatly increase the number of blocks needed for a site if they want to use Infinity Scroll on every section front. It could easily scale into the hundreds of blocks needed for a site. Then every time a style change is desired, such as showing the comment count in the summary block, it'll require editing each of those hundreds of blocks instead of the standard dynamic one.

Every single sub-section URL will need it's own block created instead of being able to inherit the blocks from the parent URL.

With this limitation Infinity Scroll is basically dead in the water for large scale deployment.

I really hope Town News is working to fix this but I wanted to post it here for wider awareness because before the answer came back the template developers I was told that there were other sites having the same trouble I was.

Micropayments are increasingly seen as one component to offset a decline in ROP, at least in Canada. The Winnipeg Free Press, Canada’s second largest independent daily, has successfully pioneered a model. Readers pay .27 cents for the first story. As more stories are read the system works to make the client a full subscriber. We’ve given our news away too long chasing clicks that don’t translate into substantial revenue. This is not a panacea. But it is important. The Canadian industry will see a significant number of papers lock down their sites in the coming year. Micropayments will allow them to still maintain a social media presence while generating revenue. https://www.inma.org/blogs/conference/post.cfm/micropayments-bring-in-new-readers-activate-subscribers-for-winnipeg-free-press

I would like to request an infinite scroll feature. When you get to the bottom of one story the next story published in chronological order shows up on the same webpage. This goes on for ever. 

Apple is finally opening up ANF to everyone. We've been pushing an RSS feed to Apple News for a while now, but publishing in ANF will over a more robust experience to readers.

Information on integrating the format here: Use a CMS with News Publisher

Any thoughts on getting BLOX to push out in ANF? There are already WordPress and Drupal plugins available.

It seems an enterprising non-subscriber has found a little glitch to access articles behind the paywall and his instructions are now making the rounds on social media.

Here are the instructions:

"I'm not too sure if I should be posting this. However, as someone who does PC/IT work and repair, I figure I could let some of y'all in on a way to read most of, if not all the article's without paying. (On Android using Chrome) Basically, I go to the article I want to read that is not free. Then I select "Request Desktop Site" in the browser settings. (the three dots on the top right)  Once that loads, (it puts a minor delay on the article loading) all of the article is displayed in its entirety for just a moment or two. A few seconds later the pop up to sign up for a subscription block's it all out. Now it's that small delay, prior to the subscription pop up, that we are after. In that delay, I do a screen shot of the article. (You might have to refresh the page and try again if you weren't quick enough the first time) After I successfully capture it, I then just read it via my picture gallery. If it's longer than my initial screen grab, 

I try a second time and scroll really quick to encompass the remainder of the article with another screen shot. If it's too long for those methods, I do a complete screen record. (video recording of your entire screen) then I go back through the recording and look frame by frame. Hope this helps some of y'all. You're welcome."

We've tested it out and have been able to confirm it works. While it isn't easy enough that I think we'll start losing subscribers over it, it also isn't that complicated to pull off.

I'm actually seeing it pretty consistently even on desktop browsers right now. It seems that the delay before the paywall message appears is much longer than it used to be. It looks like Town News might need to adjust the timing of how things are rendered so the full article isn't displayed until after the user has been evaluated as having an active subscription.

Have any of y'all come across readers doing this or something like it to bypass the paywall?

I'm posting here as part of a formal feature request and also to see how the rest of y'all are working around this limitation.

What we've found is that social media broadcasts from TotalCMS are more often then not failing to actually happen. Support pinpointed that this failure will occur anytime an article gets edited (by a line editor or page designer) in between the time an asset gets a Site Tag and passes the Start Date/Time. For us this is a large portion of content.

Here is the note from support:

"The failure of the articles broadcasted from the TotalCMS system results from broadcasting an article that has a start date/time in the future that has additional revisions made to the asset in-between the time it was broadcast and the time it goes live. If the revisions are made after the start time has passed then the broadcast of the asset will be successful.

"To avoid this issue I would not broadcast the asset if the asset will need to be revised before it goes live or be sure to re-broadcast the asset after additional revisions are made before it goes live."

And my response:

"This is behavior that definitely needs to be corrected to support a real-world newspaper publishing workflow.

"We expect reporters to compose the social broadcasts because as the authors they are most closely associated with the content.

"However all articles still need to be edited before publication.

"With the details you've given us it means that we would have to ask the page designers to go back and set the social broadcast information after they have finished designing the pages at the end of the night which just isn't realistic.

"I'm sure we could make some minor changes to our workflow as well, but I feel like there might be some middle ground we need to work towards here.

"If the behavior cannot be changed there definitely needs to some change in the TotalCMS GUI that alerts users to the fact that the broadcast was cancelled. Right now it still just shows the "Syndicated..." text exactly the same as if the broadcast was successful."

In my feature request I'm asking that they either correct the problem of the broadcasts not happening or at a minimum update the GUI in that situation so reporters are aware the broadcast was cancelled due to a later edit.

How are y'all working around this problem or are we the only ones dealing with it due to our workflow?

We would like the ability for the "Web headline" field to be blank when an article asset is set to "Long-form" and ONLY IF the asset's "Hammer" field is populated. 

The reason we would like this function is for display purposes. We like the way the Hammer looks with a Subhead, however we are forced to populate the Web Headline field. If we populate it with something like a dash or bullet, that is the headline that is displayed on the website.

Ideally, if an asset's presentation mode is set to Long-form and the "Web headline" is left blank, the article asset would use the "Hammer" field as the web headline. This would open up our online display options as we wouldn't be forced to populate the Web Headline field.