Forum Replies Created

Viewing 15 replies - 1 through 15 (of 27 total)
  • @aioex I have just come across your question, and was wanting to do similar – change references to “Wordfence 2FA” to something else – my users don’t need to know this feature is provided by a specific plugin.

    I’ve found a Plugin called Say What? which allows you to change certain bits of text – thankfully Wordfence is pretty much completely translated, so this plugin works here.

    I have configured a translation as follows for your specific question regarding the login screen:
    Original string: Wordfence 2FA Code
    Text domain: wordfence
    Replacement string: Two-Factor Authentication Code

    Additional strings can be found by searching in the source code for the text – where there’s bigger strings with bigger descriptions you’ll have to override the whole thing, you can’t just change part of the text – but for now, this seems a sensible thing, until Wordfence introduce the ability to set a custom phrase to override “Wordfence 2FA” with something more useful.

    Oh… wow… that seems to have made a big difference on my site, even with 2.6.14 🙂

    Thanks!

    Thread Starter ConfusedTA

    (@confusedta)

    Hi Mike,

    Thanks for your response 🙂

    I’ve managed to get a filter appearing in the list of groups, and a meta_key placed against users, which looks to be correct!

    For reference (in case anyone is searching for similar in the future), the code I used is below.

    Contexture Page Security has an optional expiration date for group membership, and when it has expired, the users still appear as a group member, so a little logic needs to be applied to determine whether they are current or expired.

    add_action( 'mailusers_group_custom_meta_filter', 'send_to_current_members', 5 );
    
    function send_to_current_members()
    {
        mailusers_register_group_custom_meta_filter('Current Members', 'currentmember', true);
        mailusers_register_group_custom_meta_filter('Expired Members', 'expiredmember', true);
    }
    
    add_action( 'mailusers_update_custom_meta_filters', 'update_currentmembers_meta_filter', 5 );
    
    function update_currentmembers_meta_filter()
    {
        // My Contexture Page Security Group ID is 4
        // Go to Users->Groups to see the ID for your group
        $ctxps_group_id = 4;
    
        // Define the meta_key used to denote current and expired members
        $cm_mk = 'currentmember';
        $em_mk = 'expiredmember';
    	
        //  Remove all instances of the Current Member and Expired Member meta keys
        $uq = new WP_User_Query(array('meta_key' => $cm_mk));
        foreach ($uq->get_results() as $u)
        {
            delete_user_meta($u->ID, $cm_mk);
        }
    	
        $uq = new WP_User_Query(array('meta_key' => $em_mk));
        foreach ($uq->get_results() as $u)
        {
            delete_user_meta($u->ID, $em_mk);
        }
    	
        // Get a list of all users who belong to the specified group
        $uq = CTXPS_Queries::get_group_members($aoc_ctxps_group_id);
    
        //  Loop through the users who are members of the group and check
        //  whether they are still current or expired
        foreach ($uq as $u)
        {
            if(!is_null($u->grel_expires))
            {
                // An expiry date has been set for this user
                $timestamp = strtotime($u->grel_expires);
                if ($timestamp < time()) {
                    // Expiry is earlier than Now, this user is Expired
                    update_user_meta($u->ID, $em_mk, true);
                } else {
                    // Expiry is later than No, this user is still a current member
                   update_user_meta($u->ID, $cm_mk, true);
                }            
            } else {
                // No expiration is set, this user is a member
                update_user_meta($u->ID, $cm_mk, true);
            }
        }
    }

    I will add check-boxes for the two options into the WooCommerce dashboard, and look at hooking into wp_mail() to check recipients against the meta values created by this plugin.

    Thanks!

    Garry

    Thread Starter ConfusedTA

    (@confusedta)

    OK, thanks, I’ll give the email route a go in the short term 🙂

    Garry

    Thread Starter ConfusedTA

    (@confusedta)

    That’ll be great 🙂

    In the meantime, a simple URL parameter for the Admin page would be sufficient!

    Such as:

    /wp-admin/admin.php?page=events-manager?status=draft

    Thread Starter ConfusedTA

    (@confusedta)

    I don’t understand 🙂

    These are replacements used during the output from plugin?

    How could I add an item to my main menu (so that it’s accessible from whatever page my Admins are on in the front-end) which applies that filter automatically when first visiting the Admin page?

    Thread Starter ConfusedTA

    (@confusedta)

    Just updated, error gone!

    Thanks for the quick response!

    Hi Robin,

    I completely forgot about this until it was bumped up again.

    The storage location does store it elsewhere, but it still does not use my ‘static’ URL.

    My wp-content directory is set (via Settings -> Media -> Full URL path to files) to http://static.url.com

    This plugin, however, still references http://url.com as the base and the CSS file will not be served by my NGINX server, nor automatically minimised for me.

    Other than that – I have not yet had to re-create the CSS file since you implemented the fix and the redirection to another folder.

    Hi Robin,

    Sometimes the simplest solutions are the best!

    Would it be possible to add an option to allow saving to a specific location (or just a checkbox for saving to uploads), so that those of us who do wish to tweak in that way can do so, whilst leaving the default mode of operation as it is?

    Thanks for your quick responses!

    Hi,

    I too am experiencing the same issue – the automated update of the plugins via WordPress renames the old plugin directory, extracts the new one, then deletes the old (renamed) directory, thus resetting the contents of the plugin directory to that of the .zip stored on WordPress’ servers.

    I have noticed this both using the WordPress Updates bulk-update page, as well as by pressing Update on the Plugins page. You will not notice this if you upload the plugin directly to the server’s filesystem via FTP/SSH (as you will not be deleting the directory, as the automated updates do).

    By navigating to the plugin’s settings page (which, by the way, why is it a sub-menu item in Settings and not Appearance?) and then pressing Save on any of the pages, will re-create the .css file.

    One way around this is to store the version of the plugin as an Option in the database, and then compare this value to a constant within the code. When the plugin is loaded, it will compare these two values, and if there is a mismatch, you can re-save the .css file, as well as update the version value within the database.

    This will then resolve this issue, without requiring the manual step to press Save – which will be forgotten 3 months down the line!!

    Here is a page which explains why this process is necessary, including links to the WordPress blog for further information. This page talks about adding database options for plugins, but due to the way that this plugin works by requiring to create the .css file following an update. I hope you’re not hooking into the plugin activation hook for this – as it doesn’t fire any more on any updates – only on initial installations! 😉

    Another way around this will be to store the .css file in another folder – maybe wp-content/uploads/ – for people who have tweaked WordPress for performance purposes, this folder is often located on a separate server/sub-domain designed to serve static files (using NGINX rather than Apache), or on a CDN, which also often employs automatic minifying of static files such as CSS. The plugins folder is often not stored on a “faster” server, so requiring the .css file (which is also full of whitespace) to be loaded from the “slower” plugins directory can cause performance bottlenecks within the website – I’m sure that’s not something you want attributed to your otherwise awesome plugin!

    Garry

    i guess that it is a unique reference to allow the store owner to order the correct item.

    This is a change I had not noticed until seeing this thread – and without resorting to adding custom fields (of which the method to do so is liable to change with changes to the WC core) having an SKU for each product, including external ones, seems like a sensible option that does not seem sensible to remove…

    Thread Starter ConfusedTA

    (@confusedta)

    Having it as a separate entry will allow for colour customisation etc too – but I’ll leave it as your choice, as it’s your plugin, and you need to maintain it, after all!

    (And, I probably will leave it at the same font size as the rest of that section anyway!)

    Thanks!

    Thread Starter ConfusedTA

    (@confusedta)

    Hi,

    That appears to work – it would be nice to see some additional bbPress specific settings in the theme options in the future, like there is for WooCommerce.

    Thanks!

    Thread Starter ConfusedTA

    (@confusedta)

    I have found that guide, and actually incorporated that previously – an update at ~2.4 broke it, and now any time I edit a variation, my custom field gets cleared.

    Thread Starter ConfusedTA

    (@confusedta)

    The custom fields box is not available per variation, though?

    I have variations stored in different places (as we add additional variations, the only available shelf space could be on the opposite side of the warehouse).

Viewing 15 replies - 1 through 15 (of 27 total)