1 Introduction

Since I built my blog using WordPress, I've complained a lot about WordPress's inherent mechanism of only allowing access from one URL:

The reason is simple—I also have to access the admin panel via domain name when I'm in use. Accessing the admin panel via domain name requires going through a series of security checks. Especially after I set up managed challenges for sensitive paths like /wp-admin/ in my Cloudflare custom rules, the entire access process became even more inefficient.

On the other hand, my blog (based on WordPress) deployment adopted...Active-Active ArchitectureThe master node (write) is a WordPress node at home, and the slave nodes (read-only) are borrowed from a VPS in Chicago. In theory, I could directly access the master node at home using the internal IP address for daily maintenance and write operations (for those interested in this architecture, please refer to previous articles).Home Data Center Series WordPress Multi-Active Architecture (Simplified Version) Implementation Plan in Personal BlogHowever, I was forced to go through a lot of trouble due to WordPress's single-domain access restrictions and security policies. The key is that I need to take extra steps to ensure that when I access the domain name, I am accessing the master node.

For convenience, I later configured it.Multiple domain access methods(See article:)A simple tutorial on how to set up WordPress to support multiple domain name accessThey've always used an internal IP address to manage WordPress. This management method usually works smoothly, but there's one scenario where problems still arise:When replying to comments directly in the backgroundSpecifically, when I access the master node admin panel using my internal IP address and reply to a comment, WordPress writes my information (the internal link used to access the admin panel) 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 internal link, thus preventing the comment from being replied to correctly.

So, I've finally decided to try and solve this problem myself, and I can easily write a short article about it.

2. Problem-solving approach and implementation

2.1 Solution Approach

The root cause of the problem is quite clear: when WordPress saves comment data, it writes the commenter's information (including the URL address) into the database. When I log in to the backend using my internal IP address and reply to a comment directly, this internal IP address is recorded. For me personally, this doesn't cause any problems; however, when external visitors access the site via the public internet, their systems cannot recognize or access this internal IP address, resulting in comments not being replied to correctly, or even page loading errors.

Therefore, what really needs to be addressed is not the logic of the comments themselves, but...The URLs recorded in the comments need to be consistent.Whether I access the backend from the public network or log in through an internal network address for management, the data ultimately written to the database should be the same externally accessible domain address.

Achieving this is actually quite simple: before submitting comments to the database, just check and replace the comment metadata, uniformly replacing the internal network addresses with public domain names. This way, backend operations remain unchanged; and from the visitor's perspective, the comment system remains consistent and usable, with completely consistent reply logic.

In other words, the root of the problem isn't an error in WordPress's comment mechanism, but rather an inconsistency in the URL information within the comment metadata due to different access paths. Once this information is standardized, the comment reply issue will naturally be resolved.

2.2 Implementation Scheme

Since the root of the problem lies in the incorrect URL being written into the comment data, the most direct solution is...Before the data is entered into the database, the relevant fields should be processed uniformly..

The approach can be divided into two parts:“"Intercept" and "Replace"”.

“"Interception" means that before a comment is submitted to the WordPress backend, the request is intercepted to determine if it is indeed a comment request. Only if it is confirmed to be comment data will we intervene. Otherwise, it is allowed to proceed to avoid interfering with other backend functions.

“"Replacement" is the key to the entire solution. Comment data is often submitted in POST format, containing the comment content, commenter information, comment target (post ID), and the URL from which the comment originated. If internal network addresses appear in the submitted data, these addresses need to be replaced with a unified public domain name before the request reaches WordPress. This way, when WordPress finally writes to the database, it always records the standard domain name address, eliminating address inconsistencies regardless of whether the backend operation originates from the public or internal network.

In principle, this approach adds an intermediate processing layer at the "entry point" of the WordPress comment submission process. It doesn't rely on WordPress plugins or modify core files; it achieves data consistency simply by preprocessing requests at the network layer. This makes the solution highly versatile and secure—it can be seamlessly applied as long as comment requests can be intercepted, regardless of whether the site is deployed locally, on a single node, or in a distributed environment.

In other words, we're not "patching" WordPress, but rather using a lightweight, non-intrusive "proxy adjustment" to make the system, which previously only recognized a single access path, compatible with multiple access sources. This design approach is elegant in itself: keeping data consistent without forcing users to change their access habits.

2.3 Code Implementation

Once the approach was determined, implementation became quite simple. We didn't need to modify WordPress's core logic or write complex plugins; we could easily accomplish this by utilizing the system's built-in filter hook mechanism.

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

