7 Common Roadblocks & How to Solve Them: Part 2
Have you ever wondered what questions other customers are asking? Wonder no more! We’ve rounded up some of the most asked ‘roadblock’ questions and how you can solve them below.
Missed Part 1? No worries, you can check it out here!
Scenario: Localist is rejecting the Feed URL.
Solution: You should always check a Feed’s validity if you’re experiencing any issues here. We recommend using a Feed validation service like, https://validator.w3.org/feed/. In addition, it may be helpful to check out our RSS/ICS Feed docs to cross check your Feed data and make sure it's including the correct tags.
Scenario: Changes to the Feed haven’t been reflected in Localist.
Solution: Localist Feeds update once overnight—if you make any changes to Feeds during business hours they will not update until the next day. We also recommend checking the event in Localist to see if any fields have been locked from further updates. If so, changes made at the Feed source to these fields will not be reflected in Localist. The following 3 fields can be locked and cut off from further Feed updating:
- Event Place
Scenario: The Localist logo is displaying on the page, but there’s no event content in the Widget.
Solution: The reason the Widget is not displaying on the website is most likely because of SSL protocol alignment issues. For context, SSL refers to when a website offers encryption, which is noted in the URL using https (secure) vs http (non-secure). When it comes to embedding content, you can embed content using https (like a Widget) on a non-secure/http page, but you cannot do the reverse and embed content using http on a secure/https page. This is often called upgrading security (allowed: posting https on an http site) or downgrading security (not allowed: posting http on an https site).
Scenario: An event that is Restricted to Widgets + Logged In Users Only isn’t showing up on the calendar or the Widget.
Solution: The reason why you're not seeing this event in the Widget or on the calendar is because these Visibility settings do not work together. Here’s why:
- Events that are Restricted to Logged In Users Only won’t show up in a Widget
- Events that are Restricted to Widgets won't display on other calendar pages
Essentially, when you combine these two Visibility settings it will prevent events from displaying in Widgets or on the calendar. For those reasons, we would not recommend combining Restricted > Widgets + Logged In Users Only. Instead, you should either:
- Set the Visibility to Restricted > Widgets so the event will only show up in Widgets,
- Set the Visibility to Restricted > Logged In Users Only so the event will only be visible to folks who are logged in to the calendar, or
- Set the Visibility to Public so the event will show up in the Widget and on the calendar
Scenario: You need to create an admin account for someone who doesn’t have access to your SSO.
Solution: There are two options here. First, if you have the standard “local” logins available on your platform then you can have this person create an account via the sign-up page. From here, you’d just have to escalate their Permissions to give them admin access. If you do not have “local” logins turned on and want to do so, you can contact as firstname.lastname@example.org for assistance! On the other hand, if you do not want to turn on the “local” logins you can accomplish this by creating an account in and back-end and have the admin login via the unlinked backdoor. Here’s how:
- Navigate to the Admin Dash > Users > + Add User
- Fill out the form as you see fit, but make make sure to give the account admin Permissions
- Then this admin can use the unlinked admin backdoor: http://events.yourdomain.com/auth/admin_login to log-in
- Note: Replace “events.yourdomain.com” with your custom domain
Scenario: An upcoming event isn’t appearing on a Group, Department, and/or Place Page as expected.
Solution: This is likely happening because 1) The correct Group, Department, and/or Place has not been assigned to the event or 2) The event’s Visibility is preventing it from appearing on these pages as expected. In terms of Visibility, if you want an event to display on Group, Department, and Place pages then it will have to be Public.
Scenario: Events are being added without photos.
Solution: To help ensure events have quality photos assigned, here are a few Localist tools that can help:
- Photo Library: Platform Admins can add images to the Photo Library that users and admins alike can select from when creating events.
- Photo Fallback Chain: An automation chain made up of Place Page, Group/Dept and Event Type photos that are assigned to an event without a unique photo. The last piece of the fallback chain is the Event/Place Default photo that can be assigned by uploading a photo to the Photo Library > making the Event/Place Default photo designation.
- Submission Guidelines: Using Guidelines, you can provide photo best practices and guidelines for submitters within the Public Event Submission Form.