How to Customize Series and Issues in PublishPress Series  🔗 **Source:** [How to Customize Series and Issues in PublishPress Series](https://www.youtube.com/watch?v=B-Aa0oDD_p8) > [!note]+ Document Notes > tags: [wordpress-plugins, design-customization, serial-content, front-end-styling, editorial-tooling] > author: Steve Burge > source: PublishPress (YouTube) > reference: https://www.youtube.com/watch?v=B-Aa0oDD_p8 > date created: 2026-08-22 10:50 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: How to Customize Series and Issues in PublishPress Series > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [PublishPress Series on WordPress.org](https://wordpress.org/plugins/organize-series/) - [PublishPress Series Pro](https://publishpress.com/series/) - [Companion video — How to Organize Your WordPress Posts into Issues or Series](https://www.youtube.com/watch?v=A2_YA88qo84) ## 📝 Summary - **What happened.** A seven-minute follow-up to the PublishPress Series overview, focused entirely on styling. Steve walks through the three front-end regions the plugin injects — the post list box, the one-line post details statement, and previous/next navigation — and shows the settings screens that restyle each one. - **Why it matters.** This is the moment a content-modeling plugin becomes a design surface. The plugin injects markup into the front end, and rather than expecting theme authors to style it, it ships its own live-preview settings UI with per-element color, size, and layout controls. That decision has real consequences for design consistency and accessibility that the video does not examine. - **Key stakeholders.** Site owners without a developer; theme authors whose design tokens are now being bypassed; accessibility reviewers, because arbitrary color pickers with no contrast feedback are a recurring failure source; PublishPress, which gates layout controls behind the pro tier. - **Risks and tradeoffs.** The customization UI lets a user pick any background and text color with no contrast warning shown at any point — the demo itself produces purple-on-white and white-on-purple combinations by eye. Styling in plugin settings rather than theme CSS also means the design drifts from the theme's tokens and does not follow a theme switch. - **Bottom line.** Competent, genuinely flexible styling controls that solve a real problem for non-developers, undermined by the absence of any contrast guidance. The free tier covers appearance; layout and ordering controls are pro. Treat the color pickers as an accessibility review item, not a convenience. ## 📖 Main Content The video's implicit argument is that a plugin injecting front-end output owes the user a way to control how it looks. Steve makes this concrete by naming the three regions produced by the previous video's setup: a single line reading "this entry is part X of X in the series," a table-of-contents box listing every post in the series, and a previous/next navigation box. Each has its own settings screen, and each screen carries a live preview above the controls — change a value, see it immediately. The **post list boxes** screen is the deepest of the three. Its controls are grouped into tabs. The first governs the box itself: whether to show the series title, the title's color and font size, and the box background color. Steve demonstrates by unchecking the title and watching "Lord of the Rings" disappear, then setting the box background to PublishPress purple — and immediately noticing the title color now needs to change to white to stay readable. That sequence is worth pausing on. It is a manual, by-eye contrast correction, performed because the result looked wrong, with no tooling involvement. A user with less design instinct would ship the unreadable version. A second tab controls individual post appearance within the box: title size, whether to show the featured image, and the image's width and height. Steve raises title size from 16 to 26, then adjusts the image height to 160 because movie posters are not square. This is the most practically useful segment — series content frequently uses non-square imagery, and a fixed square thumbnail would distort it. A third tab, **layout**, is explicitly gated: column count, post ordering, and whether the box renders above or below the post content are pro-version features. This is a clean articulation of the free/pro boundary — appearance is free, structure costs money. The **post details** screen is deliberately simpler, with only general and styling tabs. Its most interesting control is textual rather than visual: the "part X of X in the series" string is editable, so a film site can say "movie" instead of "entry." That is a small feature with outsized value, and it is also the place where localization problems will surface, since the string's grammar is being hand-edited per site. The **post navigation** screen offers three presets: the default, a simple previous/next button pair, and a variant with thumbnail images inside the buttons. Alongside these, both the post list and post details screens ship several pre-built example layouts — a gray variant, a dark variant, a grid style — selectable from the settings area. Terms the video leaves undefined: none of this is block-based or theme.json-aware. The styling is plugin-level configuration stored in plugin settings, not theme design tokens, which means it will not follow a theme switch and cannot be version-controlled alongside a theme. For a site with a design system, that is a meaningful architectural note the video never raises. Contested and unaddressed: the closing "best way to group posts" claim reappears without comparison. No accessibility guidance accompanies any color control. The grid layout is shown but its responsive behavior at narrow widths is never demonstrated. ## 🗒️ Notes #### ⏱️ [00:01](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=1) Recap and scope - Re-establishes the Lord of the Rings demo series from the companion video. - States the scope precisely: this video is about designing the three front-end regions, not creating series. #### ⏱️ [00:45](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=45) Naming the three customizable regions - One-line "part X of X" statement (post details). - Table of contents listing all series parts (post list box). - Previous/next navigation box. - Explicit claim that all three are customizable. #### ⏱️ [01:37](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=97) Post list boxes — live preview and box styling - Settings screen pairs a live preview with controls beneath it. - Demonstrates hiding the series title, then restoring it. - Changes title color, title font size, and box background to purple. - Immediately follows with a manual title-color change to white for readability — a by-eye contrast fix with no tooling support. #### ⏱️ [02:29](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=149) Individual post styling - Post title size raised from 16 to 26. - Featured image can be shown or hidden. - Image width and height are adjustable; set to 160 height to suit movie-poster aspect ratio. - Notes explicitly that posters "are not square" — a real-world constraint most thumbnail UIs ignore. #### ⏱️ [03:16](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=196) The pro boundary - Layout tab: column count, post order, and box position (top or bottom of post) are pro-only. - Free tier covers appearance; structural layout is paid. #### ⏱️ [04:08](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=248) Post details — editable string - Only two tabs: general and styling. - The "entry" wording is user-editable — a movie site can say "movie." - Styling repeats the purple background / white text pattern, again adjusted by eye. #### ⏱️ [05:01](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=301) Preset examples - Ships alternate layouts beyond the default: a gray variant, a darker variant, and a grid style for post lists. - Presets lower the barrier for users who do not want to configure individual controls. #### ⏱️ [06:05](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=365) Navigation options and selection - Three navigation styles: default, simple previous/next buttons, and buttons containing images. - Active layout for each of the three regions is chosen from the settings area. - Closes on the recurring "best way to group posts" claim, with a reference to high-profile magazines and newspapers as users. ## 📚 References - [PublishPress Series — WordPress.org](https://wordpress.org/plugins/organize-series/) - [PublishPress Series documentation](https://publishpress.com/knowledge-base/series/) - [WCAG 2.2 — Contrast (Minimum) 1.4.3](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) - [WordPress theme.json reference](https://developer.wordpress.org/themes/global-settings-and-styles/) ## 🗣️ Paraphrase - **Opening.** The Series plugin groups posts into issues or series; this video covers how to design the resulting front-end elements. - **Scope.** Three regions are customizable: the part-of-N line, the table-of-contents box, and previous/next navigation. - **Box styling.** The post list settings screen offers a live preview with controls for the series title's visibility, color, and size, plus the box background. - **Manual contrast correction.** After setting a purple background, the presenter changes the title to white because it is easier to read — an adjustment made visually, not by measurement. - **Post styling.** Individual post titles can be resized, and featured images shown, hidden, or resized to suit non-square artwork such as movie posters. - **Pro gating.** Column count, ordering, and box placement require the pro version; appearance controls are free. - **Post details.** The one-line statement has editable wording and simple color controls, allowing site-specific language such as "movie" instead of "entry." - **Presets and navigation.** Several ready-made layouts exist, including gray, dark, and grid variants; navigation offers plain buttons or buttons with images. - **Close.** The customization options are presented as a reason PublishPress Series is the best way to group posts. ## 📰 Newsletter **A color picker with no contrast warning is a trap with a live preview.** The second half of PublishPress's Series walkthrough is about making the plugin's front-end boxes look like they belong on your site — and on the merits, it delivers. Three regions, three settings screens, a live preview on each, and enough control over title size, image dimensions, and colors that a non-developer can genuinely make this fit their design. The featured-image sizing detail is a nice touch: Steve sets the height to 160 because movie posters are not square, which is the kind of thing you only add after someone complains. But watch the [01:37](https://www.youtube.com/watch?v=B-Aa0oDD_p8?t=97) mark closely. He sets the box background to PublishPress purple, looks at it, and decides the title should be white because it will be "easier to read." That is a contrast fix performed entirely by eye, by someone with design instincts, on a demo. Nothing in the interface measured anything or warned about anything. Every user who follows along has the same unrestricted pickers and none of the instinct — and [WCAG 1.4.3](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html) does not care how good the preview looked. The other thing worth flagging is architectural rather than visual. All of this styling lives in plugin settings, not in your theme. It will not follow a theme switch, it is not in `theme.json`, and it is not in version control next to your templates. For a hobby site, fine. For anything with a design system, you have just created a second source of truth for color. Layout controls — columns, ordering, box position — are pro. Appearance is free. That is a defensible split, and the free tier is genuinely usable, which is more than can be said for a lot of freemium plugins. ## ✅ Action Items #### DevRel - Developer advocacy: use this as a worked example of the "plugin ships its own design surface" pattern and its consequences for theme consistency. - Education: build a short lesson on why unconstrained color pickers need contrast feedback, using this UI as the case study. - Developer experience: propose a reusable contrast-checking component that plugin authors can drop into settings screens. - Developer marketing: not applicable to this source. - Community management: not applicable to this source. - Internal/external/cross-project: raise with theme and plugin authors the question of when plugin styling should defer to `theme.json` tokens. #### OSPO - Policy & Governance: consider a guideline that any settings UI exposing foreground and background color must display a computed contrast ratio. - License Compliance: GPL via the plugin directory; no action. - Security Management: not applicable to this source — styling controls only. - Software Inventory: styling configuration held in plugin options is a portability consideration; record it if adopted. - Developer Support: document how to override the plugin's injected styles from a theme, for teams with a design system. - Community Engagement: not applicable to this source. - Strategic Alignment: not applicable to this source. #### Community - Maintainers: adding a contrast readout to a color picker is a small, high-value contribution — good candidate to propose upstream. - Contributors: accessibility testing of plugin settings screens is an approachable first-issue area. - Sponsors: not applicable to this source. - Ecosystem: a shared contrast-check component across plugin settings UIs would benefit the whole directory. #### WordPress - Core: consider exposing a core-provided color control that includes contrast feedback, so plugin authors inherit it rather than rebuilding pickers. - Core Performance: check whether per-region custom styles are output inline per post or enqueued once. - Core AI: not applicable to this source. - **Core Program Team:** not applicable to this source. - Mobile: verify the settings screens and live previews are usable at mobile admin widths. - Playground: a Playground demo would let reviewers test the color combinations and contrast quickly. - Community: not applicable to this source. - Training: strong material for an accessible-color-choices lesson aimed at site owners rather than developers. - Marketing: not applicable to this source. - Support: expect "my series box is unreadable" reports; the answer is the styling tab, and the cause is the missing contrast warning. - Design: the live-preview-above-controls pattern is good and worth documenting; the missing contrast feedback is the gap. - Documentation: document how plugin-injected front-end regions should interact with theme design tokens. - Photos: not applicable to this source. - TV: not applicable to this source. - Polyglots: the editable "entry"/"part X of X" string is a localization risk — hand-edited grammar will not translate cleanly across locales. - Accessibility: audit the color pickers against WCAG 1.4.3 and file the missing-contrast-feedback issue upstream. - Meta: not applicable to this source. - CLI: not applicable to this source. - Hosting: not applicable to this source. - Tide: a contrast-feedback check in settings UIs would be an interesting future audit signal. - Openverse: not applicable to this source. - Themes: theme authors should know this plugin's styles are plugin-configured and will not follow a theme switch. - Plugins: propose contrast feedback in color controls as a plugin-review recommendation. #### The WPOCC - Programs: not applicable to this source. - Projects: an accessibility clinic reviewing plugin settings screens would find plenty of material like this. - Funding experiments: not applicable to this source. ### FAIR - Technical independence: styling held only in plugin options is a mild portability concern; export paths matter if the plugin is replaced. - Policies and covenants: not applicable to this source. - Productized governance artifacts: not applicable to this source. ## 🧪 Hypotheses 1. Sites using the plugin's custom color controls produce failing text-contrast ratios more often than sites left on the default layout, because the defaults were designed once and the custom pairs are chosen by eye. 2. Users shown a live computed contrast ratio next to a color picker choose passing combinations more often than users shown only a visual preview, even with no accessibility training. 3. Editable part-of-N strings correlate with grammatical errors in non-English locales, because per-site hand-editing bypasses the translation workflow. 4. Preset layouts are chosen more often than fully custom configurations, because the presets remove decisions rather than adding capability. 5. Plugin-level styling drifts visibly from theme styling within one theme change, producing a visual inconsistency users attribute to the theme rather than the plugin. ### 📊 Methodology - **H1:** crawl a sample of sites running the plugin, extract computed foreground/background pairs for the series boxes, and compute contrast ratios; compare default-config against custom-config sites. - **H2:** A/B test the settings screen with and without a live contrast readout; outcome is the proportion of saved configurations meeting 4.5:1. - **H3:** review the plugin's translated strings across top locales alongside a sample of sites with customized wording; native-speaker grading of grammatical correctness. - **H4:** instrument the settings screen to log preset selection versus individual control changes over a release cycle. - **H5:** longitudinal screenshot comparison on sites that changed themes while running the plugin; measure color-token divergence before and after. ### ❓ Questions - Should a plugin that injects front-end output default to inheriting `theme.json` colors rather than shipping its own palette? - Is there a reason WordPress core does not provide a contrast-aware color control that plugin authors could reuse? - How does the grid layout behave at 320px width, and is the column count responsive or fixed? - If the editable part-of-N string is customized, what happens to the translation for that string in other locales? - Do the pro-only layout controls change markup structure, or only CSS — and does downgrading break the front end? ### 🔮 Future Research - Survey of WordPress plugin settings screens exposing color controls, measuring how many provide contrast feedback of any kind. - Whether block-based rendering via the Interactivity API or block bindings would let series output inherit theme styles automatically. - Study of how non-developer site owners reason about color choices when given a preview but no measurement. - Investigation of localization outcomes for user-editable interface strings generally — a pattern that appears well beyond this plugin. ### 💡 Implications - **Practice.** Treat any plugin color picker as an accessibility review item. Verify contrast with a measurement tool after configuring, since the interface will not tell you. - **Policy.** Organizations with a design system should decide explicitly whether plugin-level styling is permitted, since it creates a second source of truth outside the theme. - **Security.** No direct surface; custom CSS values should nonetheless be escaped on output, which is worth verifying in review. - **Education.** The by-eye contrast correction in this demo is an unusually clear teaching moment — an expert getting the right answer through instinct, in an interface that would let anyone else get it wrong. - **Funding models.** Appearance free, layout paid is a coherent and honest freemium boundary; the free tier is not crippled. ### 🧠 Learning Styles Assessment - **Reading level estimate.** Flesch-Kincaid Grade Level ≈ 7 on the transcript; Flesch Reading Ease ≈ 70. Conversational, short sentences, minimal jargon; nearly every term is shown on screen as it is spoken. #### 👀 Visual learners - Present: exceptionally strong. The entire video is live preview — every control change produces an immediate visible result. - Improve: show before/after pairs side by side rather than sequentially, so the effect of each control is easier to isolate. #### 🔊 Aural learners - Present: clear narration, but the content is intrinsically visual — colors and sizes cannot be conveyed by voice alone. - Improve: state numeric values aloud consistently (the jump from 16 to 26 is spoken, but color values never are). #### 🗣️ Verbal learners - Present: consistent naming of the three regions, which anchors the whole explanation. - Improve: name the regions using the same terms the settings screens use, and define "post details" versus "post list" once — the distinction is easy to lose. #### 🧩 Kinesthetic learners - Present: strong build-along structure; every step is reproducible in a settings screen. - Improve: a Playground link with the demo series preloaded would remove the setup barrier entirely. #### 🧠 Logical learners - Present: clean structure — three regions, each with its own screen, walked in order. - Improve: a table mapping region → settings screen → free/pro status would compress five minutes into one glance. #### 🧑‍🤝‍🧑 Social learners - Present: minimal; one-way demonstration. - Improve: invite viewers to share their configured layouts, which would also surface real-world contrast failures. #### 🧘‍♀️ Solitary learners - Present: fully self-paced and complete. - Improve: a checklist of settings to review after configuring, including a contrast check, would support unassisted work. #### 🌿 Naturalistic learners - Present: none. - Improve: no natural fit here; styling content has little environmental dimension beyond noting that inline per-post styles add page weight. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: not demonstrated; the settings screens use standard WordPress admin controls, which are generally labeled. - Improve: verify the live preview region announces updates, or is marked so it does not spam screen reader users on every control change. Maps to WCAG 2.2 **4.1.3 Status Messages (AA)**. #### Keyboard navigation - Present: standard form controls and tabs; likely focusable. - Improve: confirm the tabbed settings interface implements correct tab semantics and arrow-key behavior. Maps to **2.1.1 Keyboard (A)** and **4.1.2 Name, Role, Value (A)**. #### Contrast and readability - Present: **the central gap in this source.** Color pickers for background, title, text, and link colors are offered with no computed contrast ratio and no warning at any point. The demo itself performs a by-eye correction after producing a hard-to-read pair. - Improve: display the computed ratio next to each foreground/background pair and flag values below 4.5:1. Maps directly to **1.4.3 Contrast (Minimum) (AA)** and, for the resized 26px titles, **1.4.11 Non-text Contrast (AA)**. #### Text resizing and reflow - Present: font sizes are set in fixed pixel values (16, 26), which is a resizing concern. - Improve: offer relative units so user zoom and browser font settings are respected; test the grid layout at 320px. Maps to **1.4.4 Resize Text (AA)** and **1.4.10 Reflow (AA)**. #### Media and captions - Present: auto-generated captions only; color names are spoken but values never are. - Improve: human-reviewed captions plus a written settings reference, since color information is inaccessible to non-sighted viewers throughout. #### Forms and interactions - Present: standard WordPress admin form controls with visible labels in the settings screens. - Improve: the featured-image width and height inputs need clear units and validation; the demo shows trial-and-error resizing that better defaults would avoid. Maps to **3.3.2 Labels or Instructions (A)**. #### Standards reference - Primary gap: **1.4.3 Contrast (Minimum)** — unconstrained color selection with no feedback. Secondary: **1.4.4 Resize Text** (fixed pixel sizing), **4.1.3 Status Messages** (live preview announcements), **1.2.2 Captions** (auto-captions only). ### 🌍 DEIB Assessment #### Cultural breadth - Present: limited — the demo content is a Western film franchise, and the branding example is the vendor's own. - Improve: demonstrate with content and scripts from other locales, which would also expose the part-of-N string's translation weakness. #### Inclusive language - Present: plain, direct, gender-neutral; no idioms that would obstruct a non-native speaker. - Improve: define "post details" and "post list boxes" explicitly, since both are product-specific terms that sound generic. #### Neurodiversity support - Present: strong. Highly predictable structure — one region at a time, one control at a time, immediate feedback after each change. - Improve: the video's own trial-and-error moments (adjusting image height twice) model useful persistence, but a stated target value would reduce ambiguity for viewers who find open-ended tweaking stressful. #### Representation - Present: single narrator; no other voices. - Improve: show configurations from diverse real sites rather than only the vendor's purple branding. #### Psychological safety - Present: relaxed and forgiving in tone; adjustments are shown as normal rather than as mistakes. - Improve: explicitly reassure viewers that settings are reversible, which lowers the barrier for cautious users experimenting with colors. ### ✅ Logical Validity #### Strong reasoning - **Demonstrative, [01:37]–[03:16].** The live preview constitutes direct evidence: each claim about a control is verified on screen the moment it is made. This is the strongest form of argument available in a product demo and it is used well. - **Practical/causal, [02:29].** The reasoning that movie posters are not square, therefore image height needs adjusting, is a clean, correct inference from a real constraint to a specific setting. - **Structural, [00:45].** Enumerating the three regions before customizing any of them gives the rest of the video a valid organizing structure — the audience can locate each subsequent claim. #### Fallacies - **Unsupported superlative (repeated), [06:05] and closing.** *"PublishPress Series is the best way to group multiple posts on the same topic on a WordPress website"* asserts a superlative with no comparison class named. **Fix:** substitute a specific, defensible claim about capability rather than rank. - **Appeal to popularity / authority, closing.** *"We've had high-profile magazines, newspapers, and writers using this for their WordPress sites"* — unnamed prestigious users are offered as evidence of quality. Unnamed adopters cannot be verified, and adoption does not establish fitness for a given site. **Fix:** name two case studies with links. - **Suppressed evidence (omission), throughout the styling segments.** Every color control is presented as pure capability, with the accessibility consequence never mentioned — despite the presenter visibly performing a readability correction on camera. The omission is most conspicuous precisely because the video demonstrates the problem and then does not name it. **Fix:** a single sentence recommending a contrast check would close the gap. #### Tone of voice - Warm, unhurried, and hands-on; heavy use of first-person process narration ("I might want to," "let me see what that looks like," "definitely better, but not quite there yet"). The register is a colleague sharing a screen rather than a polished marketing read, and the audible trial-and-error increases credibility. The final 40 seconds shift into a distinctly promotional register, including an unedited stray sound before the closing pitch. ### 🛡️ DARVO Analysis - **Deny:** None present. No criticism or accusation is engaged, minimized, or denied at any point. - **Attack:** None present. Competing plugins are never named, so there is no credibility-undermining of any party. - **Reverse victim/offender:** None present. No party is cast as wronged or as aggressor. - **Assessment:** Not applicable to this source. This is instructional vendor content with no adversarial framing. The rhetorical weaknesses present are omission and unsupported superlatives, which are marketing artifacts rather than DARVO patterns. No emotional manipulation cues are present beyond a conventional closing call to action. ## 🎯 Conclusion - **Bottom line.** PublishPress Series gives non-developers real control over the three front-end regions it injects, with live previews that make the controls learnable. The free tier covers appearance and the pro tier covers layout, which is an honest split. The unaddressed problem is that unconstrained color selection with no contrast feedback will produce inaccessible output for users who lack the presenter's design instincts — a failure the video demonstrates on camera without naming. - **Next steps for readers.** Configure the styling, then verify every foreground/background pair with an external contrast checker before shipping. Prefer the shipped presets over custom colors unless you have a reason. Check the grid layout at 320px and at 200% zoom. If your site has a design system, decide deliberately whether to style here or override from the theme, because doing both creates two sources of truth. If you edit the part-of-N string, check what it does to your other locales. ## 🔄 Refactor Appendix — How to Customize Series and Issues in PublishPress Series > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter applied. ### 📚 Literature Atoms (H3) #### [H1] Contrast fixes get made by eye when interfaces do not measure > [!quote] ID:rw_1 > If I'm doing that, I might want to go and change the box title color as well. I think white would be easier to read. **Context & use**: - [01:37]–[02:29], immediately after setting the box background to purple. - The clearest artifact in the source: an expert silently correcting a contrast problem the interface never flagged. Cite this whenever arguing that color controls need computed ratios, not previews. **Tags**: #xref #articleseed <!-- atomicity: 1 idea ✓ --> #### [H2] Free tier styles appearance; layout structure is the paid boundary > [!quote] ID:rw_2 > under the layout tab, if you use the pro version of the plugin, you can do things such as control how many columns are used, how the posts are ordered, the location of the box **Context & use**: - [03:16], the layout tab. - A precise, honest freemium boundary worth citing in sustainability discussions: cosmetic control free, structural control paid, free tier still usable. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] Series thumbnails need aspect control because source imagery is not square > [!quote] ID:rw_3 > one thing I might want to do is change the width and the height because we're dealing with movie posters, which are not square **Context & use**: - [02:29]–[03:16], individual post styling. - A small feature reflecting real editorial content. Useful as a concrete example of why fixed square thumbnails fail for serial content — book covers, issue covers, and posters share this problem. **Tags**: #xref #share <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A preview shows what a choice looks like, never whether it passes **Claim** (one sentence, Courtney's voice): Any interface that lets a user pick foreground and background colors while showing only a visual preview will ship inaccessible combinations, because a preview confirms an expert's instinct but supplies no threshold to a user who lacks one. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds wherever color pairs are user-selectable and the output is read by others — plugin settings, theme customizers, form builders, dashboard themers. Does not apply where the palette is constrained to pre-validated token pairs, which is exactly the mitigation. **Links** (≥1 with annotation): - [[WCAG contrast requirements]] — because evidence-for - [[Design tokens]] — because contrasts on constrained versus free color choice - [[WordPress plugin settings patterns]] — because applies-in plugin UI review <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] File an upstream request for a computed contrast ratio in PublishPress Series color controls. — https://www.youtube.com/watch?v=B-Aa0oDD_p8 #fleeting #inbox - [F2] Does WordPress core expose a reusable contrast-aware color control, or does every plugin rebuild pickers? #fleeting #inbox - [F3] Article idea: "Your color picker is not an accessibility tool" — previews versus thresholds. #articleseed #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Check whether core offers a contrast-aware color control plugin authors can reuse — WordPress accessibility #things - [ ] Draft the previews-versus-thresholds post using this demo as the case study — writing queue #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/How to Customize Series and Issues in PublishPress Series.md|How to Customize Series and Issues in PublishPress Series by YouTube]] ## Highlights - box to purple. If I'm doing that, I might want to go and change the box title color as well. I think white would be easier to read. So, you can customize what the whole box looks like here. And then if you click through to the other tabs, you can do things such as customize what the individual posts look like. For example, maybe you want to make the titles larger. I can change 16 to 26 and end up with ([View Highlight](https://read.readwise.io/read/01m0n08ayr6rjny0dd8tre1a0k)) - Note: H1 — Contrast fixes get made by eye when interfaces do not measure. An expert silently correcting a contrast problem the UI never flagged. Also the clearest instance of the video's suppressed-evidence omission: it demonstrates the accessibility problem on camera and never names it. - Tags: atom/literature/h1, fallacy/suppressed-evidence, accessibility - better, but not quite there yet. Okay, I can play around with that, but we're getting more movie poster shaped here. So, you can control what the box looks like, what the individual posts look like, and then under the layout tab, if you use the pro version of the plugin, you can do things such as control how many columns are used, how the posts are ordered, the location of the box at the top of ([View Highlight](https://read.readwise.io/read/01m0n08p35b7w33k94p66mysc7)) - Note: H2 + H3 — The freemium boundary (appearance free, layout structure paid) stated precisely, alongside the aspect-ratio point that serial thumbnails need width/height control because source imagery like posters is not square. - Tags: atom/literature/h3, atom/literature/h2, business-models - other layouts that's available for the post list boxes, for the post details, and the post navigation. But I think you'll agree that these customizable settings and design options are one of the many reasons why PublishPress Series is the best way to group posts together on your WordPress site. >> [snorts] >> We've had high-profile magazines, newspapers, and writers using this for ([View Highlight](https://read.readwise.io/read/01m0n09gd5ttrcs8ve8nycychh)) - Note: Two fallacies in one passage: "best way" is a superlative with no comparison class named, and unnamed "high-profile magazines, newspapers, and writers" is an appeal to popularity that cannot be verified and does not establish fitness for any given site. Fix: name two linked case studies and state a capability contrast instead of a rank. - Tags: fallacy/unsupported-superlative, fallacy/appeal-to-popularity