What these two functions have in common is that they both generate a complete comment reply link, and the beginning of the link is usually the domain name of the current visit, which is the address that the user sees in the browser's address bar.

This is precisely the problem. If I access the WordPress admin panel from an intranet environment, the domain part of these links will become the intranet IP address, for example:

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

When WordPress saves comments, it writes these links into its database. Therefore, when an external visitor clicks "Reply," the browser attempts to access this internal address, which naturally fails to open.

Therefore, what we need to do is—replace these internal network addresses with public domain names before WordPress outputs comment links.https://blog.tangwudi.com.

The implementation code is as follows:

// The unified comment reply link is a public domain, compatible with the Argon theme. add_filter('get_comment_link', function(link,comment, args){ return preg_replace( '#^https?://[^/]+#i', 'https://blog.tangwudi.com',link); }, 10, 3); // If the Argon theme generates a reply link using Ajax or a custom function on the front end, add_filter('comment_reply_link', function(link){ return preg_replace( '#^https?://[^/]+#i', 'https://blog.tangwudi.com',link ); });

The two code snippets above correspond to two scenarios: generating comment links in the WordPress core function and at the theme level, respectively.

For a single-node WordPress site, there are two ways to use this code:

• Method 1: Simply add the above code to the end of the functions.php file of your current theme;
• 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 paragraph is the most crucial part. "get_comment_link" is a function called by the WordPress core when outputting comments. Filters allow us to intervene in the final step of link generation and modify the content. Here, regular expressions are used to remove the original internal URL portion of the link (i.e., http://192.168.10.99:50443 Replace this section with a public domain name.https://blog.tangwudi.com.

The second paragraph is for compatibility. Argon themeIn certain interactions within the comment section (such as clicking the "Reply" button), Argon doesn't directly call standard WordPress functions. Instead, it dynamically generates comment links using custom functions within the theme or Ajax interfaces. Modifying only the core filter might miss these dynamically generated links, so we also attach `comment_reply_link` to ensure consistent replacement in both cases.

The benefits of doing this are obvious: regardless of whether you access the backend via the public internet, log in from home using an internal network address, or even use a multi-node mirror environment, all comment links will ultimately be standardized to the same format. https://blog.tangwudi.com To begin, links in comment history, replies, and even email notifications will remain consistent, eliminating the "cannot open" issue caused by different access paths.

More importantly, this method isnon-invasive—It doesn't modify the database, the theme template, or affect plugin compatibility. It simply makes a lightweight replacement in the final stage of comment generation using WordPress's native Hook system. This is the essence of WordPress's ecosystem design: a few lines of code can elegantly solve a marginal problem that no one has mentioned for years.

At this point, the seemingly "harmless" problem is completely solved, and the comment system can finally switch naturally between the public network and the internal network without causing problems due to different access methods in the backend.

For WordPress sites deployed in a multi-active architecture, if the "comment writing to the master node" approach is used, this code only needs to be applied to the master node; if the "multi-node simultaneous writing" mode is used, the same code needs to be enabled on all nodes to maintain the consistency of comment links (see the article for solutions to the comment synchronization problem in WordPress multi-active architecture:Home Data Center Series: Using Cloudflare Worker to Solve the Comment Synchronization Problem in WordPress Multi-Active Architecture).

3 Conclusion

Ultimately, this article is about a niche but potentially dangerous pitfall: when the blogger logs into the WordPress backend using an internal IP address to reply to comments, the reply link points to the internal address, preventing readers from replying directly on the blog page (a similar situation can also occur when managing WordPress on a VPS using a Tailscale IP).

My final solution is to uniformly replace the links with public IP addresses. This way, the user experience can be unaffected by any IP address used to log in to the backend; the links in the comment section are also unified, so users can reply to my comments posted using internal IP addresses; and it works for both single-node and multi-node deployments, as long as it is deployed on the corresponding node according to your environment.

Technically speaking, this is actually quite simple, but it solves a rather hidden and "everyday" problem.

As for why the article title is "half-finished product," it's because there's still a lingering issue that hasn't been truly resolved: the hostname of the link in the notification email is comment1.tangwudi.com, not blog.tangwudi.com.

The reason for this is that when I use workers to asynchronously write comments to three nodes (comment1, comment2, comment3), I only allow my comments to be written to the main node (comment1.tangwudi.com) for email notification. If readers carefully observe the link in the email, they'll notice it doesn't match the blog domain, which looks rather cheap. Therefore, I consider this solution only a half-finished product. Of course, it works fine because I use a 302 redirect to return the link to the blog domain, so clicking the link in the email opens the comment page normally.