Forum Replies Created

Viewing 15 replies - 1 through 15 (of 210 total)
  • Thread Starter David Cameron Law

    (@seo-dave)

    Although I solved the issue I first started this thread for (logging Cerber activity to a custom log file) I can see the Cerber log file data isn’t that useful.

    What I was hoping for was Cerber would log ALL malicious activity to the custom log file and then it would be down to the Fail2ban filers to determine how to use the log data. Unfortunately it only logs wp-login.php login failures, but only if the wp-login.php file isn’t blocked by Cerber. I planned to block wp-login.php via Cerber, so nothing would be logged to the custom log file, so pointless having one.

    If Cerber had an option to log all malicious activity I could have collated malicious activity from dozens of domains into one custom log file allowing Fail2ban to block IPs server wide faster.

    For example it would have been a simple case to setup Fail2ban filters to look for an IP that’s posting SPAM comments and when a threshold is reached block the IP from the server protecting dozens of domains quickly.

    Have you considered adding logging all malicious activity to a custom log file?

    BTW I really like what the plugin does, awesome for single WordPress installations.

    Thread Starter David Cameron Law

    (@seo-dave)

    I figured it out by installing on another domain and not hiding wp-login.php etc…, with basic settings I have a log entry added to the log file when a failed login attempt.

    For others who find this when stuck I added the single define to the wp-conf.php file:

    define('CERBER_FAIL_LOG','/var/log/fail2ban-access.log');

    I created a new log file with name fail2ban-access.log under /var/log/ (same location as the fail2ban.log file in Centos 7).

    I set the fail2ban-access.log file to apache:apache with permissions 0666. This should allow all my domains to write to this one log file.

    I also added the new log file to the log file rotation job so it will be rotated on the same schedule as other website log files. Without adding the new log file to be rotated it would increase in size forever which would be a very bad idea!

    Not setup the fail2ban filter rules yet, so it’s only logging failed login attempts so far.

    Thread Starter David Cameron Law

    (@seo-dave)

    Awesome soup, you got it.

    That deserves a 5 star review when I have some spare time, always good to see a plugin developer actively supporting their plugin for free users.

    Your plugin is working perfectly again.

    Appreciated.

    Thread Starter David Cameron Law

    (@seo-dave)

    Updated and tested and sadly jQuery is still loading on the front end. I’m 100% certain it’s this plugin.

    When this plugin is activated and I view the minified/cached js file (created by W3 Total Cache) I get this at the top.

    /*! jQuery v1.12.4 | (c) jQuery Foundation | jquery.org/license | WordPress 2019-05-16 */

    When I run Google Lighthouse I see the two usual vulnerability warnings:

    jQuery@1.12.4 2 Medium

    when IQuery is loaded at the front end, so it’s definitely still loading it.

    I’ve deactivated the plugin.

    You can see the home pages Lighthouse report at https://googlechrome.github.io/lighthouse/viewer/?psiurl=https%3A%2F%2Fseo-gold.com%2F&strategy=mobile&category=performance&category=accessibility&category=best-practices&category=seo&category=pwa&utm_source=lh-chrome-ext with your plugin disabled.

    No jQuery loaded at the front end.

    I’ve reactivated the alternative progressive web app plugin, but it throws out a Browser error

    TypeError: Failed to update a ServiceWorker for scope ('https://seo-gold.com/') with script ('https://seo-gold.com/superpwa-sw.js'): An unknown error occurred when fetching the script.

    Which I haven’t been able to fix.

    Your plugin doesn’t give any errors, (and you are in active development) so if you can fix jQuery loading on the front end I’ll be a happy user again.

    Thanks for trying, appreciated.

    Thread Starter David Cameron Law

    (@seo-dave)

    I’ll look out for the update.

    I’ve marked as resolved based on you plan to fix it.

    Does W3 Total Cache strip double quotes from minified HTML now? Pretty sure it didn’t used to do that.

    Couple of updates ago (I use the free version) there was a ‘bug’ stripping both single and double quotes out of the minified HTMl code and this broke functionality on my sites (had to downgrade to an older version of the plugin otherwise some inline javascript broke).

    The single quote issue appears to be fixed (no longer breaking the inline javascript) in the latest version (0.9.7.2), but some (not all) double quotes are still stripped and though functionality remains I don’t like it.

    View source of any page at https://www-news.co.uk/ (runs under version 0.9.7.2) and the code in quote terms is a mess!

    All HTML code when unminified is either single or double quoted, but W3 Total Cache is removing some of the double quotes, looks random! I really don’t want the double quotes stripped from my code.

    Based on Marko’s reply above it sounds like the plugin is supposed to do this! Is that right?

    Thread Starter David Cameron Law

    (@seo-dave)

    figured out a much better solution to the manual support above. Couldn’t get the above to work in a way that created responsive images or the noscript code anyway.

    Filtered my custom image function with:

    apply_filters( 'post_thumbnail_html', custom_theme_image_function(.........) );

    Since Rocket LazyLoad adds a filter to post_thumbnail_html the lazyload code is added to the custom image function, no need for manual support.

    Plugin Author David Cameron Law

    (@seo-dave)

    I removed the plugin from the repository, see https://wordpress.org/support/topic/plugin-removed-from-repository-3/ for reason.

    Development continues at https://seo-gold.com/display-widgets-plus-plugin/ under a slightly different name: dropping SEO in the name.

    Plugin Author David Cameron Law

    (@seo-dave)

    I’ve created a new Display Widgets update (v4.0.0) as a direct replacement for the now closed Display Widgets plugin (free download at https://seo-gold.com/display-widgets-plus-plugin/) and will later create a premium version of the Display Widgets Plus plugin.

    Since I’m not adding plugins to the repository anymore had to find a way to offer automated updates (like the repository) and have added the YahnisElsts Plugin Update Checker to the v4.0.0 code from https://github.com/YahnisElsts/plugin-update-checker (so when I do updates they’ll show on the Dashboard Update page like any plugin).

    The new Display Widgets plugin (v4.0.0) is the Display Widgets SEO Plus v3.0.0 code with some of the BuddyPress and bbPress widget logic removed, so this is a significant feature update to Display Widgets v2.05/v2.7 plugin.

    Fixes all the bugs I’ve found including the broken WPML language plugin support and includes the following widget logic:

    * Static Front Page – is_front_page()
    * Home Page Archives – is_home()
    * Category Archives – is_category()
    * Specific Categories : New v4 Feature
    * Posts Within Specific Categories : New v4 Feature
    * Tag Archives – is_tag()
    * Dated Archives – is_date() : New v4 Feature
    * Author Archives – is_author() : New v4 Feature
    * Search Results – is_search()
    * Archives – is_archive()
    * Posts – is_single()
    * Static Pages – is_page() : New v4 Feature
    * Specific Static Pages
    * Attachment Pages – is_attachment() : New v4 Feature
    * Singular Pages (Posts, Pages, Attachments) – is_singular() : New v4 Feature
    * 404 Error Page – is_404()
    * Custom Taxonomy Archives – is_tax()
    * Custom Post Type Archives – is_post_type_archive()
    * Specific Custom Post Type – via get_post_type()
    * Full WPML Language Plugin support : New v4 Feature
    * Basic BuddyPress Plugin support – is_buddypress() : New v4 Feature
    * Basic bbPress Plugin support – is_bbpress() : New v4 Feature

    The above is what I’d have released on the plugin repository had I been able to adopt the Display Widgets plugin a few months back.

    Since the plugin isn’t in the WordPress plugin repository support requests should be directed to my site above (via the comments) not here.

    Almost signed my name at the bottom again: one of the WordPress support forums unwritten rules, you can’t add your name to comments!

    @ipstenu
    “David, stop signing your posts. We can see who you are, and we’ve asked you to stop this before.”

    As far as I’m aware I haven’t been “asked to stop this before”.

    Very strange rule, you can’t add your name (like David or David Law) to the end of a comment!

    You might want to add that rule here: https://codex.wordpress.org/Forum_Welcome#Signatures which says nothing about not using your name.

    Signatures

    Using your WordPress.org profile for advertisement in posts unrelated to your themes and plugins is discouraged. This includes signature links and URLs in display names.

    As requested I will no longer link to the 2.7 zip file from this forum, again weird as it’s public info and means those wanting to do a manual update via FTP, can’t!

    After this post I’ll be unsubscribing from the Display Widgets forum and leave it to you to sort out the support mess.

    I had a look at the 2.7 zip file (downloaded about 12hrs ago) and as Mika said both the readme.txt file and the display-widgets.php file have been changed to v2.7 (as the plugin team reported).

    Can also see at https://plugins.svn.wordpress.org/display-widgets/tags/2.7/display-widgets.php and https://plugins.svn.wordpress.org/display-widgets/tags/2.7/readme.txt they have the 2.7 info.

    Don’t know why the upgrade notice would still show 2.05 (you aren’t the only person to post about this in the forum) and require a manual modification???

    To be sure you have removed the malicious 2.6.* code try loading (changing the domain to your domain)

    http://domain.com/wp-content/plugins/display-widgets/readme.txt

    Should have a line: Stable tag: 2.7, identical to this file https://plugins.svn.wordpress.org/display-widgets/tags/2.7/readme.txt if anything is different investigate further.

    and

    http://domain.com/wp-content/plugins/display-widgets/geolocation.php

    That should be a 404 error page unless you uploaded the 2.7 plugin files using FTP, if you uploaded via FTP I suggest deleting the entire /display-widget/ directory and upload a new one (from the clean 2.7 zip file) so it is 100% safe.

    If you get a PHP error loading the geolocation.php file similar to:

    "Fatal error: Call to undefined function add_filter() in /home/####/public_html/#####/wp-content/plugins/display-widgets/geolocation.php on line 243"

    You might still be running the 2.6.* code (or see above about FTP).

    Wild Speculation Warning Start….

    The hacker could have modified the WordPress upgrade process on some sites to stop normal upgrades, but set the hack to show v2.05 as the hacker wouldn’t have known in advance if the plugin team were going to go with downgrading to v2.05 (keeping the version number) or going with another version (2.7, 2.7.0, 3.0.0 etc…).

    If I were a hacker that would have been my approach, guess what the plugin team would do (v2.05 would be a logical choice) and add a contingency to stop the v2.6.* code from being removed by renaming it v2.05 when the upgrade process kicks in.

    To check this see if there’s a geolocation.php file within the /display-widgets/ directory AFTER running the WordPress plugin upgrade process.

    Wild Speculation Warning End….

    IMHO there should have been a forced security upgrade to v2.7 on all sites, there will be tens of thousands of users who won’t upgrade for days/weeks/months/ever.

    [removed]

    The plugin is closed permanently which is why the main plugin page goes to search (closing it that way makes life harder for users IMHO).

    I’ve put a full list of safe download sources in a comment at https://stallion-theme.co.uk/display-widgets-plugin-review/#comment-48619 I’ll update the comment if anything changes.

    The Display Widgets Plugin version 2.6.* (including v2.6.3.1) contain malicous hacking code putting your site at a serious security risk.

    Display Widget users should remove ALL 2.6.* versions of this plugin, the only safe version is v2.05 see

    https://wordpress.org/support/topic/display-widgets-plugin-v2-6-3-1-includes-hacking-code/

    David Law

    The Display Widgets Plugin version 2.6.* (including v2.6.3.1) contain malicous hacking code putting your site at a serious security risk.

    Display Widget users should remove ALL 2.6.* versions of this plugin, the only safe version is v2.05 see

    https://wordpress.org/support/topic/display-widgets-plugin-v2-6-3-1-includes-hacking-code/
    [ Signature moderated ]

    @displaywidget account has been blocked (banned) so he won’t be able to respond here anymore.

    Display Widget users should remove all 2.6.* versions of this plugin, the only safe version is v2.05 see https://wordpress.org/support/topic/display-widgets-plugin-v2-6-3-1-includes-hacking-code/

    [ Signature moderated ]

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