1 Introduction

Since building my blog with WordPress, the mechanism where WordPress naturally only allows access from a single address has made me complain many times:

The reason is very simple—when managing the backend on a daily basis, I also have to use the domain name to access it. And accessing the backend using the domain name requires going through a series of security policy checks. Especially later, after I set up a Managed Challenge in the Cloudflare custom rules for sensitive paths like /wp-admin/, the entire access process became even more inefficient.

On the other hand, my blog (based on WordPress) deployment adopts anactive-active architecture, where the master node (write) is at the home WordPress node, and the slave node (read-only) is at the Chicago VPS node. Logically, I could completely use the intranet IP to directly access the home master node for daily maintenance and writing operations (friends interested in this architecture can refer to the previous article:Home Data Center Series: WordPress Active-Active Architecture (Simplified Version) Implementation Plan in Personal Blog), however, I was forced to go a long way around by WordPress's single-domain access restriction and security policies. Crucially, I also need extra steps to ensure that when accessing via the domain name, it accesses the master node~.

For convenience, I later configuredmulti-domain access methods(see article:Tips and Tricks Series: Simple setup tutorial for WordPress supporting multi-domain access), and have been using the intranet IP to manage WordPress. Usually, this management method runs very smoothly, but there is still one scenario where problems occur:When replying to comments directly in the admin dashboardSpecifically, when I use the intranet IP to access the master node dashboard and reply to a comment, WordPress writes my information (the intranet link when accessing the dashboard) into the comment metadata. This means that if a visitor tries to reply to these comments under a blog post, the visitor's system will not be able to recognize my intranet link, resulting in the comment not being replied to normally.

So, I finally decided to try and solve this problem, and by the way, write a quick blog post about it~.

2 Problem-Solving Ideas and Implementation

1 Problem-Solving Ideas

The root of the problem is actually very clear: when WordPress saves comment data, it writes the commenter's relevant information (including the URL address) into the database. When I use the intranet IP to log into the dashboard and reply directly to comments, this intranet address is recorded. For myself, this does not cause any problems; but when external visitors access via the public network, their systems cannot recognize or access this intranet address, resulting in comments not being replied to correctly, or even abnormal page loading.

Therefore, what really needs to be solved is not the logic of the comment itself, but thatthe URL addresses recorded in the comments need to maintain consistencyWhether I access the dashboard via the public network or log in through an intranet address for management, what is ultimately written to the database should be the same, externally accessible domain name address.

Implementing this is actually not complicated: we just need to check and replace the comment metadata before the comment is submitted to the database, uniformly replacing the intranet addresses with the public domain name. In this way, the dashboard operations still remain the same and unaffected; while from the visitor's perspective, the comment system remains coherent and usable, and the reply logic is completely consistent.

In other words, the essence of this problem is not that WordPress's comment mechanism went wrong, but that different access paths caused “environmental inconsistency” in the address information within the comment metadata. Once this layer of information is unified, the comment reply issue will naturally be resolved.

2 Implementation Plan

Since the root of the problem lies in the incorrect URL being written into the comment data, the most direct solution isto perform a unified processing on the relevant fields before the data is written to the database。

The idea can be divided into two parts:“Interception” and “Replacement”。

“Interception” means that before the comment is submitted to the WordPress backend, we first intercept this request to determine whether it is a comment request. Only when it is confirmed as comment data do we intervene. Otherwise, we let it pass directly to avoid interfering with other backend functions.

“Replacement” is the key to the entire solution. Comment data is often submitted in POST format, which contains the comment content, commenter information, comment target (post ID), and the source URL at the time of commenting. If an intranet address appears in the submitted data at this time, these addresses need to be replaced with a unified public domain name before the request reaches WordPress. In this way, when WordPress finally writes to the database, what is recorded is always the standard domain name address, and whether the backend operation originates from the public network or the intranet, there will no longer be an issue of inconsistent addresses.

In principle, this approach is equivalent to adding a layer of intermediate processing logic at the “entrance” of the WordPress comment submission process. It does not rely on WordPress plugins, nor does it modify core files; it achieves consistency at the data layer simply by preprocessing requests at the network layer. This makes the solution highly versatile and secure—as long as comment requests can be intercepted, it can be seamlessly applied, whether the site is deployed locally, on a single node, or in a distributed environment.

In other words, we are not “patching” WordPress, but rather through a lightweight, non-intrusive “proxy adjustment,” making a system that originally only recognized a single access path compatible with multiple access sources. This design concept itself is also very elegant: keeping data consistent without forcing users to change their access habits.

3 Code Implementation

Once the idea is determined, the actual implementation becomes very simple. We don't need to modify WordPress's core logic, nor do we need to write complex plugins; we can easily accomplish it just by utilizing the filter hook mechanism provided by the system itself.

