The home and splash page render a link to the schedule based purely on
the `schedule_public` flag, even when an admin has not yet selected a
schedule or scheduled any events. Following that link rendered the
schedule view, which then failed inside `_carousel.html.haml` because
`@rooms` (and the selected schedule) had no data — a 500 error instead
of a graceful response.
Treat `schedule_public` as an allowance rather than an unchecked
control: introduce `Program#any_published_schedule?` (true only when
the flag is on *and* there is at least one event in a selected
schedule) and use it to decide whether to render the link from the
home and splash pages. The schedule controller now returns 404 when no
event has been scheduled, so bookmarked URLs surface as "not found"
instead of an internal server error.
It used to be a partial inside #index, but having their own page
yields some extra benefits:
- Performance: Move logic from the view to the controller
- Theres' no need to go extra steps inside the :index view
- UI: Remove the extra 'Upcoming Conferences' when the system needs
to start the flow of the creation of the first user
Available during registration or after conference
Co-authored-by: Shyukri <shshyukriev@suse.com>
Co-authored-by: Henne <hvogel@opensuse.org>
Co-authored-by: Moises <mdeniz@suse.com>
Registered users should see a button on the main conference page
to edit their current registration instead of being asked to
create/add a new one.
Fixes#2041
The markdown settings for conference description include header assignments;
there's no reason to force all content into a tag type that the user didn't
specify in their markdown.
I have tested two events one with an image and the
other without an image. I have put them through
the Facebook debug sharing tool as well as the
Twitter card validator and both work!
Added missing image url as well as created twitter card.
validated both with twitter validator and facebook validator.
All passed.
Need to check to see if no image is selected, what is outcome.
The single query was producing a tremendously large ActiveRecord allocation.
While this isn't nearly as cool as one query, it's still a significant
reduction in SQL trips, and now has the bonus of only loading what is
actually going to be displayed.
