DEV Community: Jeffrey Inman

Fixing "Sign in to confirm you're not a bot" for YouTube transcripts on a server

Jeffrey Inman — Sat, 17 Oct 2026 03:56:08 +0000

Your transcript code works on your laptop. You deploy it to AWS, Vercel, Render, Railway or a VPS, and every video fails with one of these:

ERROR: [youtube] dQw4w9WgXcQ: Sign in to confirm you're not a bot. Use --cookies-from-browser or --cookies for the authentication.
youtube_transcript_api._errors.RequestBlocked / IpBlocked
playabilityStatus: {"status": "LOGIN_REQUIRED", "reason": "Sign in to confirm you're not a bot"}

Nothing is wrong with your code. YouTube decided the request came from a bot because of where it came from.

Why it only happens on servers

YouTube scores each request by its IP address. Home and mobile connections look like people. Cloud and datacenter ranges (AWS, Google Cloud, Azure, Hetzner, DigitalOcean, the functions behind Vercel) look like scrapers, so YouTube asks them to sign in before it serves the player data that captions come from. A few requests a day may get through. Past a few hundred, most won't. That's why it looks random at first and then fails on every video.

Is it the bot check, or is the video really private?

Both come back as LOGIN_REQUIRED, which is what makes this confusing. Check the reason text:

Reason text	What it means	Retry?
Sign in to confirm you're not a bot	Your IP is flagged, the video is fine	Yes, from another IP or client
This video is private / Sign in to confirm your age / members-only	The video really needs an account	No
Video unavailable	Deleted or blocked in your region	No

Checking that string before you retry saves you from burning proxy bandwidth on videos that will never work.

Fixes, from free to paid

1. Update yt-dlp and give it a JavaScript runtime

Recent yt-dlp versions need an external JavaScript runtime to talk to YouTube. Without one, extraction fails in ways that can look like the bot check. Install Node.js or Deno, then:

python -m pip install -U "yt-dlp[default]"
echo '--js-runtimes node' >> ~/.config/yt-dlp/config
yt-dlp --write-subs --write-auto-subs --sub-langs "en.*" --skip-download "https://youtu.be/dQw4w9WgXcQ"

If it was the missing runtime, this fixes it. If it was the IP, it won't.

2. Ask for the player data as a different client

YouTube serves several apps (web, mobile, TV) and doesn't apply the bot check the same way to all of them, so a video blocked for one client often loads for another. In yt-dlp that's --extractor-args "youtube:player_client=...". The yt-dlp wiki lists which clients currently work, and that list changes. For captions, the MIT-licensed yt-transcript-cli does this automatically (Android, then iOS, then web):

npx yt-transcript-cli "https://youtu.be/dQw4w9WgXcQ" --json

It exits with code 2 and BLOCKED when every client is refused, and code 3 when the video simply has no captions, so a script can tell the two apart. On a heavily flagged IP every client can be refused, and then you need a different IP.

3. Cookies from a logged-in account

yt-dlp --cookies cookies.txt --write-auto-subs --skip-download "URL"

This is what the error message suggests, and it works for a while. But cookies expire, every request is tied to a real Google account, and that account can get restricted for automated use. Use a throwaway account, never your main one.

4. Proof-of-origin tokens

yt-dlp supports PO tokens through provider plugins. They can clear the check without cookies, but it's one more moving part that YouTube changes regularly. The yt-dlp wiki's PO Token Guide covers the setup.

5. Residential proxies

Residential proxies make your requests look like home connections. youtube-transcript-api supports them directly:

from youtube_transcript_api import YouTubeTranscriptApi
from youtube_transcript_api.proxies import GenericProxyConfig

ytt = YouTubeTranscriptApi(proxy_config=GenericProxyConfig(
    https_url="http://USER:PASS@your-residential-proxy:PORT"))
transcript = ytt.fetch("dQw4w9WgXcQ", languages=["en"])

There's also a WebshareProxyConfig helper. This is the reliable fix and also the expensive one. One developer who hit the block at a few hundred requests a day reported going through about $200 of residential proxy in a month, and still had to babysit the retry logic.

6. A hosted transcript API

If transcripts are one step in your product rather than the product, it's usually cheaper to call a service that already handles client rotation, residential retries and the reason-string checks. Disclosure: I run two versions of one.

YouTube Transcript Scraper on Apify: $2 per 1,000 transcripts, videos without captions aren't charged, and Apify's free monthly credit covers about 2,500.
YouTube Transcript API on RapidAPI: one GET request returning JSON, plain text or SRT. 100 free requests a month.

curl "https://youtube-transcript-api23.p.rapidapi.com/transcript?url=https://youtu.be/dQw4w9WgXcQ&format=text" \
  -H "x-rapidapi-key: YOUR_RAPIDAPI_KEY" -H "x-rapidapi-host: youtube-transcript-api23.p.rapidapi.com"

Other hosted options exist too. Whichever you pick, check that failed or caption-less videos aren't billed.

Which one to use

Side project, under ~100 videos a day: fixes 1 and 2. Often enough on their own.
Steady volume and you don't mind maintaining it: 2 plus residential proxies.
Transcripts feed an app or an AI agent and you'd rather not maintain scraping: a hosted API.

None of these is permanent. YouTube changes its checks every few weeks, so whatever you pick, make your code tell "blocked, retry later" apart from "this video has no transcript". Then it fails loudly instead of quietly returning nothing.

Live USPS rates after Web Tools: the 60-calls-an-hour limit

Jeffrey Inman — Tue, 29 Sep 2026 20:56:49 +0000

If your WooCommerce shop quotes live USPS rates, the switch from USPS Web Tools to the new USPS APIs changed two things that don't show up until a busy day: how you get keys, and how many times an hour you're allowed to ask for a price. Here's what I found wiring a store to the new API, with real numbers.

Disclosure: I built Beacon Shipping Rates for USPS, a free WooCommerce plugin for this, with a paid add-on. Everything below applies whatever plugin you use.

What changed

USPS retired the old Web Tools APIs on January 25, 2026. Plugins that still called them stopped getting rates that day. The replacement is the USPS APIs at developers.usps.com: OAuth tokens, JSON, and a different set of endpoints for domestic and international prices.

