IRD-dev

@takayuki Miyoshi – Thank you!

I also noted a presentation issue that I am hopeful you will be able to address. I have a contact form that is right-aligned to the page edge. When the reCAPTCHA feature is engaged, much of it extends off the viewable area on mobile devices. Hence, my question is: can you build in a configurable feature to offset this issue?

Thanks in advance for your assistance and insight.

@silverporl – see my post in this support thread!

https://www.ads-software.com/support/topic/hidden-features-revealed-framework-not-current

@takayuki Miyoshi – I have opened a new thread for my particular experience / question.

@davmerit – My apologies; I stand corrected.
@takayuki Miyoshi – Thank you for the clarification.

It’s odd that davmerit’s link still does not open for me .. while your’s does. They look identical.

I believe that I have now answered my own question, by performing an inspection of the Theme parent and child directories .. which I first offloaded to my local machine and then leveraged “WinMerge” to perform the full compare (directories, files, contents).

While your plugin does successfully create a “child theme”, it seems to DUPLICATE *every* directory and file from the parent, instead of merely creating a new STYLE.CSS in the child’s root directory with one simple reference to utilize the parent theme’s STYLE.CSS. For example:

@import url("../parenttheme/style.css");

Perhaps also create an empty functions.php in the aforementioned directory as well, as such:

# Empty functions.php file for your childtheme
# The parents functions.php contents will be loaded.
# Add any additional or overwriting functions here.

My point / concern is, especially for those who may be unfamiliar, that the intrinsic behaviour of WordPress is to utilize files that exist in the CHILD directory. Hence, when a Theme core/parent is updated, one’s WordPress site will continue to only load the now-antiquated files in the Child — files that were copied at an earlier timeframe using this plugin.

In summary, once a Child theme is created using this plugin, all future updates to the theme’s parent will be ignored. Proof is in the aforementioned article: https://www.ads-software.com/support/topic/child-themes-and-php-pages

If I am mistaken, please clarify. I just spent the last 30 minutes deleting a s#it-ton of directories and files which this plugin excessively created!

@davmerit – Thanks, however, your feedback is not applicable. And, although I did view the URL which you provided, that page is no longer available at this moment (404 error).

The Placeholder value IS an option and, hence, should be able to exist inline, regardless of position with other options of its kind.

Let’s see what the plugin author has to say.

https://contactform7.com/setting-placeholder-text/

@tim Nash – thanks for the constructive feedback and support.

Hello. I am also experiencing this same issue.

Additionally, if the reCAPTCHA is not completed (unsuccessful or untouched), Contact Form 7 will throw the general error “Failed to send your message. Please try later or contact us via telephone.” Is there a way to detect the specific failure and provide a more accurate error re: reCAPTCHA?

Good to see continued feedback from the community on this topic and overall WP security pros/cons. Some responders wilfully broadened the scope of the discussion and others offered their own understanding of modern-day security concerns and issues.

In regard to my specific concern, not wanting the public to see the WordPress Username on Articles / Posts, here’s what I chose to do in my WP 4.3.1 project:

1) Under Blog & Portfolio Menu > Meta Information ( /wp-admin/admin.php?page=of-blog-and-portfolio-menu ), I disabled inclusion of “Author”.

2) On the NEWS page itself, under “Show advances settings”, I disabled “Show post author”.

This seemed to provide a remedy to the concern I raised initially.

I then went a step further and added two plugins which effectively provided the level of logon security I desired:

1) Installed plugin “Limit Login Attempts” (www.ads-software.com/plugins/limit-login-attempts/). This was a snap to implement and performs well to its name.

2) Installed plugin “Google Authenticator” (www.ads-software.com/plugins/google-authenticator/). This, too, was a snap to implement and will work well for my particular project. I’ve used the Google Authenticator app on my Android smartphones, for several years now, to protect my Gmail, Outlook and other sensitive accounts. In fact, now that I have this working, I no longer see a need for the aforementioned plugin “limit login attempts”.

Lastly, I am contemplating making an additional albeit experimental change, by directly (myPhpAdmin) editing the “user_nicename” database column’s value in WP_USERS table, for the Admin user. Presently, its value is the SAME as the username and I plan to change it to the same value as the account’s Nickname which, in my case, is purposefully dissimilar to the username. This is just in case the “nicename” is shown anywhere within WP or the plugins I’ve engaged.

Thanks to everyone for their feedback, even though we may disagree on some points. I do realize that there are other potential points of entry, such as through a plug-in flaw. However, I still feel it’s best not to blatantly ignore the fact that this intrinsic feature of WordPress continues to warrant discussion.

Smart corporations choose to hide the username, when one’s workstation is locked, forcing the authorized personnel to provide their full credentials each time. Clearly, there is a consensus on the topic of not revealing any portion.

Whilst my question was ultimately to inquire how one may hide the username on articles or similar posts, I am pleased to have provoked passionate responses regarding the evolving security of WordPress.

I will certainly review each of the noteworthy recommendations presented in this thread. Thanks, again.

Aaron, you are 100% correct. Any experienced security admin will also agree. Protecting the username is PARAMOUNT in any security circle. With all of the historical security flaws with WordPress, you would think this to be a top priority. Find a way to hide the username – regardless of it being the WP Admin or any other user.

There are only 2 values needed to gain access .. and WP is providing one of them pro bono.