WordPress's comment system calls multiple functions when generating comment links, such as get_comment_link() and comment_reply_link().

The common point of these two functions is that both generate a complete comment reply link, and the beginning of the link is usually the domain name at the time of the current access, which is the address the user sees in the browser's address bar.

This is exactly where the problem lies. If I access the WordPress dashboard in an intranet environment, the domain name part of these links will become the intranet IP, for example:

http://192.168.10.99:8080/?replytocom=123#respond

And when WordPress saves comments, it writes these kinds of links into the database. Consequently, when an external visitor clicks “Reply,” the browser will try to access this intranet address, which naturally cannot be opened.

Therefore, what we need to do is—before WordPress outputs the comment links, uniformly replace these intranet addresses with the public domain namehttps://blog.tangwudi.com。

The implementation code is as follows:

// Unify comment reply links to public domain, compatible with Argon themelink,comment, args){,linklink){,link;

The two pieces of code above correspond to the two situations of generating comment links by WordPress core functions and the theme layer, respectively.

For WordPress sites deployed on a single node, there are two ways to use this code:

• Method 1: Directly add the above code to the end of the current theme's functions.php file;
• Method 2: If you don't want to modify the theme files, you can also install the ”Code Snippets” plugin, add it as a new “Snippet” and enable it. This method is safer and makes it easier to retain custom logic after theme updates.
  
  

The first part is the most critical. ”get_comment_link” is the function called by the WordPress core when outputting comments, and the filter allows us to intervene in the final step of link generation to modify the content. Here, a regular expression is used to replace the original intranet address part in the link (i.e., http://192.168.10.99:50443 this part) with the public domain namehttps://blog.tangwudi.com。

The second part is for compatibility with the Argon themeIn some interactions in the comment area of Argon (such as when clicking the “Reply” button), it does not directly call the standard WordPress functions, but dynamically generates comment links through custom functions within the theme or Ajax interfaces. If we only modify the core filter, we might miss this part of dynamically generated links, so we also hooked comment_reply_link to ensure both cases can be uniformly replaced.

The benefit of doing this is obvious: whether you access the dashboard via the public network, log in to the dashboard through an intranet address at home, or even use a multi-node mirrored environment, ultimately all comment links will be uniformly standardized as https://blog.tangwudi.com Beginning. Comment records, reply links, and even links in email notifications will remain consistent, and there will no longer be situations where “clicking fails to open” due to different access paths.

More importantly, this approach isnon-intrusive— without modifying the database, touching theme templates, or affecting plugin compatibility. It simply performs a lightweight replacement in the final step of comment generation through WordPress's native Hook system. This is precisely the essence of the WordPress ecosystem design: a few lines of code can elegantly solve an edge-case issue that has gone unmentioned for years.

At this point, this seemingly “harmless” issue is completely resolved. The comment system can finally switch naturally between the public network and the intranet, no longer causing issues due to different access methods to the backend.

For WordPress sites deployed in an active-active architecture, if the “write comments to the primary node” scheme is adopted, you only need to apply this code on the primary node; if it is the “simultaneous writing to multiple nodes” mode, the same code needs to be enabled on all nodes to maintain the consistency of comment links (for the solution to the comment synchronization issue in WordPress active-active architecture, see the article:Home Data Center Series: Solving the Comment Synchronization Problem in WordPress Active-Active Architecture with Cloudflare Worker)。

3 Summary

In the final analysis, this article is actually about dealing with a rather niche but real pitfall that people can fall into: when a blogger logs into the WordPress backend using an intranet IP to reply to comments, the reply comment links will point to the intranet address, making it impossible for visitors to reply directly on the blog page (in fact, a similar situation may also be encountered when using Tailscale IP to manage WordPress on a VPS).

In the end, my solution is: uniformly replace the links with the public network address. This way: any IP can be used to log into the backend without affecting the experience; the links in the comment section are also unified, so visitors can normally reply under the article to the comments I posted using the intranet IP; it works for both single-node and multi-node deployments, as long as it is deployed on the corresponding node according to your own environment.

Technically speaking, this is actually quite simple, but it solves a rather hidden and “everyday” hassle.

As for why the article title is ”Semi-finished Product”? Because there is actually a legacy issue that hasn't been truly resolved, which is that the hostname of the links in the notification emails is comment1.tangwudi.com, instead of blog.tangwudi.com.

The reason for this is that when I use a worker to asynchronously write comments to 3 nodes (comment1, comment2, comment3), I only allow my comments written to the primary node (which is comment1.tangwudi.com) to trigger email notifications. If commenting friends carefully observe the links in the emails, they will find that they are inconsistent with the blog domain name, which looks a bit low-end, so I think this solution can only be considered a semi-finished product... Of course, it works fine because I used a 302 redirect to point the access links back to the blog domain name, so clicking the links in the emails directly opens the comment page normally.