Your comments
Hi there!
Are you aware of our layout scheduling feature? It can do what you're looking for... the only downside is that it is a schedule for the whole page, not just one block. So, if you change something on one page, like add a new circulation block, you have to change it in both layouts so they are in sync.
Here is some info about it:
Does that help?
Yes it is site wide. It effectively changes the meaning of "last modified" (in that, it only updates when important is checked), so it is good to be consistent.
Hi Robert!
Yes... the "important updates" feature itself actually exists today. It is mostly used for publishers who don't want the "updated" date to change with minor typo fixes, etc. Which I think probably everyone will want!
Here is the setting today, in Editorial.
And once both "manually declare important updates" and "allow update comments" is checked, you'll get an interface that looks like this:
Then, once you create that kind of update at save time, it shows up in the revision history.
Hi there!
Yes we would count them as virtual page views. We do the now with vertical collections, for example.
It is actually possible to increment real page views, but then you may want to know the difference between your ‘story views’ and the ‘infinity views.’ So you would have to add an event and then you’re just adding lots of ‘hits’ (which you pay for in GA premuim) for no reason!
We would actually load new add or refresh old ones with this model.
Hey Nick!
Yeah it looks like a bug. We changed the Facebook URL on the article page to reference the "permanent" BLOX URL (so it doesn't break when you change sections or titles) but (unless you have something custom), it looks like the Facebook comments are referencing the normal BLOX URL. Facebook titles everything together based on URL, so if the URLs are different, it won't show the correct numbers!
I will submit a ticket for this. Thanks!
He's kind of a big deal! :)
Hi Seth!
I am just reviewing some photo-related questions on the site and I see this was missed.
HTML does work in the photo captions, however BR tags in general are removed if they are outside of "block" level elements.
If you want to keep the BR tags, you can put them inside of a block-level element, such as a div tag, and they should remain. Note that the div is counted as a paragraph as far as ads or paging in BLOX CMS.
Also note that inline elements, such as inline photos, can't be placed inside of a block-level element. So when you save it will be placed outside of the div.
We are currently re-working our photo gallery tech, including a "browse overlay" feature so I am adding this to the items we are looking into.
Customer support service by UserEcho
Hi guys!
We had a release yesterday which added part of this feature, but it doesn't do everything that is discussed here in this first version.
But, for now, we see two use cases:
==> 1. Publisher has a bad or short title on their article, but they want to be able to expand it in the URL.
So maybe, for some cutesy reason the title of the story is "M13," so your URL would look like this:
https://flex-showcase.bloxcms.com/m/article_32d040a8-43f5-11e8-944f-57cba1de66fc.html
Note that we automatically remove numbers, because they are more likely to change, so you end up with a stupid-looking URL basically, with just "m" there!
In these cases, you may want to be able to change the title or change the URL so that you can create something that is more SEO-friendly, and also user friendly (if you share the "m" URL above, it doesn't have any good keywords or let you know anything about it).
Buy with this URL title feature, you can go in there and type something that can be used instead. So you end up with this:
https://flex-showcase.bloxcms.com/former-gang-members-offer-advice-on-how-to-combat-ms-13/article_32d040a8-43f5-11e8-944f-57cba1de66fc.html
Note that it allows the number to be in there, so that makes things more clear in some cases (like m13 where you need that for SEO, really).
Note that, in theory, it could go the other way as well. You might have a page that has a long page title, but you wanted it to be shorter or more precise (again, for SEO and for usability), you could do that also.
==> 2. Publisher would like their URLs to remain static so it doesn't mess up statistics or other external services such as Facebook comments.
In this situation, it's more that you want the URL to remain the same for statistics, rather than that you want to "fix" it from some unattractive state. The new feature is meant to address the situation above, but it is not likely to fix the statistics issue.
A few thoughts there:
Firstly, software like Chartbeat and Parsley can be updated to key off of the article UUID instead of the URL.
This will mean that they will all be tracked together regardless of section or title change.
Secondly, we are looking at doing some kind of permanent URL that would remain frozen, but we haven't agreed yet what that would look like.
Wordpress has a little Edit button that allows this (like Kevin's example). Basically, after the title is written, a few seconds later it populates the "permalink" slug area. If you edit it after it is published, it creates a 404 (that you can fix if you create a 301 redirect manually, it sounds like).
So, in our situation, we could possibly do something like that...
The problem is that BLOX is a little different because many users will actually write content in BLOX that may span many days. It is common that you see an asset in the system that has a start date of 2037 and the title is "Second story about the mayor TK" or whatever. So, in those cases, you'd theoretically end up with that in your URL, even if you change your title later.
It is possible we could tie the URL creation to a workflow status... i.e. it doesn't auto-fill the URL until it its a publish state, and then it freezes.
I have also seen some CMSes where they will have a "generate URL" button that, when pressed, will generate the URL and freeze it.
Interested to hear your thoughts...