In the event form, the selection of previously-uploaded images should wait to be loaded until requested by the user. This way, an increasingly large buttload of images isn't being loaded every time the page is.

Move token out of ImagesController::upload() and elements/images/form.ctp and into core.php.

"Choose fields to update" option is presented, and user can check/uncheck specific fields to be updated. If "Choose fields to update" is not selected, all fields are updated. This will accommodate the following use case:

1. User creates a series
2. User edits a few events, maybe changing their starting times.
3. The entire series needs its title changed. User opens one of the events and changes its title.
4. The user selects "update all events in this series"
5. The user selects "choose fields to update" and makes sure that only Event.title is selected.
6. The user submits the form and the title is updated in all of the events in the series, but none of the other fields, such as the edited starting times, are changed.

Cookie encryption key should be changed and moved from AppController to core.php.

Starting on January 2020

• Title text for each cell is "tooltip text?"
• If no dates are populated, every date is selectable

In the feature-front-end-conversion branch:

• The "add a previously-uploaded image to this event" feature seems to have been removed from the event add/edit form.
• The list of images associated with the selected event have been hidden under the "Select a previously uploaded image" button.

Have returnPath send bounced emails to a script that removes them from the mailing list.

Is there any risk of legitimate email addresses being affected by this? Perhaps "address not found" errors should be distinguished somehow from other network errors that result in emails getting bounced back.

The event_series table has some records that represent spam series that have had all of their events deleted.

Probably the best approach is to add something to Event::afterDelete() that checks to see if the event was part of a series that is now empty.

Password reset emails are getting sent to spam. Not sure why but there you have it. Ideas:

• See what's exactly triggering spam filters about the emails.
• Put a warning message on the password reset pages that the email may go to spam and to check spam.

"Collective" is cut off from the location name "Chameleon Salon/Collective" in http://muncieevents.com/location/Chameleon%20Salon%2FCollective.

The error logs are full of things like this:

2014-10-08 14:47:10 Error: [MissingActionException] Action WidgetsController::events() could not be found.
Exception Attributes: array (
  'controller' => 'WidgetsController',
  'action' => 'events',
)
Request URL: /widgets/events/day/10/26/2014
Stack Trace:
#0 /home/okbvtfr/public_html/muncie_events/lib/Cake/Routing/Dispatcher.php(187): Controller->invokeAction(Object(CakeRequest))
#1 /home/okbvtfr/public_html/muncie_events/lib/Cake/Routing/Dispatcher.php(162): Dispatcher->_invoke(Object(WidgetsController), Object(CakeRequest), Object(CakeResponse))
#2 /home/okbvtfr/public_html/muncie_events/app/webroot/index.php(92): Dispatcher->dispatch(Object(CakeRequest), Object(CakeResponse))
#3 {main}

I can't find anything in any views or controllers that would send people to a URL like that. So what the fuck.

Create Address model with fields location_name and address and populate it in the same way that address suggestions are currently being determined.

Create admin interface for browsing and editing addresses.

Some location names should have null addresses, such as "Downtown", which currently has the auto-suggested address of "Walnut Street".

1. Choices for "Choose fields to update" are initially all unchecked, and when any field is changed, they are automatically checked.
2. The checked/unchecked status is remembered when the form is submitted so that the user's choices are retained if the form is submitted and bounces back an error message.

Tag auto-complete is activated when someone enters just a space. It's unlikely that a user will begin entry with a space, but it's certain that they'd reach a point when entering two tags when they've entered one, then a comma, then a space, at which point they'd get an arbitrary set of autocomplete suggestions.

Mailing list recipients could be grouped by common filters and multi-recipient emails could be send out using BCC to groups that would receive identical messages. This should save execution time significantly.

• Dates in the past
• "cialis" or "viagra" in the title (this characterizes the bulk of spam messages)
• etc.

Bounce back with message explaining why it was rejected and prompting user to contact an admin if they feel this was in error.

Here's another round of things that should be corrected. Many of these relate to CSS rules that were changed for reasons other than making the site responsive and just need to return back to their original values until we're ready to plan out a more comprehensive redesign with the graphic designers.

Code stuff:

• In /app/View/Elements/header.ctp:37, the search form is placed inside <a class="navbar-brand logo">
• That same file was indented with 2 spaces, but we're moving between legacy code indented with tabs to new standards that indent with 4 spaces. Any other files indented with 2 spaces should be updated, ideally to 4 spaces.

When using a full-sized window, and in general:

