Your comments
Hi Allie!
I'll go through each item step by step:
1. Currently, you can re-notify a message by just posting an additional manual message. You can do this ahead of time (one post today, one post tomorrow) or when needed for breaking news. The automatic trigger will not re-trigger (which is good, because you wouldn't want that) - but if you create a new message for breaking news, it will re-post it.
2. To define a custom Facebook message, you can type the message in the notifier message area. I believe that it will also use the Summary text as well.
However, you may be talking about the summary that is in the news "card" area on Facebook, which is scraped from the page itself. See my docs here:
3. What you're describing here is the "Twitter card" layout, which is specified on the page that is scraped by Twitter. For the example you have there, Butter is overriding the card type through their API.
Usually, this is something we have by default as part of Flex templates. We have built-in logic that will specify a large photo in most circumstances. For some reason, this isn't showing on pantagraph. If you could submit a CRM ticket to see if there is something custom on this site or why the Twitter card logic isn't displaying for you.
Let me know if you have more questions!
Note that for customers who do not have a locally cached page, they would be seeing the ad much sooner.
Yeah, this is subject to a few caching layers... such as the JS files updating and the page updated. It should take around 15 mins if you cache bust as Ian explained.
Hi Jeff... You have "optimize PDF files" enabled in your editorial -> application settings -> asset settings -> Optimize new PDF files. Optimizing PDF files removes a lot of information in order to make them smaller and flatter.
If you turn this off, even temporarily, in order to upload your file, it should fix the issue.
I tested it, and when the "Optimize PDF" setting turned off, the PDF keeps the fillable information, and when a user downloads that form, it will allow them to fill it out.
https://flex-showcase.bloxcms.com/example/pdf_691077b4-4f6b-11e9-9e00-1f280866c63e.html
You can then turn back on this setting if you want other PDF files to be optimized.
A few quick things:
1. The BLOX Notifier alerts should look like the BLOX Email Reach alerts. This is something we're working to fix.
2. We can make changes to the asset page "email" mode design in a generic way, so let me know what type of thing you'd like to see there.
3. We are working on a new way to be able to send better branded emails of all kinds... email alerts and reset password, etc. We are building a "Site Branding" panel where you can set your colors and your logo, etc. That way we will be able to use your logo and colors in a standard way on system-built items such as this.
There are several different ways to do this:
- Tell your breaking news block to only show items that are less than 2 hours old. So whenever a article is two hours away from its start time, it will be removed from the block automatically. This is great when you are OK with all breaking news being promoted for the same period of time. If there is an edge case that needs to be online for longer, use can use a pinned asset with a schedule.
- Add an archived date to your breaking news article, and then create a rule on your breaking news block that doesn't show items that are archived. This is helpful when you want to have custom "expiration" times on a per-article basis.
- Use a pinned asset that has a scheduled time to unpin. You can use this in combination with the above two solutions.
- Create a new schedule which shows the breaking news block for a period of time. This is likely overly complicated since you'd have to go into the block editor to create a schedule. This is more likely to be useful for recurring events (like afternoon updates or Friday night prep sports) rather than breaking news. But, if there was a big specialized layout with multiple blocks for the breaking news initiative, a scheduled layout may be helpful.
With all that being said, we are looking into new ways to indicate "alerts" and things along those lines. For example, if you find a breaking news article from 2013, it will still say BREAKING next to it, or it may even say that in the headline. Those are things that are still in discussion.
I'll have to check into this more... Other than creating two accounts... it looks like our Here maps integration will be available as soon as next week.
Yeah, so it looks like I need to change the instructions to not create a new service account, but assume that one is already there! We had two people run through this as a test and it seemed to work... but perhaps they just chose the other account randomly. =)
As a side note, I am working on a few new blocks or promos that will ask for Notification sign ups at other places in the site. For example, at the bottom or in the middle of articles, or maybe even a popup overlay (a popup overlay that you have to agree to, which then triggers a browser permission popup).
Let me know if you have any thoughts along these lines.
I think that's part of the issue Aidian... if you go to your manage service account permissions area, do you see two firebaseadminsdk accounts?
I think when you click on service accounts, in Robert's screen below, it is generating a key from the service account that is connected to your firebase. So, that may be a more clear way of instructing you on how to do it.
It also could be that Firebase is automatically creating a service account at some point. It didn't do this before, but if it is doing that now, that should be the only account you need.
Customer support service by UserEcho
This would indeed solve the problem with the wrapping headlines. I am a bit nervous about this because in terms of the interface, it would be a bit confusing to the reporter / admin user. They would need to know that in this specific case, the headline was the message and the message wasn't used. If they wanted to re-write the headline to be more specific, they would need to know that the headline wasn't the headline, but the headline was the message.
In the "code" it is sending the "title" and the "message." The title is optional. But, I would feel uneasy making the "message" the title in just this one case, if that makes sense.
In addition, it is possible that Apple could change the display of the message in the future, and the fact that we've changed the meaning of "title" and "message" could backfire.
That being said, I agree with the premise of your post. I will talk to our dev team to see if they have any ideas on how we can communicate this clearly.