i never liked the arbitrary “Reply” link gets added under each comment because a lot of people think that this is what you’re supposed to click to write a top-level comment - instead they end up replying to a previous comment and it screws up the nesting - this helps to solve that by changing the ‘Reply’ link to ‘Reply to <name>’ link
for the code see this post below in which i corrected the code according to suggestions provided by @anon71687268
I, too, find that annoying! I’m used to it by now, but, have still seen lots of hard-to-follow convos in comments sections due to this. Nice snip.
While it’s often recommended (in the WP space) to add code snips to the functions.php file, that’s actually a bad practice that is (ever so slowly) going away. The proper way (which is how we’re recommending to do it with ClassicPress) is to place such code snips into a utility plugin – it only actually takes a single file and you can copy/paste your snips right in. Here’s an article that describes why functions.php should be avoided in 90% of cases and breaks down exactly how to create a utility plugin for such code snips.
https://codepotent.com/create-a-custom-utility-plugin-for-your-classicpress-site/
Of course, that’s not to say that you can’t place code into the functions.php file – in fact, there are some code snips that actually do belong there. I thought you might like to understand the difference and learn a new trick along the way. 
Cheers!
thank you for that! - i moved my custom functions to /plugins and learned a couple things in the process
one thing i would add is that i think it’s a good idea to stick this at the top of your plugs - at least i see this in other plugins…
/* die if called directly */
defined('ABSPATH') or die('No direct access!');
Sure thing.
I write it slightly differently, but, yes, you’re right. I’ve updated the code examples in the article. One thing to note is that the line should be added to the top of the file unless you’re using a namespace in your plugin (as done in the article.) In the case of namespaces, the namespace must be the very first line of code in the file…and then followed by the line you described. 
for piece of mind, could you confirm this @anon71687268 …
here’s the whole script - given the good advice by @anon71687268 create a folder in the /plugins directory (add-comment-reply-name or whatever) and stick this script inside (add-comment-reply-name.php) and edit the namespace entries as needed - finally, set the owner and group (chown) of both the file and folder accordingly (admin:admin in many cases), then activate in CP as any other plugin
<?php
/**
* Plugin Name: Comment Reply To Name
* Plugin URI: <some URL>
* Author Name: <name>
* Author URI: <some URL>
* Description: changes Reply link in comments to include the commenters name
* Version: 0.1.0
*/
namespace Comment_Reply_To_Name;
/* die if called directly */
defined('ABSPATH') or die('No direct access!');
// original code: https://raam.org/2013/personalizing-the-wordpress-comment-reply-link/
if (! function_exists('add_comment_author_to_reply_link')) {
function add_comment_author_to_reply_link($link, $args, $comment){
$comment = get_comment($comment);
// If no comment author is blank, use 'Anonymous'
if (empty($comment->comment_author)) {
if (!empty($comment->user_id)){
$user=get_userdata($comment->user_id);
$author=$user->user_login;
} else {
$author = __('Anonymous');
}
} else {
$author = $comment->comment_author;
}
// If the user provided more than a first name, use only first name
//if(strpos($author, ' ')){
// $author = substr($author, 0, strpos($author, ' '));
//}
// Replace Reply Link with "Reply to <Author First Name>"
$reply_link_text = $args['reply_text'];
$link = str_replace($reply_link_text, "Reply to '" . $author . "'", $link);
return $link;
}
add_filter('comment_reply_link', __NAMESPACE__.'add_comment_author_to_reply_link', 10, 3);
}
Well, that’s a fine example of learning something new and applying the knowledge – good work!
I’d make a couple of slight changes. As you’ve written it above, it’s truly a stand-alone plugin (rather than a utility plugin.) The reasons why are:
Now, before I explain, it should be noted that what you’ve done here is completely valid as a stand-alone plugin.
If you think about the purpose of creating a utility plugin (which is to contain our many random code snips, safe from loss,) a more accurate header description (for a utility plugin) would be something like, “Custom functionality for xyz.com” or something like that. The reason you don’t want to specifically describe the functionality in the header is that you’d have to re-edit the header every time you added a new snip to the file (if you wanted to keep the description correct) and it would get unwieldy in no time. Instead, what you can do is to describe the functionality in a comment block just above the given snip. Then, when you add something else to the file later (which you almost 100% will,) you can add another comment block to describe the new functionality…and the header comment remains correct without any editing.
It’s the same logic behind #2 (the filename/directory name) … the suggested filename, add-comment-reply-name.php, and the directory name, add-comment-reply-name, describe a stand-alone plugin that adds the reply name to the comment. A utility plugin would tend to use something more generic like custom-functionality or utility-plugin for the directory name, thus allowing you to continue to add functionality without editing the file and directory name.
PS. You forgot the namespace line. 
It would go between your primary header comment and the ABSPATH line. The namespace must be the first line of code in the file. It’s fine to have comments above the namespace, but, the namespace must be the first line of actual code.
As you’ve written it above, it’s truly a stand-alone plugin …
yes, that was intentional - i like the idea of keeping functions isolated for troubleshooting and clarity reasons - my reasoning here is that if i added a bunch of small-ish functions in a single plug, then troubleshooting is harder (for me) if/when something breaks because now i have to start commenting out blocks of code, rinse, repeat, until the issue is isolated, rather than just disabling plugs from within admin
You forgot the namespace line.
actually i omitted it because i didn’t immediately understand it - i think i got it now and so i added to the code above
The thing is, when you add new code to a utility plugin, you’ll probably notice immediately if something were to break. In that case, you don’t have to comment out block-by-block; you’d just comment out whatever you were working on. The functionality in a utility plugin can be deactivated in one-fell-swoop, which often means you won’t have to activate/deactivate a bunch of plugins “just to see”. Whenever something goes wrong on my site, the first thing I do is deactivate my own utility plugin to make sure it’s not the culprit. If something did manage to slip through and break things, then I’d resort to commenting blocks out.
The namespace is there to prevent your code from colliding with other code that may be running on the site, which can often cause the dreaded WSOD. You can prefix your functions instead of using a namespace, if that’s easier; ie:
function myprefix_some_function_name() {
}
$some_var = myprefix_some_function_name();
…is equally safeguarded from code collisions as…
namespace myNamespace;
function some_function_name() {
}
$some_var = some_function_name();
yep - i totally get that… but… what happens if you have a pile of little functions in your util plug and 3 months later a new version of CP is released and your site explodes? there may be a more elegant way to troubleshoot with logging, but i’m a dummy and so i just start disabling stuff until my site un-breaks
so can we say that the namespace thingy makes the variables in the function apply to the local scope (the function) rather than global? is that how it works?
With WordPress, it’s common for updates to cause things to explode. With ClassicPress, that’s not a thing – we’re committed to maintaining compatibility with the 4.9 branch. BTW, disabling stuff until it unbreaks is the most common method, I suspect.
The variables, functions, etc. are local to the namespace’s scope, so, any/all files with that same identical namespace declaration will also be part of the same scope, and you can call, say, a get_items() function from within your namespaced scope without worrying that some other plugin/theme/core also has a function named get_items().
If you need to call a namespaced function from within some other (namespaced or global) scope, you do have to prepend the namespace when you make the call.
In one file, you might have:
namespace = MyNamespaceOne;
function get_items() {
}
…and in another file, you might have:
namespace = MyNamespaceTwo;
function get_items() {
}
Let’s also say there’s a get_items() function in the global scope. If you’re in the scope of MyNamespaceTwo and you want to call the get_items() function, you have to specify the scope. Here’s how it works:
// To call a function defined in the same scope.
$items = get_items();
// To call a function defined in another namespace's scope.
$items = \MyNamespaceOne\get_items();
// To call a function defined in the global scope.
$items = \get_items();
In that last example, if the get_items() function were only existing in the global scope, you don’t need the \.
I also prefer keeping site-specific plugin code separated into different files. I usually put these under wp-content/mu-plugins/filename.php - the main difference is that these files are always loaded and there is no (easy) way to disable them.
A variable is local to a namespace’s scope only if the variable is encapsulated by something else too, typically a function. If the variable is created within a namespace but outside of such a function, then it will have global scope. In my view, this is a major weakness of PHP’s namespacing.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.