• I recommend keeping primary links (home, go to date…) and secondary links (log in, register…) visually separated instead of combined. Having the secondary links appear on top and the ‘Home’ link underneath feels counterintuitive.
• In the ‘Advanced’ dropdown for the search bar, the typeface for the options was changed to Harabara, which seems unnecessary and I think is a bit harder to read.
• Changing the tagline font size from 25px to 1.25rem makes it harder to read, and removing the negative margin-bottom from its i.icon-me-logo element makes the letters around and inside that icon misaligned
• text-shadow was removed from #sidebar h2, which makes these headers a bit harder to read
• The font size for ul.event_accordion .actions a was originally 0.8em, but has been increased to 20px, which makes these links larger than any of the text around them. This is distracting and breaks up the flow of the event information.
• In the event accordion, location addresses aren't displayed
• The 'Go to Date' popup changed the alignment of the list of dates from left to center. In general, we try to avoid center-aligning lists, because it creates an uneven line for the eye to follow when scanning through the text.
• Instead of using .btn-sm for buttons, regular-sized buttons are recommended so users have a full-sized target for clicking.
• The border for .widget_controls has been removed. It should be re-added to help visually separate input from output.
• The margin-top for #widget_demo p has been removed, but some sort of space between the widget and the text below it should be re-added.
• A background-color and text-color change was added for links with :hover or .active that should be removed for now.
• The 'advanced' button for the search bar isn't staying in the same line as the search bar (see comment for example and suggestion)

When using a medium-sized window:

• Switching from left-align to center-align on lines such as “May 11, 2017 Today” breaks up the vertical line that visitors scan down when skimming over the page and forces an unnecessary zig-zag pattern.
• Moving the logo from the left to the center of the screen is distracting and misaligns the bottom row to the left and right of it.
• Unnecessary vertical bars have been added between the links in the header

When using a handheld-device-sized window:

• The link to 'Home' is midway down the list of links instead of at the top

/tag/708_all_ages_concerts only brings up upcoming events, but /tag/708_all_ages_concerts/page:foo brings up all events. Future/past should be respected in routing and links.

When a feed that can be subscribed to via Google Calendar is created, email [email protected] to inform Heather of the new feature.

The AutoNag system sends reminder emails to venue representatives if it appears that the calendar is missing expected events in the near future.

Model

Nagee (couldn't come up with anything better)
Fields:

• location: string for location name
• email: venue representative
• optout: rep can set to TRUE to be permanently opted out
• last_email: date

Form

/autonag/optin/:location_name
Can by used by admins, preferably sent as a link to venue reps so they can fill it out themselves.
Contains an overview of what AutoNag is for and an attempt to make it sound useful instead of annoying. Maybe avoid actually using the term "AutoNag" on the public-facing site.
Fields:

• Location name (automatically filled in)
• Email address
• On average, we host an event every ____ days that should be promoted on the calendar
• Footnote:

Cron job

Runs every day, checks every Nagee that has not been emailed in the last week(?) to see if their venue has no events in the next X days. If not, an email gets sent out.

Email

Contains a reminder that the venue has no events posted for the next X days and these links:

• Link to add an event
• Link to change Nagee info (email address and frequency)
• Link to opt out

Example

...

To keep spam off of the visible calendar, the auto-publishing of events added by logged-in users should only take place if those users have at least one approved event attributed to them. This means that a user's first event will have to wait for approval, then subsequent ones will be automatically published to the main site (but not spread to network calendars until given moderator approval).

Add 'published' => true and 'approved' => true conditions to the query that fetches search results.

Yep. Fix that.

To reduce the clutter of already-selected tags in the list of autosuggest options in the events form, the names of selected tags should be passed along in the autosuggest request and those tags excluded.

(They could be removed in a client-side script, but doing it server-side allows the count of returned suggestions to stay the same for all requests)

In some cases, newlines are just ignored: http://muncieevents.com/event/2680

In other cases, they're replaced by \n: http://muncieevents.com/event/2734

When an event that is part of a series is being edited, the user should be given the choices of

• Only edit this event
• Edit all events
• Edit this and subsequent events

All editable fields other than Event.date are updated in all relevant events.

Frequently, users would benefit from being able to put line breaks in cost information, such as with this recent entry: "$20 - adult general admission; $10 - under 18 or w/ college ID; $45 -- family package (four tickets)--"

Spam tags are cluttering up the spam tree and adding to the burden of moderators.

On event moderation page, in addition to 'edit' and 'delete', there should be a 'spam' button that deletes the event, the account that created it, and any other events created by that same account.

"All events this series will be deleted. Are you sure?" is not currently true.

Unless otherwise noted, these front-end issues apply to both the 2.x & 3.x versions of Muncie Events.

• The datepicker drops down more slowly. I'm not sure anyone else will notice or care.
• The header links are grey and :active white, when they should be white and :active underline.
• The "Note:" text on the /widgets page needs made <small>.
• The footer needs a margin-bottom in order to be more visible.
• The advanced search menu doesn't collapse, it drops down, and disappears when anything else is clicked. It should also have alt-text.
• The /login page is just sloppy & disorganized compared to the current site.
• The logo on the header tagline turns the mouse into a cursor on mouseover for no reason.
• .card needs its border removed.
• .card, .card-header, and .card-footer need their background-color set to #f0f0f0.
• .description needs set to margin: 0px 15px;.
• The page margins don't line up at all.
• The widget text boxes are not in TWBS form.
• The section headers in /terms are too big compared to the current site.
• The buttons in the Tag Manager are not in TWBS form.

2.x version problems:

• The event accordion has somewhat jerky transitions. Have tried to duplicate, was unable to.
• The event pages in the widgets don't display images. Yes it will, I just have virtually none of the ME images from March 2017 on.
• The "More events?" link in the widgets just stays there for no reason.
• The "Thanks for stopping by" post-logout message is supposed to be a flash message, not just text.

On the icon in the header of http://muncieevents.com/activism, cursor: pointer. Remove a [class^="icon-"]:before, [class*=" icon-"]:before {cursor: pointer;} or give the selector greater specificity if that styling is required elsewhere. Like add 'a' as a required parent.

Steps to duplicate:

1. Load the Feed widget.
2. Click on an event.
3. Click the back button.
4. Click the same event a second time.

I think including an "if" statement to search for a particular class or element would stop this from happening.

It appears that events occurring on the same day are not sorted consistently on /location/foo pages:

Each group of events on the same day should be sorted by their starting time.

Site is currently using Facebook API 2.0 (unversioned calls). All calls to the Facebook API will need to be upgraded to at least 2.1, preferably the most recent version.

• This location page has a "next" pagination link to https://muncieevents.com/location/Minnetrista/page:2,
• Page 2 shows past events, even though it should only be showing future events
• Also, page:2 appears to not be read correctly by the pagination component, as that page has a "next" pagination link to https://muncieevents.com/location/Minnetrista/page%3A2/page:2
• And shows upcoming events
• And that page has a "next" link back to https://muncieevents.com/location/Minnetrista/page:2

So basically, the "next" button just loops the user through the first "upcoming" page and the first "all/past" page.

Spambot-posted events sometimes have spammy custom tags added (if the bot breaks the CAPTCHA challenge and creates an account). These tags have to be deleted as a separate action from deleting the events.

Idea:
When an event is deleted, any of its tags that are not associated with any other event are also deleted.

General error: 1366 Incorrect string value: '\xF0\x9F\x8E\xB5 F...' for column 'title' at row 1
Request URL: /events/add

This was apparently caused by the 🎵 emoji being in an event's title (or possibly an event series's title). The title column is encoded as utf8mb4_unicode_ci in the database, which should support emoji, so I'm not sure why the error is being thrown.