Getting keys is simpler than it used to be. Sign in with your usps.com login, open Apps, add an app, tick Default Access, and copy the Consumer Key and Secret. The secret is shown once. You don't need a shipping account or an EPS account just to quote retail prices.

The part that bites: 60 calls an hour

Each app gets a default quota of 60 calls per hour per API. A checkout that asks USPS for a price every time a customer changes their ZIP or quantity can burn through that in a sale, and after that USPS answers 429 and your checkout shows no USPS options at all.

You can ask USPS for more through the "Email Us" page on the developer portal. Until they say yes, the fix is on your side:

Cache identical packages. Same origin ZIP, destination ZIP, weight and box size means the same price. Round the weight to a tenth of a pound and the dimensions to half an inch and most carts land on a cached answer. USPS prices change a few times a year, so a day is safe.
Count your own calls and stop just under the quota instead of waiting for the 429.
Keep a stale copy for when USPS is down, and serve it rather than nothing.
Have a fallback rate. A flat price is better than an empty shipping list.

What real prices look like

Retail prices from the new API on September 24, 2026, 2 lb in a 10×8×4 box, Beverly Hills (90210) to Manhattan (10001), zone 8:

service	price
USPS Ground Advantage	$19.05
Priority Mail	$21.55
Priority Mail Express	$72.45

A flat $12 shipping charge would have lost $7 on that order and overcharged a local one. That gap is the whole reason to quote live.

Puerto Rico, Alaska, Hawaii and APO/FPO ZIPs all come back as normal domestic rates. Flat-rate envelopes and boxes come back in the same response, but only offer them if the order actually fits the container.

One more change

Address validation moved behind a separate license. Since August 1, 2026, the Addresses API returns 403 unless you apply for it in the business portal (My Account, API Licenses). If a plugin promises address validation on the default keys, it won't work.

If you're on WooCommerce

The official USPS Shipping Method supports the new API from version 5.2.5 and costs $109 a year. Beacon Shipping Rates for USPS is free on wordpress.org and does the caching, quota guard, stale copies and fallback described above, with a setup page that tests your keys and fetches a real rate before you touch a shipping zone.

Whatever you use, turn on debug logging for a day after switching and look for 429s.

Hourly and multi-day rentals on Wix: what Wix Bookings can't do, and your options

Jeffrey Inman — Tue, 29 Sep 2026 17:29:46 +0000

If you rent out kayaks, bikes, boats or golf carts and your site is on Wix, you've probably tried Wix Bookings first. It's free and it's already there. It also wasn't built for rentals, and you can see that on a lot of real booking pages. Here's what goes wrong and what your options are.

Disclosure: I built one of the options below (Beacon Bookings). The rest of the facts come from Wix's own help pages and the App Market, so check them yourself.

What Wix Bookings is built for

Wix Bookings sells appointments, classes and courses. An appointment is a service with a fixed length that one client books. A class has a set time and a number of spots. That's a good fit for a haircut, a yoga class or a guided tour at 10am.

A rental is different. The customer decides how long they want it, often how many of it they want, and the price usually drops for longer rentals. Wix's help center even has a feature request page for "allowing clients to set the duration of a service", which tells you it isn't there.

The workarounds I keep seeing

I went through a few dozen rental businesses' Wix booking pages. The same patterns come up again and again:

A service per length. "Kayak 2 hours", "Kayak 4 hours", "Kayak 8 hours", repeated for every boat. One pontoon company I looked at had two boats times three lengths, so six services for two boats.
A service per group size. "Group of 2", "Group of 3", all the way to "Group of 10", each at a different price.
An "Additional Day" service that the customer is told to book together with the first day.
The deposit as its own service the customer has to remember to add.
Multi-day rentals set up as 15-minute appointments, because an appointment can't span two days.
Two identical boats listed as "Boat A" and "Boat B", because a service can't say "we have two of these".

All of these work, sort of. They also mean the customer does the math, the calendar doesn't know how many you have left, and you check every booking by hand.

Your options

1. Keep Wix Bookings and live with the workarounds. Free, already installed, and fine if you rent one thing for one fixed length.

