mistaecko
Forum Replies Created
-
You are probably right!
Starting from PHP 5.3 this should work on Windows as well.
I didn’t really get the meaning of the parameters by reading the PHP docs. Found a better explanation of FNM_PATHNAME here.
If the
FNM_ PATHNAMEflag is set in the Flags parameter, a / (slash) in the String parameter is explicitly matched by a / in the Pattern parameter. It is not matched by either the * (asterisk) or ? (question-mark) special characters, nor by a bracket expression. If the FNM_PATHNAME flag is not set, the / is treated as an ordinary character.If I understand correctly, the difference is this:
FNM_PATHNAME=1 /abc/def/file.txt does *not* match /abc/*.txt FNM_PATHNAME=0 /abc/def/file.txt *does* match /abc/*.txtI would rather expect
FNM_PATHNAME=1behavior. However, the turning it off (=0) could be more powerful. One could do something like/blbla/cache/*.txtand this would ignore all text files in all subdirs of the/blbla/cachedirectory.Or maybe even
*/cache/*.txtWhat do you think?
And, of course, you would then have to match your string (filename, dir name, absolute dir or file path) against each pattern with
if (preg_match("/$pattern/i", $nameOrPath))
The slashes are part of the regex definition, theiis a ‘switch’ that makes the pattern case insensitive.preg_matchwill return the number of matches or0in case of no match. Since we added line beginning and line ending markers there can only be 1 match or none at all, but all int values greater than 0 will evaluate to TRUE anyway.Yeah, I totally understand. Regular Expressions are a beast! 😉
I am not so sure that there would be a lot of people using this feature anyway.
What would really be nice is the wildcard support I guess.
I wonder whether it would make sense to enable simple wildcard support (
*) on the individual fields. This could be done by using regex internally.You don’t really need to understand the detailed syntax of regular expressions to use them to implement wildcard support.
The concept is as follows:
1. Take the user input and run it through preg_quote – this will put a backslash in front of every character that is part of the regex syntax
$input = preg_quote($input);2. Then use str_replace to turn all wildcards into the correct regex syntax – the wildcard
*should match any character, which in regex syntax is.*(dot means any character, and asterix means 0 or more times). We have to consider that in step 1. all asterix wildcards have been prefixed with a backslash
$input = str_replace("\\*", ".*", $input);3. Then add a
^at the beginning and a$at the end. These are the regex markers for line beginning and line ending.I am still reflecting on whether there are better solutions. I had a look around (google) to see if there are any PHP projects or libs out there which have implemented something similar. Sometimes it’s better not to reinvent the wheel. But haven’t found anything convincing yet.
mistaecko
Edit your
.htaccessfile in your wordpress directory via FTP. Just delete the entire section that was created by ‘Better WP Security’. It is marked with comments where it starts end where it ends. (Create a backup of this file before you make changes, just in case).
You should then be able to login to WordPress and change the configuration.
First time you hit save the entire section (but not the entire file) will be recreated.
Problem solved!Thanks, Scott, for looking into this.
I am experimenting with various HTTPS plugins and htaccess rules. So the problem might actually be with my setup and not with your plugin.
First I thought that you might have hard-coded the protocol since this was the only link that did not render the protocol correctly. However, later it started to render correctly.
Right now I experience the same problem in a different part of wordpress (on the login page).
Sorry for the false alarm.
Forum: Plugins
In reply to: Please help! Error establishing a database connectionAfter looking into this problem more I can confirm that there is a bug in the plugin.
*Some* of the generated prefix strings will get mysql confused and break the process, leaving the database in an inconsistent state: the table prefixes will have been renamed, but some values in the options tables not.
This applies at least to patterns that start with a number and include an ‘e’. This is the scientific notation for exponential numbers, e.g.
74e5. There might be other patterns (e.g. hex like prefixes) that could cause problems as well.I have informed the author of the plugin about this bug.
To fix a broken rename process please see my previous post but make sure you use backticks around the table names:
UPDATE `XXXX_options` SET option_name = REPLACE(option_name, 'wp_','XXXX_') WHERE option_name LIKE '%user_roles%'; UPDATE `XXXX_usermeta` SET meta_key = REPLACE(meta_key, 'wp_','XXXX_') WHERE meta_key LIKE 'wp_%';The bug in the plugin is due to missing these backticks in four SQL statements in database.php, namely in line 67, 74, 85, 90.
A fixed version of the database.php file (plugin v2.10) can be found here: https://gist.github.com/1421722
This version should work with ANY prefix, and is tested against
74e5and works!Forum: Fixing WordPress
In reply to: My forum syntax sandbox (IGNORE)backticks `xxx`Forum: Fixing WordPress
In reply to: My forum syntax sandbox (IGNORE)REMOVED
Some hints for others who find this thread
ad (5) dump file to big
use bigdump.php or a similar solution: http://www.ozerov.de/bigdump/
ad (8) server restart shouldn’t be necessary – it’s PHP!
Please also see this thread for a similar problem with the table rename feature.
Forum: Plugins
In reply to: Please help! Error establishing a database connectionBtw, it seems the author of this plugin is currently traveling the world 😉 see http://wordpress.org/support/topic/plugin-better-wp-security-changing-table-prefix-kills-wp-admin
But the link in my previous post details all steps involved in renaming the wp_ prefix manually.
So any rescue attempt should check all these steps and fix those that didn’t go through.
I recommend to *not* use this feature for now, especially on production systems and if you are not familiar with SQL.
mistaecko
Forum: Plugins
In reply to: Please help! Error establishing a database connectionI experienced the very same problem just recently (while the feature had worked well for me before).
Interestingly it happened with a very similar prefix (7e59).
It failed at some point during the name change process AFTER renaming all tables and AFTER setting the new prefix in wp-config.php.
My guess is that the chosen prefix is problematic because it is interpreted by mysql as a hex number.
So while I describe the steps that might make the rename process complete below, it might very well turn out to not fix the problem. You would then have to change to a different prefix altogether (maybe one that does not contain any numbers at all)
You can try to fix it following these steps
(1)
Make sure that all your table names have been changed to the new prefix.
Make also sure that the prefix setting in wp-config.php has been updated to the new prefix value.
In my case these steps actually completed successfully.(2) Fix PREFIX_options table
UPDATE
XXXX_optionsSEToption_name= REPLACE(option_name, ‘wp_’,’XXXX_’) WHEREoption_nameLIKE ‘%user_roles%’;(3) Fix XXX_usermeta table
UPDATE
XXXX_usermetaSET meta_key = REPLACE(meta_key, ‘wp_’,’XXXX_’) WHERE meta_key LIKE ‘wp_%’;Note: change XXX to your prefix
credits to http://tdot-blog.com/wordpress/6-simple-steps-to-change-your-table-prefix-in-wordpressI guess you have solved the problem by now anyway since 2 weeks have gone by, but maybe this can help others.
mistaecko
From how I understand the ‘Hide Backend Options’ feature it works like this:
any request that goes to wp-login.php without the security key attached will be redirected to the ‘not found’ page. This is in order to shut out any malicious requests/attacks that target the login mechanism.
Note that it does NOT redirect requests to wp-login.php to http://www.mysite.com/login (or whatever slug you chose). This would defeat its purpose (hide the login page).Any custom link that points to the login page and wants to use wp-login.php has to either add the security key OR point to the ‘login’ slug.
Not sure why the plugin recommendeds to add the security key since it seems more convenient to just point to the login slug.
If you point the login link in {DW Members Only plugin} to the login slug (http://www.mysite.com/login) it should work. However, it will then redirect to wp-login.php?[key] and this is what is displayed in the browser bar.
The protection here is only to deter automated attacks that are scripted assuming a standard wordpress layout.
Thanks, deleting the wp_options entries did the trick!
The ‘Force SSL Administration’ option works solid now.
mistaecko
Thanks for your quick reply!
No sorry. Still not working. As soon as I activate the plugin I am kicked out, even when I am logged in via https at that time.
(All blurred out parts mention the same host)
This is not a clean/fresh install, so there might be interactions with an older config or another plugin. The .htaccess file is clean though and only contains the standard wordpress index.php rewrite.
I came up with my own handwritten .htaccess based solution so not sure how much time I will invest in troubleshooting this, sorry.
> WordPress (and WordPress HTTPS) has no way of telling if the current page is HTTPS.
Can you elaborate on this a bit?I installed the ‘Force SSL on admin’ on a development server of mine (Apache2 on Ubuntu) and it got stock in the redirect loop on the login page.
If I run a simple test file like this:
<?php if($_SERVER['HTTPS']){ echo 'you are secured'; }else{ echo 'you are not secured'; } ?>it detects the HTTPS connection correctly.
I guess that above file should fail on @newelley’s shared host, and my problem is a different one. Correct?