It doesn't seem like folks are actually reading the rules, so I suggest that instead of hiding them behind a link on the event posting page, instead displaying them until a "I have read and understand these rules" link is clicked. That would set a cookie for anonymous users and set a User.read_rules flag for logged-in users that will revert the rules to only appearing when a rules link is clicked on.

The rules could also appear on a separate page that comes before /events/add for users who haven't (confirmably) read them.

Steps to reproduce:

• Submit invalid data (e.g. submit anonymously and don't interact with CAPTCHA challenge)
• data[Event][date] gets submitted as e.g. "04/30/2018" or "04/29/2018,04/30/2018"
• On the next page, the date is not auto-selected, the date cannot be selected, and the calendar jumps to December 2023
  • data[Event][date] and defaultDate are passed to this page as "//04/30/2018" or "//04/29/2018,//04/30/2018"
  • EventsController.php:497 (list($year, $month, $day) = explode('-', $date)) breaks

Each item should include more more than one picture (max dimensions enforced) and an excerpt of the event description.

Hide author email address behind CAPTCHA challenge (a la YouTube) instead of requiring user to be signed in.

The expected <fb> tag in the registration page is no longer appearing.

Here's some new stuff from me, some new stuff from Victoria, and some old stuff from vol. 2 that wasn't taken care of:

• Instead of using .btn-sm for buttons, regular-sized buttons are recommended so users have a full-sized target for clicking. (.btn-sm still in use in around 10 files)

• The text-alignment of ul.event_accordion .actions was changed from right to center

• Some buttons are missing any of the button type classes listed here, resulting in them not having any borders or :hover styles. .btn-default is recommended if the situation doesn't call specifically for one of the other button types.

• On medium screen widths, there's not enough room in #sidebar > .categories for everything to fit on one line. I recommend either increasing the minimum width or making the icons disappear at smaller widths.
  

• On screen widths from 785-1,007, search input field overlaps link
  

A security certificate will be required to avoid users seeing browser-generated warnings about insecure password collection.

• Three location lines (name, details, address) are not lined up
  

• .notification_message class is broken: d9941bc#commitcomment-21313498
  

• Event details have been moved: c733a43#commitcomment-21375061
  

• Buttons have been moved from beside inputs to underneath them, 'add address' needs to stay next to the 'location name' input
  

• Apply Bootstrap styling and responsive design to Customize Event Feed Widget page (/widgets/customize/feed)

• Apply Bootstrap styling and responsive design to Monthly Calendar Widget page (/widgets/customize/month)

• Apply Bootstrap styling and responsive design to Change Password page (/users/change_pass)

Please check these off as they're corrected.