2. Wix Rentals. Wix now has its own rentals app. It lets customers pick how long, priced per hour or per day, with buffer time between bookings. Two catches from Wix's own overview page: it's "available only on Wix Harmony" (Wix's newest editor), and online reservations need a Business Premium plan. Hourly rentals run from 30 minutes to 24 hours and daily rentals from 1 to 8 days, going by Wix's developer docs. I couldn't find a way to book several of the same item in one booking. If your site is on Harmony, look at it first.

3. An outside booking system. FareHarbor, Peek, Checkfront, Booqable and similar tools are full rental and tour platforms. You link to them or embed them, and the booking and payment happen in their system, not your Wix store. Worth it if you want waivers, check-in, staff scheduling and so on. It's also a second system to pay for and learn.

4. A rental app from the Wix App Market. There are a few. TWICE Rentals is the most established, with a 14-day trial (2.6 stars from 18 reviews when I checked). Mine is below.

What I built: Beacon Bookings

Beacon Bookings is a Wix app that adds a booking form to your site and checks out through your normal Wix checkout. It works in the regular Wix Editor and Wix Studio. What it does for rentals:

Customers pick how long (by the hour, day or night) and how many ("Kayaks: 2").
An hourly rental can run overnight or for days, so one form covers 2 hours, a full day and a week. Pickup and return just have to fall in your open hours.
You set capacity: 6 kayaks means the 7th booking for that time is refused.
Customers can put several items in one order (two kayaks and a paddle board, or a bounce house and 40 chairs) and pay once.
Set prices for longer rentals: "4 hours for $120" or "7 days for $300". The customer is charged whichever works out lower.
A first-hour-plus-extra-hours price works too (a per-booking base price plus an hourly rate).
Buffers, weekly hours and closed dates.
The slot is held while the customer pays, so two people don't grab the last boat.
On the paid plan, a refundable security deposit is added to the checkout as its own line, so you can refund exactly that amount from the order later.
The booking form shows in your site's language (English, Spanish, Portuguese, French or German).

It's free for one rental type. The paid plan is $12 a month for unlimited rental types, resources (rooms, staff, specific boats) and deposits. It doesn't do waivers or add-on items like coolers yet.

It's on the Wix App Market: Beacon Bookings.

How to choose

One item, one fixed length: Wix Bookings is fine.
Your site is on Wix Harmony: try Wix Rentals.
You need waivers, check-in and staff tools: an outside system like FareHarbor or Peek.
You're on the regular Wix Editor and want customers to pick how long and how many, pay through your own checkout, and never overbook: that's the gap Beacon Bookings fills.

Moving off EventON: its timestamps aren't what they look like

Jeffrey Inman — Tue, 29 Sep 2026 01:00:46 +0000

EventON is a popular WordPress events calendar, sold on CodeCanyon, with a free Lite version on wordpress.org. If you're moving off it, or just exporting your events, there's one thing to understand before anything else: the start and end times look like normal unix timestamps, and they aren't. Convert them the obvious way and every event moves by your site's UTC offset.

I read this from EventON Lite 2.5.9, mostly from the function that turns the date fields on the edit screen into stored values. As far as I can tell the paid version uses the same post type and fields, but check a few of your own events against what's below.

Where your events live

Each event is a post of type ajde_events.
The times are in evcal_srow (start) and evcal_erow (end), as unix timestamps.
The event's timezone is in _evo_tz. All-day events have evcal_allday = "yes".
Repeats are in evcal_repeat, evcal_rep_freq, evcal_rep_gap and a few more fields, plus a list called repeat_intervals.
Locations and organizers are the event_location and event_organizer taxonomies.
Event types are event_type, and extra type sets become event_type_2, event_type_3 and so on.
The event colour is evcal_event_color, stored as hex without the #.
Status is _status: scheduled, cancelled, rescheduled, postponed, movedonline, tentative or preliminary. The online link is in _vir_url.

Trap 1: the timestamps are "virtual"

When you save an event for 6:30 pm, EventON builds the timestamp in UTC from the wall-clock time you typed. So evcal_srow is 18:30 UTC, whatever your timezone is. It's the local time pretending to be UTC.

That means this is wrong on any site that isn't on UTC:

// Wrong: shifts the event by the site's offset.
$start = wp_date( 'Y-m-d H:i', (int) get_post_meta( $id, 'evcal_srow', true ) );

and this is right:

// The stored number is wall-clock time encoded as UTC, so read it back as UTC.
$start = gmdate( 'Y-m-d H:i', (int) get_post_meta( $id, 'evcal_srow', true ) );
$zone  = get_post_meta( $id, '_evo_tz', true ) ?: wp_timezone_string();

The same goes for SQL. FROM_UNIXTIME() converts with the session's time zone, so set it to UTC first or you get the shift there too:

SET time_zone = '+00:00';
SELECT p.ID, p.post_title, FROM_UNIXTIME(pm.meta_value) AS starts_local
FROM wp_posts p
JOIN wp_postmeta pm ON pm.post_id = p.ID AND pm.meta_key = 'evcal_srow'
WHERE p.post_type = 'ajde_events'
  AND p.post_status NOT IN ('trash', 'auto-draft')
ORDER BY pm.meta_value;

Trap 2: trust `repeat_intervals`, not the settings

A repeating event stores its settings:

how often: evcal_rep_freq = hourly, daily, weekly, monthly, yearly or custom
the gap
for weekly, the chosen days in evo_rep_WKwk (0 = Sunday)
for monthly, "by weekday" in evo_rep_WK with the week of the month in evo_repeat_wom

It also stores repeat_intervals: every occurrence it generated, as [start, end] pairs of the same virtual timestamps. That list is what the calendar actually shows.

Rebuilding a rule from the settings mostly works, but not always. Custom repeats are only a list, and hourly repeats don't map to most calendar formats. If you rebuild a rule, expand it and compare the dates against repeat_intervals before you trust it. When they don't match, the list is the truth.

Trap 3: location details aren't in term meta

Location and organizer details (address, coordinates, contact) aren't in wp_termmeta. They're in one big serialized option, evo_tax_meta, keyed by taxonomy and term ID:

$meta    = get_option( 'evo_tax_meta', array() );
$address = $meta['event_location'][ $term_id ]['location_address'] ?? '';

Older sites may also have a per-term option named taxonomy_<term id>, which EventON reads as a fallback. Check both.

Trap 4: types come in numbered sets

event_type is the first set of labels; turning on more creates event_type_2, event_type_3, each with its own URL (/event-type_2/<slug>/). Decide where each set goes, and redirect all of them.

URLs

Single events default to /events/<slug>/ (changeable in EventON's settings). Taxonomy pages are /event-location/<slug>/, /event-organizer/<slug>/ and /event-type/<slug>/, and each extra type set gets its own base. Note what yours are before you switch.

Before you switch

Convert one event by hand with gmdate() and compare it with what EventON shows on the front end.
Count repeating events and compare each rebuilt rule with repeat_intervals.
Export evo_tax_meta along with your posts, or your venues lose their addresses.
List every event_type* taxonomy and its URL base.

Disclosure

I build Beacon Events, a free events calendar on wordpress.org. Version 0.12.0 imports from EventON and EventON Lite and handles all four traps: https://wordpress.org/plugins/beacon-events/ . It reads the virtual timestamps correctly, keeps a repeat rule only when it reproduces EventON's stored dates exactly, pulls addresses from evo_tax_meta, turns every type set into categories, and redirects the old location, organizer, type and event links. Custom date lists and hourly repeats come across as their first date, and the import report lists those events so you can check them.

Moving off WP Event Manager: what's in your database and what breaks

Jeffrey Inman — Tue, 29 Sep 2026 00:53:20 +0000

WP Event Manager is on about 20,000 sites. The core plugin is free; recurring events, ticket sales and registrations are paid add-ons. If you're leaving it, or just want your events out in a form another tool can read, here's how it stores them. I read this from version 3.4.1, mostly the code that saves an event from the admin screen and the front-end form.

Where your events live

Each event is a post of type event_listing. The title, description and featured image are where you'd expect.
Dates: _event_start_date and _event_end_date hold the date and time together in local time (2026-10-17 10:00:00). Use those rather than the separate time fields.
_event_timezone: the event's own zone (see trap 4 before you use it).
_event_online: "yes" or "no".
The address: _event_location, _event_pincode and _event_country, stored on the event itself.
Venues and organizers are their own post types, event_venue and event_organizer. Events point at them by ID in _event_venue_ids and _event_organizer_ids.
Categories are the event_listing_category taxonomy. Event types are a second taxonomy, event_listing_type.
The banner image URL is in _event_banner. The ticket choice and price are in _event_ticket_options and _event_ticket_price.

The traps

1. The address belongs to the event, not the venue. A venue post has a name, a description and some links, but no address. Two events at "The Loft" can carry two different addresses. If you migrate venues on their own you lose every address; build each venue's address from its events instead.

2. Dates are usually Y-m-d H:i:s, but not always. When the plugin can't parse a date on save it stores what was typed instead, in your site's date format. Check for those rows before you trust a straight copy:

SELECT p.ID, p.post_title, pm.meta_value AS start_date
FROM wp_posts p
JOIN wp_postmeta pm ON pm.post_id = p.ID AND pm.meta_key = '_event_start_date'
WHERE p.post_type = 'event_listing'
  AND p.post_status NOT IN ('trash', 'auto-draft')
  AND pm.meta_value NOT REGEXP '^[0-9]{4}-[0-9]{2}-[0-9]{2}';

3. Past events have their own status. Once an event is over it becomes expired, a post status the plugin registers itself. Deactivate the plugin and WordPress no longer knows that status, so the admin screens and anything built on WP_Query stop seeing those posts, even though they're still in the table. Query wp_posts directly, or export before you deactivate.

4. _event_timezone doesn't always mean anything. The plugin only uses it when its timezone setting (event_manager_timezone_setting) is each_event. On the default, site_timezone, events show in the site's zone whatever that field says. So check the option before you apply the field, or a leftover value will move events by hours.

5. The ID fields change shape. _event_organizer_ids can be an array, a single number, or a comma-separated string, depending on how the event was saved. _event_venue_ids is usually one ID. Normalise them before you look anything up:

function wpem_ids( $value ): array {
    $list = is_array( $value ) ? $value : preg_split( '/\s*,\s*/', (string) $value );
    return array_values( array_filter( array_map( 'intval', (array) $list ) ) );
}

6. Event types are a second set of labels. They're separate from categories, with their own /event-type/<slug>/ pages. Decide whether they become categories or tags in the new system, and redirect those URLs to match.

7. Add-ons keep their own data. Ticket sales and registrations from the paid add-ons don't live on the event post. Migrate or archive them separately.

URLs

The defaults are /event/<slug>/, /event-category/<slug>/, /event-type/<slug>/, and the /events/ archive. All three bases can be changed under the plugin's permalink settings, so check yours before you plan redirects.

Before you switch

Run the date query above and fix any rows it returns.
Check event_manager_timezone_setting.
Export while the plugin is still active, or read the table directly, so expired events come along.
Write down your three URL bases.
Decide where event types go.

Disclosure

I build Beacon Events, a free events calendar on wordpress.org, and its importer handles all of this as of 0.11.1: https://wordpress.org/plugins/beacon-events/ . It builds venues with the address from their events, brings expired events across as past events, follows the timezone setting, and turns event types into categories with their /event-type/ links redirected. Its /event/ and /event-category/ URLs are the same as the plugin's defaults, so most links keep working. It doesn't import ticket sales or registrations from the paid add-ons.

Moving off Modern Events Calendar: what's in your database and what breaks

Jeffrey Inman — Tue, 29 Sep 2026 00:43:09 +0000

Modern Events Calendar Lite was closed on wordpress.org on May 11, 2022, permanently, for a guideline violation (that's what its plugin page still says). Plenty of sites still run it, updated from the developer's own site. Whether you're moving to something else or just want your events out, it helps to know how MEC stores them, because a few of its choices will quietly give you the wrong dates if you copy fields as they look.

I read all of this from MEC Lite 6.5.6, the last version on wordpress.org, mostly from the function that saves an event. Newer builds still have to read events saved by older ones, so the stored format should be the same, but check your own data with the queries below before you trust any of it.

Where your events live

Each event is a post of type mec-events: title, content, excerpt, featured image.
The schedule is in post meta:
- mec_start_date / mec_end_date (Y-m-d)
- mec_start_day_seconds / mec_end_day_seconds (seconds after midnight)
- mec_allday
- mec_timezone ("global" means the site's timezone)
- the repeat settings in mec_repeat_*
There are two tables, wp_mec_events and wp_mec_dates. MEC fills them from the meta when an event is saved and uses them for its calendar queries. Read the meta; treat the tables as derived.
Venues, organizers and categories are taxonomies:
- mec_location: address, latitude and longitude in term meta.
- mec_organizer: tel, email and url in term meta.
- mec_category: the colour is in mec_cat_color.
Bookings, if you used them, are separate: mec-books posts plus a wp_mec_bookings table.

To see which repeat types you actually have (and so which of the traps below apply to you):

SELECT pm.meta_value AS repeat_type, COUNT(*) AS events
FROM wp_postmeta pm
JOIN wp_posts p ON p.ID = pm.post_id
WHERE pm.meta_key = 'mec_repeat_type'
  AND p.post_type = 'mec-events'
  AND p.post_status NOT IN ('trash', 'auto-draft')
GROUP BY pm.meta_value;

An empty repeat_type means the event doesn't repeat.

The traps

1. Weekly intervals are stored in days. "Every 2 weeks" is saved as mec_repeat_interval = 14. MEC multiplies the week count by 7 before saving. Copy it straight into an RRULE and you get INTERVAL=14, which is every fourteen weeks.

2. "Ends after N times" is stored as N − 1. mec_repeat_end_at_occurrences holds one less than what the user typed. Six classes becomes 5 in the database.

$type     = get_post_meta( $id, 'mec_repeat_type', true );
$interval = max( 1, (int) get_post_meta( $id, 'mec_repeat_interval', true ) );
if ( 'weekly' === $type ) {
    $interval = max( 1, intdiv( $interval, 7 ) );
}
$count = null;
if ( 'occurrences' === get_post_meta( $id, 'mec_repeat_end', true ) ) {
    $count = (int) get_post_meta( $id, 'mec_repeat_end_at_occurrences', true ) + 1;
}

3. Weekday numbers are ISO. mec_certain_weekdays uses 1 = Monday through 7 = Sunday, not the 0 = Sunday you'd get from PHP's w or JavaScript. The "weekday" and "weekend" repeat types don't store their days on the event at all. They come from MEC's settings (mec_options → settings → weekdays / weekends), which default to 1–5 and 6–7.

4. "Advanced" repeats are little tokens. mec_advanced_days holds values like Sun.1 (first Sunday of the month) or Fri.l (last Friday). That's a monthly rule by position, BYDAY=1SU or BYDAY=-1FR. One event can hold several tokens, so check for that before you assume one rule per event.

5. Location or organizer ID 1 means "hide it". It isn't a venue. If you import it as one you'll end up with a venue called whatever term 1 is on your site.

6. Times are stored three ways. There are 12-hour fields (mec_start_time_hour, _minutes, _ampm), a seconds-after-midnight field, and a datetime string. On sites set to 24-hour time MEC converts the hour back to 12-hour before saving it. Use mec_start_day_seconds / mec_end_day_seconds and skip the hour fields.

7. Extra and skipped days. Skipped dates are a comma list in mec_not_in_days. The "custom days" repeat type keeps its own list in mec_in_days as start:end pairs (2026-10-17:2026-10-17), sometimes with times appended as hh-mm-AM. There's no rule behind those, just the list.

8. Your URLs may not be the defaults. Single events live at /events/<slug>/ and categories at /mec-category/<slug>/ unless someone changed them under MEC's settings (slug and category_slug in the same mec_options array). Read those two values before you switch, or your redirects will only cover URLs your site never used.

Before you switch

Run the query above and note which repeat types you have.
Spot-check one weekly event and one "ends after N times" event by hand against MEC's own calendar.
Write down your two URL slugs.
Decide what happens to bookings. They're in their own post type and table, not on the events.
Keep MEC installed but deactivated until you've compared a month of dates side by side.

Disclosure

I build Beacon Events, a free events calendar on wordpress.org, and version 0.10.1 has an importer for exactly this: https://wordpress.org/plugins/beacon-events/ . It handles the traps above, keeps venues with their addresses, organizers, category colours, images and timezones, and redirects old event and category links, custom slugs included, once MEC is off. What it doesn't do: a "custom days" list comes in as its first date, an advanced rule with several weekdays keeps the first one, and MEC bookings aren't imported. The report after the import lists the events that hit one of those.

QR ticket check-in for a WordPress event, without a scanner app

Jeffrey Inman — Mon, 28 Sep 2026 21:00:05 +0000

Most small events check people in off a printed list. It works until the line gets long and two volunteers are flipping through the same three pages looking for "Maria". The usual upgrade is a scanner app, which means everyone at the door installs something and logs into it.

There's a simpler version. Every phone camera already reads QR codes and opens whatever URL is inside. So the QR on a ticket can just be a link to your own site, and "checking someone in" is that page loading on a volunteer's phone.

I built this for a WordPress events plugin this week and a few of the decisions weren't obvious, so here they are. The snippets are plain PHP against WordPress APIs; adapt the table and names to whatever stores your bookings.

Don't put the booking link in the QR

Most booking systems email a private link that lets the guest see or cancel their booking. It's tempting to reuse it in the QR. Don't: people post photos of their tickets, and anyone who scans that photo gets the guest's cancel link.

Put a separate code in the QR that can only do one thing, check in. I derive it from the booking id and the booking's secret token with an HMAC, so it can't be guessed and doesn't reveal the token:

function checkin_code( array $booking ): string {
    $mac = hash_hmac( 'sha256', 'checkin|' . (int) $booking['id'] . '|' . $booking['token'], wp_salt( 'auth' ) );
    return (int) $booking['id'] . '-' . substr( $mac, 0, 24 ); // 96 bits is plenty for this
}

function booking_by_code( string $code ): ?array {
    if ( ! preg_match( '/^(\d+)-([a-f0-9]{24})$/', $code, $m ) ) {
        return null;
    }
    $row = get_booking( (int) $m[1] ); // your lookup
    return ( $row && hash_equals( checkin_code( $row ), $code ) ) ? $row : null;
}

hash_equals rather than === so the comparison takes the same time whether the first character or the last one is wrong. The checkin| prefix keeps this MAC separate from anything else you sign with the same salt.

The QR then holds https://example.com/?checkin=42-3f9c….

Only staff phones can check people in

The check-in URL does nothing for a logged-out visitor except send them to the login page and back:

if ( ! is_user_logged_in() ) {
    wp_safe_redirect( wp_login_url( $checkin_url ) );
    exit;
}
if ( ! current_user_can( 'edit_others_posts' ) ) {
    // "This account cannot check people in."
}

Each volunteer logs in once on their phone before doors open. After that, scan, see the result, next person.

A side effect I like: link previewers, email security scanners and chat apps that fetch URLs do it without your cookies, so a ticket pasted into Slack or forwarded to someone can't check anyone in.

Yes, a GET request changes state

Normally you don't let a GET change anything. Here the phone camera opens the link, so a GET is what you get, and putting a "Confirm" button on the page costs a tap per guest at the busiest moment of the night.

I kept the GET and leaned on two things: the capability check above, and the fact that check-in is a one-way stamp. Loading the page twice doesn't do anything the first load didn't. If your check-in does more (charges something, issues a wristband number), use a POST with a nonce and accept the extra tap.

Two phones, one ticket

This is the bug I actually shipped. My first version did the obvious thing: read the booking, see checked_in is empty, write the time. If two volunteers scan the same ticket at the same moment (a couple sharing one ticket, say), both requests read "not checked in" and both phones go green.

The fix is to make the write itself the check:

global $wpdb;
$n = $wpdb->query( $wpdb->prepare(
    'UPDATE %i SET checked_in = %s WHERE id = %d AND checked_in IS NULL',
    $table, gmdate( 'Y-m-d H:i:s' ), (int) $booking['id']
) );
$result = ( 1 === (int) $n ) ? 'ok' : 'already';

The database only lets one of those updates match the row, so exactly one phone gets "ok". The other re-reads the row and shows "Already checked in at 7:42 pm", which is the information the volunteer actually needs. (%i for identifiers needs WordPress 6.2+.)

I wrote a test that loads the same row twice and checks it in with both copies. It failed on the old code and passes on the new one.

Screens you can read at arm's length

Doors are dark and people are impatient, so the result page is one word on a colored background:

green "Checked in", with the name, party size and ticket type
amber "Already checked in at 7:42 pm"
red for cancelled, unpaid, waitlisted, or a code that doesn't match anything

Send noindex and no-cache headers on both the ticket page and the check-in page. Neither should ever end up in a search index or a shared cache.

Draw the QR in the browser

Don't send the ticket URL to a third-party "QR image" API to get a PNG back. That URL is a credential, and you'd be handing it to someone else's logs. A small MIT library like qrcode-generator draws it client-side as an SVG:

var q = qrcode(0, 'M');           // auto size, medium error correction
q.addData(checkinUrl);
q.make();
document.getElementById('ticket-qr').innerHTML =
    q.createSvgTag({ cellSize: 6, margin: 2, scalable: true });

SVG stays sharp at any screen size. I checked the output by decoding a screenshot of the ticket page with jsQR; it came back as the exact check-in URL.

What this doesn't handle

It needs a data connection at the door. If your venue is a basement with no signal, keep a printed door list as the fallback, with a box to tick per person. And it's one check-in per booking: a booking for four people is one scan, and the screen says "× 4" so the volunteer knows to wave the whole group through.

Disclosure

I built this for Beacon Events Pro, the paid add-on to Beacon Events, a free events calendar on wordpress.org. The QR tickets, check-in screens and door list are in the add-on. Everything above works the same in your own code if you'd rather build it yourself.

What WooCommerce Bookings really costs a small rental shop, and the free options

Jeffrey Inman — Mon, 28 Sep 2026 15:20:00 +0000

If you rent kayaks, cabins or bikes, or run tours or classes, and your shop is on WooCommerce, the default answer for taking bookings is the official WooCommerce Bookings extension. Here's what that costs a small shop over a year, what you actually need, and the free options.

Disclosure: I built Beacon Bookings, a free WooCommerce bookings plugin with a paid add-on. The prices below come from the vendors' own pages, so check them yourself.

What the official route costs

From woocommerce.com (September 2026):

WooCommerce Bookings: $249 a year.
Deposits aren't included. A reviewer on that page notes you pay "an extra $182 for the WooCommerce deposits plugin".
"WooCommerce Bookings Availability", the add-on that shows customers a calendar of what's free, is $59.

That's $490 a year if you want deposits and a customer-facing calendar. The Bookings extension is rated 2.7 stars on its own store page, and half of its 60 reviews are one or two stars.

What a rental or tour shop actually needs

Most small shops need the same short list:

Units that match the business. Hours for kayaks, nights for cabins, a fixed 2-hour slot for a tour.
Capacity. You have 6 kayaks, not 1. A tour takes 12 people, not 12 separate bookings.
People counts. "4 people" should use 4 seats, and sometimes multiply the price.
Buffers. Cleaning time between cabin stays, drive time between lessons.
No double bookings. The slot is checked when the customer picks it, held while it's in the cart, and checked again at checkout.
Your own calendar. An .ics feed you can subscribe to from Google or Apple Calendar is enough for most people.
Deposits, if you take them.

Numbers 1 to 6 are the core. Only 7 is really "extra".

The free options

On wordpress.org there are good free booking plugins, but most are appointment schedulers (LatePoint, Simply Schedule Appointments, Amelia's free tier). They're built around staff and time slots and run their own checkout. If you want bookings to be WooCommerce products, sold through the normal cart next to your other products, the list is short:

Easy Booking: date-range bookings for WooCommerce. Good for simple rentals.
Booking Activities: strong for classes and events with fixed sessions.
Beacon Bookings (mine): a bookable product type with minutes to nights, capacity per slot or per resource (rooms, staff, boats), people counts, buffers, cart holds with a locked re-check at checkout, emails with calendar files, calendar feeds, and a calendar block. Deposits, seasonal pricing and Google Calendar sync are in a paid add-on.

How to choose

Fixed class times with a seat limit: try Booking Activities first.
Simple "from date, to date" rentals: Easy Booking is enough.
Mixed inventory (6 kayaks and 2 guides, cabins with cleaning days, people-based pricing): you need capacity, resources and buffers together. That's what I built Beacon Bookings for.
Already paying for WooCommerce Bookings and it works for you: there's no reason to move.

Whatever you pick, test one thing before going live. Open two browsers, put the last slot in both carts, and check out in both. Only one should succeed.

Beacon Bookings on wordpress.org: https://wordpress.org/plugins/beacon-bookings/

A church calendar on WordPress that volunteers can keep up

Jeffrey Inman — Mon, 28 Sep 2026 00:55:16 +0000

Most church websites need the same calendar: a weekly service, a few monthly groups, special services around the holidays, and the occasional potluck or retreat people sign up for. Here's how to set that up in WordPress so volunteers can keep it current, and what to check in whatever plugin you use.

Disclosure: I build Beacon Events, a WordPress events plugin. The setup below works in most calendar plugins; where it depends on one, I say so.

Enter the rhythm once

Weekly service as one repeating event. Sunday 10am, every week, no end date. You should never have to copy it forward by hand.
Monthly groups by position, not date. "Second Tuesday" for the women's group, "last Friday" for youth night. Check that your plugin can repeat by weekday position; some only repeat on the same date each month.
Special services as single events. Christmas Eve, Good Friday and Easter each get their own event, so the weekly service doesn't have to bend around them.

Handle the week plans change

The service that moves to the park for a picnic, the Wednesday study cancelled for Thanksgiving: you want to change one date without breaking the series. Look for a way to cancel or move a single occurrence that shows visitors "cancelled" or the new time, rather than deleting the whole event.

Let members take it with them

A subscribe link. Most calendar plugins publish an iCal feed. Put the link on the page so members can add the whole calendar to their phone, and changes show up there on their own.
Colours per ministry. Worship, youth, outreach: a colour per category makes a month view readable at a glance.
The address and a map link on every event, and a join link for anything you livestream.

If your office already lives in Google Calendar

Many church offices keep the master calendar in Google Calendar. Instead of embedding Google's iframe, which doesn't match the site and doesn't resize well on phones, sync the calendar's feed into your events plugin so each event becomes a real page on your site. I wrote up what to check for in that sync here.

Sign-ups

For potlucks, retreats and classes where you need a headcount, look for RSVPs with a capacity and a waitlist, so you're not collecting names in a spreadsheet.

If you want to try Beacon Events

Beacon Events is free on wordpress.org. It covers the rhythm above without paid add-ons:

repeating events, including "second Tuesday" and "last Friday";
cancelling or moving one date, which then shows as cancelled or rescheduled;
a subscribe link, category colours, and addresses with a map link;
online events with a join link;
Google Calendar sync with a log of each run.

RSVPs with a capacity, a waitlist and reminder emails are in the paid add-on, which has a 14-day trial with no card.

https://wordpress.org/plugins/beacon-events/

If your church calendar has a pattern this doesn't cover, post it in the comments.

Moving off Events Manager: what's in your database and what breaks

Jeffrey Inman — Sun, 27 Sep 2026 23:55:27 +0000

Events Manager is one of the oldest event plugins on WordPress, and it stores events differently from most. If you're moving off it, here's what's in your database, where migrations usually break, and a checklist to run before you switch.

Disclosure: I build Beacon Events, a WordPress events plugin with an Events Manager importer. The details below apply whatever you move to.

How Events Manager stores events

Events live in their own table, not just in posts. Each event is a post of type event plus a row in wp_em_events with the dates, times, timezone and a link to its location. The row holds the real schedule, so read the table rather than the post meta.
Locations are separate records in wp_em_locations, with the address split into fields (address, town, state, postcode, country).
A repeating event is a template plus copies. Events Manager keeps one "repeating" event that holds the rule, then creates a separate event for every date it produces. Depending on the version, the rule sits on the template itself (older versions) or in its own recurrences table (newer ones), where it can also include or exclude sets of dates.

Where migrations go wrong

Every date becomes its own event. Importing the generated copies turns a weekly class into 52 unrelated events. Take the template and its rule instead, and skip the copies.
Excluded dates come back. When a repeating event has dates excluded, those need to arrive as skipped dates on the new rule, or the cancelled week reappears.
"Specific dates" events don't fit a rule. Events Manager can repeat on a hand-picked list of dates. Most rule-based calendars can't express that, so check what your importer does with them. The honest answer is usually to keep the first date and tell you about the rest.
Old links break. Events Manager leaves placeholder pages called "events" and "locations" behind, and your old event and location URLs point at them. Without redirects, search traffic and shared links go to empty pages.
Bookings are a separate job. Events Manager has its own bookings system. Moving the events doesn't move the people who booked them, so export your booking lists first.

A checklist that holds up

Back up the database, including the wp_em_ tables.
Count your published events, and note which ones repeat.
Export your current bookings from Events Manager and keep the file.
Run the import with Events Manager still active, then check one repeating event with an excluded date and one event on specific dates.
Click a few old event and location links after you deactivate Events Manager.

If you want to try Beacon Events

Beacon Events is free on wordpress.org, and its Events Manager importer does the above. Each repeating event comes across as one event with its rule and excluded dates. Locations become venues with their full address, and categories keep their nesting. Old /events/… and /locations/… links redirect once Events Manager is switched off. "Specific dates" events keep their first date and are listed in the import report, and Events Manager bookings aren't imported. Recurring events, Google Calendar sync and month, list and day views are free. RSVPs and tickets are in a paid add-on.

https://wordpress.org/plugins/beacon-events/

If your Events Manager setup has something this misses, say so in the comments and I'll look at it.

Show a Google Calendar on WordPress without the iframe

Jeffrey Inman — Sun, 27 Sep 2026 22:01:58 +0000

A lot of club, church and studio websites show their events with Google Calendar's embed code. It works, and it's free, but it's also why the events page looks like a different website. Here's what the embed gives you, the other way to put a Google Calendar on a WordPress site, and what to check before you trust a plugin with it.

Disclosure: I build Beacon Events, a WordPress events plugin that syncs calendar feeds. The checklist below applies to whatever you use.

What the embed gives you

Google's embed code is an iframe with a fixed width and height (its customize page asks for at least 500 by 500). Inside it, everything is Google's page:

It doesn't fit. A fixed-size box needs extra CSS before it behaves on a phone.
It doesn't match. You can pick colours and hide a few tabs, but not your theme's fonts or layout.
Your site gets nothing for search. The events live on Google's page, so your site has no page per event and no Event markup for search results.

The other way: sync the feed

Every Google Calendar has an iCal (ICS) address. A plugin can read that address on a schedule and turn each event into a real post on your site. You keep editing in Google Calendar, as you do now, and the website follows.

To get the address: open Google Calendar on a computer, go to Settings, click your calendar on the left, and click "Integrate calendar". The "Public address in iCal format" only works if the calendar is shared publicly ("Make available to public" under access permissions). If you'd rather not make it public, the "Secret address in iCal format" works too. Treat it like a password: anyone who has it can read the whole calendar.

What to check in a plugin that syncs

Google's feed has a few habits that trip up sync code. Try these with a test calendar before you point a plugin at the real one.

A repeating event stays one event. A weekly service should arrive as one event with a rule, not 52 separate posts.
One changed date doesn't break the series. When you move or cancel a single date of a repeating event, Google sends that date as a separate entry with the same ID as the series. Sync code that matches on the ID alone overwrites the whole series with that one date.
Old series still show upcoming dates. A weekly event that started years ago should still show next week. Some plugins only work out dates for a fixed period from the first one.
Skipped dates all stay skipped. Google writes one line per skipped date. Code that keeps only the last one brings the others back.
Evening events land on the right day. Some feeds write times in UTC, where 7:30 pm in Chicago is already Wednesday. The weekday has to be moved back.
Deleted events are handled in a way you can live with. Removed from the site, hidden, or kept: know which before it happens to a real event.
You know how often it syncs. WordPress's scheduled tasks run when someone visits the site, so an "hourly" sync on a quiet site can run late unless the host runs a real cron job.

One more thing that's true of any sync: edits you make on the WordPress side get overwritten on the next run, because the feed is the source. Change events in Google Calendar, not in WordPress.

If you want to try Beacon Events

The calendar is free on wordpress.org. Paste the feed address under Events → Settings, optionally followed by a category, and it syncs hourly with a log of what was created, updated or removed each time. A repeating event stays one event, and a moved or cancelled date shows as moved or cancelled on the series. Events that disappear from the feed become drafts rather than being deleted. It shows month, list and day views as blocks or shortcodes in your theme's fonts, and every event gets its own page with Event markup for search.

https://wordpress.org/plugins/beacon-events/

If your calendar does something odd in any plugin, describe it in the comments and I'll look at the feed.

Moving off Event Tickets Plus: what your WooCommerce ticket data looks like

Jeffrey Inman — Sun, 27 Sep 2026 19:22:35 +0000

Event Tickets Plus sells your event tickets through WooCommerce. If you're moving off it, whether because of the Liquid Web changes or because you're leaving The Events Calendar altogether, the tickets and attendees are the part that's easy to get wrong. Here's what that data looks like in your database and where a migration usually breaks.

Disclosure: I build Beacon Events, a WordPress events plugin, and I wrote an importer for this data this week. The details below apply whatever you move to.

What's in your database

The field names below come from the free Event Tickets plugin's own code, which maps every ticket provider it supports.

Each ticket is a WooCommerce product. It carries _tribe_wooticket_for_event with the event's post ID, and _tribe_ticket_capacity with the ticket's capacity (-1 means unlimited). The price is the product's price.
Each attendee is a tribe_wooticket post, one per ticket sold, so an order for three tickets makes three attendees. It points back with _tribe_wooticket_event (the event), _tribe_wooticket_product (which ticket), _tribe_wooticket_order (the WooCommerce order) and _tribe_wooticket_order_item (the line in that order). _paid_price holds what was paid.
Whether someone actually paid lives in WooCommerce, in the order's status, not in the attendee record.

Where migrations go wrong

Unpaid orders become attendees. Orders that are pending or on hold still have attendee posts. Only completed and processing orders are paid, so leave the rest out, and drop refunded, cancelled and failed ones too.
Newer stores keep orders out of wp_posts. With WooCommerce's High-Performance Order Storage (HPOS), orders live in their own wc_orders table. A query that joins attendees to shop_order posts finds nothing on those sites. Ask WooCommerce for the order (wc_get_order()) instead, which works either way.
The buyer isn't always the guest. One person can buy tickets for three people. Use the name and email stored on each attendee first, and fall back to the order's billing details only when those are empty.
Ticket types collapse into one price. An event with early bird, general and VIP tickets is three products. If your new plugin only has one price per event, you lose that, and your existing attendees lose the record of what they bought.
The import sends emails. A migration shouldn't send everyone a fresh confirmation. Check that the importer is silent before you run it on real data.

A checklist that holds up

Back up the database, including the WooCommerce order tables.
Count your paid attendees in WooCommerce before you start, so you have a number to compare against.
Run the import with Event Tickets Plus still active, and check one event with several ticket types and one order that was refunded.
Make sure capacity still counts the people you imported, so nobody can buy a seat that's already taken.
Only then switch the old plugins off.

If you want to try Beacon Events

The calendar is free on wordpress.org. Its paid add-on, Beacon Events Pro, imports Event Tickets Plus data when you move from The Events Calendar. That covers each ticket as its own ticket type with its price and capacity, and every attendee of a completed or processing order under their own name, with the WooCommerce order linked. Unpaid orders are listed in the report, and no emails go out. New tickets then sell through your WooCommerce checkout or your own Stripe account with no per-ticket fee from us. It also has check-in at the door and a printable door list. It's $49 a year for one site, with a 14-day free trial that needs no card.

https://wordpress.org/plugins/beacon-events/

If your Tickets Plus setup has something this doesn't cover, say so in the comments and I'll look at it.

DEV Community: Jeffrey Inman

Fixing "Sign in to confirm you're not a bot" for YouTube transcripts on a server

Why it only happens on servers

Is it the bot check, or is the video really private?

Fixes, from free to paid

1. Update yt-dlp and give it a JavaScript runtime

2. Ask for the player data as a different client

3. Cookies from a logged-in account

4. Proof-of-origin tokens

5. Residential proxies

6. A hosted transcript API

Which one to use

Live USPS rates after Web Tools: the 60-calls-an-hour limit

What changed

The part that bites: 60 calls an hour

What real prices look like

One more change

If you're on WooCommerce

Hourly and multi-day rentals on Wix: what Wix Bookings can't do, and your options

What Wix Bookings is built for

The workarounds I keep seeing

Your options

What I built: Beacon Bookings

How to choose

Moving off EventON: its timestamps aren't what they look like

Where your events live

Trap 1: the timestamps are "virtual"

Trap 2: trust repeat_intervals, not the settings

Trap 3: location details aren't in term meta

Trap 4: types come in numbered sets

URLs

Before you switch

Disclosure

Moving off WP Event Manager: what's in your database and what breaks

Where your events live

The traps

URLs

Before you switch

Disclosure

Moving off Modern Events Calendar: what's in your database and what breaks

Where your events live

The traps

Before you switch

Disclosure

QR ticket check-in for a WordPress event, without a scanner app

Don't put the booking link in the QR

Only staff phones can check people in

Yes, a GET request changes state

Two phones, one ticket

Screens you can read at arm's length

Draw the QR in the browser

What this doesn't handle

Disclosure

What WooCommerce Bookings really costs a small rental shop, and the free options

What the official route costs

What a rental or tour shop actually needs

The free options

How to choose

A church calendar on WordPress that volunteers can keep up

Enter the rhythm once

Handle the week plans change

Let members take it with them

If your office already lives in Google Calendar

Sign-ups

If you want to try Beacon Events

Moving off Events Manager: what's in your database and what breaks

How Events Manager stores events

Where migrations go wrong

A checklist that holds up

If you want to try Beacon Events

Show a Google Calendar on WordPress without the iframe

What the embed gives you

The other way: sync the feed

What to check in a plugin that syncs

If you want to try Beacon Events

Moving off Event Tickets Plus: what your WooCommerce ticket data looks like

What's in your database

Where migrations go wrong

A checklist that holds up

If you want to try Beacon Events

Trap 2: trust `repeat_intervals`, not the settings