<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>EDD on Luis Sousa Blog</title>
    <link>https://89393b0c.nuvai-blog.pages.dev/tags/edd/</link>
    <description>Recent content in EDD on Luis Sousa Blog</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 07 Mar 2026 12:10:00 +0000</lastBuildDate>
    <atom:link href="https://89393b0c.nuvai-blog.pages.dev/tags/edd/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Protecting EDD Downloads from URL Guessing</title>
      <link>https://89393b0c.nuvai-blog.pages.dev/posts/protecting-edd-downloads-from-url-guessing/</link>
      <pubDate>Sat, 07 Mar 2026 12:10:00 +0000</pubDate>
      <guid>https://89393b0c.nuvai-blog.pages.dev/posts/protecting-edd-downloads-from-url-guessing/</guid>
      <description>&lt;p&gt;We sell digital products on &lt;a href=&#34;https://joyofexploringtheworld.com/&#34;  class=&#34;external-link&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;joyofexploringtheworld.com&lt;/a&gt; using Easy Digital Downloads. By default, EDD stores files in &lt;code&gt;wp-content/uploads/&lt;/code&gt;—the same directory as every other WordPress upload. That means anyone who can guess the filename can download the file directly, bypassing purchase validation entirely.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-problem&#34;&gt;&#xA;  The problem&#xA;  &lt;a class=&#34;heading-link&#34; href=&#34;#the-problem&#34;&gt;&#xA;    &lt;i class=&#34;fa-solid fa-link&#34; aria-hidden=&#34;true&#34; title=&#34;Link to heading&#34;&gt;&lt;/i&gt;&#xA;    &lt;span class=&#34;sr-only&#34;&gt;Link to heading&lt;/span&gt;&#xA;  &lt;/a&gt;&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;EDD download URLs contain a token that validates the purchase. But the actual file sits in a publicly accessible directory. If someone guesses or discovers the file path (e.g. from a cached CDN URL or a predictable naming pattern), they can download it without paying.&lt;/p&gt;</description>
    </item>
    <item>
      <title>When &#34;There Has Been an Error Cropping Your Image&#34; Isn&#39;t About the Image</title>
      <link>https://89393b0c.nuvai-blog.pages.dev/posts/when-image-crop-error-isnt-about-the-image/</link>
      <pubDate>Sat, 07 Mar 2026 12:04:00 +0000</pubDate>
      <guid>https://89393b0c.nuvai-blog.pages.dev/posts/when-image-crop-error-isnt-about-the-image/</guid>
      <description>&lt;p&gt;We run a travel blog on a budget stack (&lt;a href=&#34;https://joyofexploringtheworld.com/&#34;  class=&#34;external-link&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;joyofexploringtheworld.com&lt;/a&gt;) with Docker, Cloudflare, and imgproxy for images. When we hit “There has been an error cropping your image” in the WordPress media editor, the message pointed at the image—but the real cause was elsewhere.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-misleading-error&#34;&gt;&#xA;  The misleading error&#xA;  &lt;a class=&#34;heading-link&#34; href=&#34;#the-misleading-error&#34;&gt;&#xA;    &lt;i class=&#34;fa-solid fa-link&#34; aria-hidden=&#34;true&#34; title=&#34;Link to heading&#34;&gt;&lt;/i&gt;&#xA;    &lt;span class=&#34;sr-only&#34;&gt;Link to heading&lt;/span&gt;&#xA;  &lt;/a&gt;&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;The error suggests missing image libraries (GD or Imagick). We confirmed both were installed and working. The actual problem: the crop request to &lt;code&gt;admin-ajax.php&lt;/code&gt; was returning &lt;strong&gt;403 Forbidden&lt;/strong&gt;. That can come from a security plugin, WAF, or nonce validation—not from the image itself.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Fixing header and footer overlap on WordPress checkout pages (EDD &#43; block theme)</title>
      <link>https://89393b0c.nuvai-blog.pages.dev/posts/fixing-edd-checkout-header-footer-overlap/</link>
      <pubDate>Sat, 07 Mar 2026 12:00:00 +0000</pubDate>
      <guid>https://89393b0c.nuvai-blog.pages.dev/posts/fixing-edd-checkout-header-footer-overlap/</guid>
      <description>&lt;p&gt;We sell downloadable travel itineraries on &lt;a href=&#34;https://joyofexploringtheworld.com/&#34;  class=&#34;external-link&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;joyofexploringtheworld.com&lt;/a&gt; using Easy Digital Downloads (EDD). With a sticky header and a block theme (Bricksy Pro), the checkout and receipt pages had content sitting under the header and footer. Here&amp;rsquo;s how we fixed it.&lt;/p&gt;&#xA;&lt;h2 id=&#34;the-problem&#34;&gt;&#xA;  The problem&#xA;  &lt;a class=&#34;heading-link&#34; href=&#34;#the-problem&#34;&gt;&#xA;    &lt;i class=&#34;fa-solid fa-link&#34; aria-hidden=&#34;true&#34; title=&#34;Link to heading&#34;&gt;&lt;/i&gt;&#xA;    &lt;span class=&#34;sr-only&#34;&gt;Link to heading&lt;/span&gt;&#xA;  &lt;/a&gt;&#xA;&lt;/h2&gt;&#xA;&lt;p&gt;With a sticky or fixed header, the main content area starts at the top of the viewport. The header overlays it, so the first lines of the checkout form are hidden. Similarly, a fixed footer can cover the bottom of the page. FSE block themes don&amp;rsquo;t always add padding for fixed elements on custom post types like EDD checkout.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
