New answers tagged

0

If you have checked your database entry of the page/article, you will see that it is a issue on Database side, or by any means there was restoring going on because of the crash, that could be an issue or a restoring plugin/script with a bug why a simple character as ' gets messed up. And could you tell in how many cases the character ' got replaced by ...


0

If using it on your own server, I wouldnt recommend using a WP plugin as a base, try to configure fail2ban ( a brief tutorial - https://easyengine.io/tutorials/nginx/fail2ban/ ) , it will work like a charm.


0

I wanted to state, this happened to me a few times in the early WP 3.x days. Am using GoDaddy shared hsoting etc. My solution, i compiled my own HTaccess file(if ur using Apache) against RFI / LFI / SQL injects etc, just very basic ones, disabling the use of base64, bogus image hacks, finger printing and so on. Then you need to check your CHMOD aka ...


0

If you can add fail2ban to the server, try the wpfail2ban plugin.


1

If the "attack" is distributed, the only thing you can do is to change the url of the login endpoint. This should be easy to do with web server config (block /login and friends, map some other "slug" to wp-login.php). This will also break the automatic redirect from /wp-admin to /login which is a good thing in this case. Don't forget to handle xml-rpc as ...


1

Ok i've found the solution. In fact, as i haven't noticed, there is always the hashed mdp, but for now, the logged_in cookie is structured like this : %login%|%timeout%|%sessionId%|%passhached% instead of : %login%|%timeout%|%passhached% This is like this since wordpress 4.0, and the wp_session_cookie integration, the auth method is the same that before ...


2

Nothing (you will ruin some web stats that look at it, but you probably son't care about that) Nothing No. Evil people don't care what is the value otherwise the easiest security measure would have been to change it instead of actually upgrading anything.


1

Any extra code on your server is a theoretical security risk. Instead of checking each plugin and theme if they are security risk even if they are not active, it is much easier to just delete them. This of course should not prevent you from backuping them first in case you will decide that you need them in the future ;)


0

his https://wordpress.org/about/stats/ should be your guide. As you can see more then 30% of wordpress sites run on php which do not meet your requirements. Side note: IMHO if you do not understand encryption enough to use the PHP API directly then hiding after some library will not improve the quality of your encryption, unless of course it is done just to ...


0

Are those requirement equal to those of WordPress core? No, WordPress still runs on PHP 5.2 with few more limitations on top and aims to work on a toaster found at garbage dump. Are those requirements practical for modern PHP hosting? Quite, PHP 5.4 is obsolete (security support ended last year) with lowest supported version being newer 5.5 at the moment, ...


1

Duplicate the post.php in your theme folder. Rename that file as any_name.php Enter the following code at the top of that file. < ?php /* Template Name: Any Name */ ?> Add your php codes to that file. Go to admin panel -- > Create a new page -- > Select your template and publish the page


2

There are two typical approaches, depending on what you need and consider a page. First is a whole page page, HTML markup and everything. In this case the proper way is usually to create a template in your theme (or child theme), following template hierarchy and modify it. Another approach would be to use hooks to insert your changes, which is more typical ...


0

According to the WP_Session_Tokens class documentation, this token is used to validate the user's session. It does this by checking the provided token against the existing session tokens stored in the user meta table for that user. Session tokens are generated using the wp_generate_password function, and are 43 characters long. So no, it should not be ...


0

I think !isset is a more reliable way of testing so I added that: add_filter( 'registration_errors', 'odin_registration_errors', 10, 3 ); function odin_registration_errors( $errors, $sanitized_user_login, $user_email ) { if ( !isset( $_POST['role'] ) || empty( $_POST['role'] ) || trim( $_POST['role'] ) == '' || ...



Top 50 recent answers are included