Title: wp4bs's Replies | WordPress.org

---

# wp4bs

  [  ](https://wordpress.org/support/users/wp4bs/)

 *   [Profile](https://wordpress.org/support/users/wp4bs/)
 *   [Topics Started](https://wordpress.org/support/users/wp4bs/topics/)
 *   [Replies Created](https://wordpress.org/support/users/wp4bs/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/wp4bs/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/wp4bs/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/wp4bs/engagements/)
 *   [Favorites](https://wordpress.org/support/users/wp4bs/favorites/)

 Search replies:

## Forum Replies Created

Viewing 1 replies (of 1 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[Broken Link Checker] Local Checker apparently renders Link URLs incorrectly](https://wordpress.org/support/topic/local-checker-apparently-renders-link-urls-incorrectly/)
 *  Thread Starter [wp4bs](https://wordpress.org/support/users/wp4bs/)
 * (@wp4bs)
 * [5 days, 15 hours ago](https://wordpress.org/support/topic/local-checker-apparently-renders-link-urls-incorrectly/#post-18982570)
 * Hi Dmytro,
 * I appreciate your prompt response.
 * Yesterday, I had some spare time, and so I dared to dive into the plugin code.
   Lucky enough, and having had a closer look at the database, I found a solution
   for the problem.
 * The problem is related to a malfunction of the blc parser in conjunction with
   a feature of the Divi Builder. If you choose to have different contents in the
   same text module depending on the device type (desktop, tablet, phone), the entire
   content of that module gets escaped. This means that links within such a text
   are stored in the database as `<a href=%22https://..%22`, rather than `<a href
   ="https://.."`.
 * The blc parser, however, does not remove the “%22” characters from the beginning
   and end of the link, so the parse_url function does not recognize the string 
   as a valid URL and therefore does not return a “scheme” key in the array that
   is returned. This, in turn, causes the URL to be treated as relative, so the 
   base URL is prepended.
 * This small fix, placed immediately before the call to `@parse_url` in the file`
   html_link.php`, works in my case:
 * `if ( str_starts_with( $url, ‘%22’ ) && ( str_ends_with( $url, ‘%22’ ) ) ) $url
   = substr( $url, 3, -3 );`
 * After being applied, there have not been any more error messages. It would be
   great if you could resolve the issue in this or a similar way in one of the upcoming
   updates.
 * Please let me know if I should email this to your support team, too, or if this
   post is sufficient. Maybe my explanation wasn’t straightforward enough; don’t
   hesitate to contact me at `wordpress.dev@bsoft.de`.
 * Regards, Hanno

Viewing 1 replies (of 1 total)