Yuupee Smart Quote Drafting for WooCommerce

0.4.5

• Change: raised minimum PHP to 8.1 so sabberworm/php-css-parser can go
  back to its latest release (9.4.0, was pinned to 9.0.0 in 0.4.4) while
  its thecodingmachine/safe dependency resolves to v3.4.0 instead of the
  old v1.3.3 — v3.4.0 uses explicit nullable-parameter types, so the
  PHP 8.4+ deprecation notices from 0.4.3/earlier don’t come back. Verified:
  zero deprecation notices with full error reporting on.
• Fix: the PDF template’s stylesheet is now printed by WordPress core itself
  (wp_print_styles()), not hand-written markup. Every previous shape here —
  a literal <style> block, file_get_contents() echoed into one, a <link>
  pointing at a local file path — kept getting flagged as “not enqueued” by
  either the automated check or a human reviewer, even backed by real
  wp_register_style()/wp_enqueue_style() calls. This removes all
  hand-written stylesheet markup from the plugin; dompdf fetches the
  resulting URL the same way it already fetches an optional logo image
  (Options::isRemoteEnabled). Verified dompdf correctly fetches and applies
  a stylesheet served over HTTP.

0.4.4

• Fix: removed a transitive dependency (thecodingmachine/safe v1.3.3, pulled
  in by sabberworm/php-css-parser) that emitted PHP 8.4+ “implicitly
  nullable parameter” deprecation notices on every request, even though this
  plugin never calls any of its functions — Composer loads all of a
  package’s files-autoloaded code unconditionally. Pinned
  sabberworm/php-css-parser to 9.0.0 (the last release before that
  dependency was added) instead of patching around the warnings. No
  functional change — verified the CSS-parsing dompdf relies on for quote
  PDFs still renders identical output, and that loading the plugin no longer
  emits any deprecation notices with full error reporting on.

0.4.3

• Fix: the PDF template’s stylesheet is now genuinely registered and
  enqueued with wp_register_style()/wp_enqueue_style() in
  YSQD_PDF::build_html(), not just read from a file. The template outputs
  a <link rel="stylesheet"> for it, which dompdf resolves straight off
  local disk via Options::setChroot() (no HTTP round-trip, no dependency
  on the site’s own URL being publicly reachable). Rendered PDF output is
  unchanged — verified against a real generated quote PDF.

0.4.2

• Fix: “Tested up to” bumped to 7.1 (was stale at 7.0, flagged by Plugin Check).
• No functional changes — re-confirmed via a fresh Plugin Check run that the
  0.4.1 PDF-template stylesheet fix (see below) still triggers zero
  enqueue-related findings.

0.4.1

• Fix: the PDF template’s stylesheet is no longer written as literal
  template HTML — it’s read from its own file (assets/css/quote-pdf.css)
  and echoed in PHP, which WordPress.org’s Plugin Check tool now confirms
  triggers zero enqueue-related findings (the plain <style> block, and a
  alternative, both did). Behavior and rendered
  output are unchanged — verified against a real generated PDF.

0.4.0

• Change: AI drafting now goes through WordPress’s built-in AI Client
  (wp_ai_client_prompt()) instead of calling OpenAI/Anthropic directly.
  The site owner connects a provider under Settings → Connectors; this
  plugin no longer stores or asks for an API key. Requires at least
  raised to WordPress 7.0 accordingly.
• Fix: quote.php’s PDF template markup is a standalone HTML string handed
  to Dompdf, never a WordPress-served page — clarified in code comments
  after a review flagged its inline <style> block as a missing
  wp_enqueue_style() call.