2.17.1

Fix only, in how a pasted booking list is read.

• A line asking for artwork on a show that already exists no longer creates a second show. Add flyer 9-12 Jack the Radio day party and Change 9-25 flyer (change Rodney Henry to Stephen Clair) were read as new events named after the flyer.
• Told apart by what the instruction acts on: the verb taking a flyer as its object, or a change that mentions one at all. A trailing reminder is different — Add Aug 22nd Pickled 8:00-11:00pm and add flyer is still a real new show and still becomes one.
• Lines beneath such an instruction are kept with it rather than listed separately, so an instruction spanning several lines reads as one thing.

Found by running a booking list neither the parser nor its author had seen.

2.17.0

Bulk Add attaches flyers for you.

• Upload the flyer folder to the Media Library and each row is paired with the image whose filename begins with that date, so 8-29.jpg finds the show on the 29th. Both 8-29 and 08-29 are understood.
• Where a night has more than one show, the words after the date settle it: 8-29 Ascension.jpg goes to the Ascension show and the plainly named 8-29.jpeg to the other. Where that leaves exactly one row and one flyer, the last pair is matched by elimination.
• Anything still uncertain is left empty and labelled rather than guessed at. A wrong flyer is worse than none, because nobody checks a thumbnail that is already filled in.
• Matching runs after reading a list, and there is a button to run it again once dates have been corrected or the folder has been uploaded.

2.16.0

Bulk Add — a month of shows in one pass.

• Paste a booking list, upload a CSV, or type rows straight into the table. All three fill the same table, which is also the preview: nothing is written until Create, and every row can be corrected first.
• A pasted list needs no format. The date and the time are found in the line and the rest becomes the title, so commas in a lineup survive. Lines beneath an entry become its description, which is where a festival running order belongs.
• Lines asking for a deletion or a move are set aside and shown rather than acted on. A booking list mixes new shows in with corrections, and a line reading "Delete July 23rd UniS" carries a date and a name — reading every dated line as an addition would create the event the list is asking to be rid of.
• Lines that could not be read are reported rather than dropped, so a real show with a mistyped date cannot go missing quietly.
• Rows the parser had to guess at are flagged with what it assumed. An event whose title and date already exist is skipped, so pressing Create twice does not double the calendar.

2.15.3

• The Description is written for someone deciding whether to install the plugin. It opened with the data model and argued its design decisions, which is the wrong thing for a plugin page to do. It now says what the plugin is, who it suits, and what it does, in about half the length.

2.15.2

Fix only, both in how readme.txt is rendered in the details modal.

• A paragraph that opens in bold was read as a bullet, which swallowed its first asterisk and left the rest of the markup showing in the text. A bullet now requires a space after the asterisk, which is what separates the two.
• Italics render. *like this* reached the page with its asterisks intact.

2.15.1

Documentation, and the details modal that renders it.

• The Description now describes the plugin. It was a technical reference — accurate, but it never said what the plugin is or who it is for, which is the one thing a plugin page has to do.
• That reference material was not thrown away. Setup moved to Installation, the things that surprise people moved to Frequently Asked Questions, and the meta keys, shortcodes, Looper setup and REST notes moved to Reference. All four are tabs in the details modal.
• Fix: numbered steps in readme.txt rendered as one run-on paragraph in the modal, because only "*" bullets were recognised. "1." is a numbered list now.

2.15.0

• "View details" on the Plugins screen opens a real details modal instead of reading "Plugin not found". That link asks the wordpress.org API about the plugin's slug, and a self-hosted plugin is not there, so the request 404s. The plugin now answers for its own slug and leaves every other plugin alone.
• The modal's content is read from readme.txt and the current GitHub release, so it cannot drift from what shipped — the same reason the Changelog screen is rendered from readme.txt rather than a second copy in code.
• "View details" is now present whether or not an update is pending. WordPress only shows the link for a plugin it holds a slug for, and it takes that slug from the update check, so previously the link appeared only while an update was waiting.
• Fix: "Tested up to" was read from the plugin headers, which never carry it — WordPress does not recognise that header, so the value reported alongside an update was always empty. It comes from readme.txt now.

2.14.1

Fix only.

• The event page lays out as intended. On a wide screen the flyer and the details share the top row, with the plain title and then the description full-width beneath them; on a phone the order is flyer, title, description, details, so the visitor reads what the event is before the meta list.
• Source order is the phone order, which is also the order the page reads best in — the heading precedes the content it heads, and the meta list follows the prose rather than interrupting it. The wide screen lifts the details with CSS rather than the markup changing.
• The stacking width and the reordering width are the same number, so there is no band of widths where one has happened and the other has not.

2.14.0

Repeating events now export as repeating events.

• "Download iCal" and "Add to Google Calendar" on a repeating event hand over the series rather than the single night that was clicked, so a weekly night is saved once instead of every week.
• The series is described from the night being viewed forward, never from the series start: no past dates are written into anyone's calendar, and DTSTART is a real instance of the rule as RFC 5545 requires.
• Events with a recurrence rule are described from that rule. Events imported from another calendar carry no rule — their dates came from the source system rather than from a pattern — so the pattern is recovered from the dates themselves: weekly and every-N-weekly, monthly on a date, and monthly on the nth weekday, with skipped nights carried through as exceptions.
• Where no pattern fits, the .ics lists the dates outright rather than inventing a rule, and the Google Calendar link stays a single date. A wrong rule would put nights in a visitor's calendar the venue is not open for.
• The Google Calendar link carries the rule but not the exceptions: its format allows one line and a URL cannot hold a line break, so the .ics is the faithful export of the two.
• A series is identified by the event rather than by the night it was saved from, so saving the same weekly from two different rows updates one entry instead of duplicating every night. Single dates are unchanged.

2.13.2

Fix only.

• On a wide screen an event's details — date, time, category, cover — sat underneath the flyer instead of beside it, leaving the space to the right of the flyer empty. The plain restatement of the title was a fourth block in the same flex row and had to be full-width to read properly, which broke the row and pushed the details below it. The title now opens the details column instead, so it introduces the meta list at every width and the columns pair up as intended. This also retires the last of the ordering rules behind two earlier layout fixes.
• The event page no longer shows a Category row when categories are switched off. It read the terms directly while the calendar honoured the setting, so turning categories off hid them in one place and not the other. Both now use the same check, including the per-event override.