Forum Replies Created

Viewing 12 replies - 1 through 12 (of 12 total)
  • Thread Starter Simon Foxe

    (@sfoxe)

    Loving the details! Thanks for taking the time to respond and include links – this is how we all get better. Appreciated.

    I re-tested the ‘losing default settings’ on plugin deactivation and confirmed caching was the issue in one specific site.

    Thanks for the information on filtering the final values, and that’s something that I can absolutely use – but my original request and idea was indeed for filtering the default values. The idea behind that is if I know as a theme dev my theme requires images of a larger size than the defaults of 1920×1920 then I can build that ‘imsanity_default_width’ filter into my theme, and deploy the plugin without worrying about modifying the settings. The user could still modify them if needed, but I know that the plugin’s defaults match my theme defaults.

    Thread Starter Simon Foxe

    (@sfoxe)

    That’s useful – I’ll re-test the settings with object caching in mind.

    On the filtering side, I prefer setting things once in code rather than relying on UI changes per build. The plugin defines constants in imsanity.php (lines 31–37) that control defaults. We could override these via filters to align with our theme – for example, increasing max image width for full-width, high-DPI headers.

    We could set these defaults in the parent theme so they’re consistent across sites, and even make it dynamic by detecting the largest registered image size. The same approach applies to quality settings – if images are pre-optimised before upload, we can disable additional compression in code.

    Presetting defaults via code means optimising our site builds and is one less thing on the checklist.

    Reporting same symptoms of unable to save posts. As per @gfamdan87 comment disabling Estimate Reading feature resolves this.

    Thread Starter Simon Foxe

    (@sfoxe)

    Absolutely… great suggestion!

    Typically, I prefer filters as it avoids template incompatibility issues as plugins are updated (like we often face with WooCommerce). Your suggestion is very well received though, and it does solve this immediately which I appreciate. Champion.

    Confirmed 4.0.4 resolved this issue. Thanks for being so responsive on this!

    I’m also seeing this problem with an empty settings page. I’ve gone back through the various releases and the settings page last worked with v4.0.1.

    I’ve tested 4.0.2, 4.0.3 and 4.0.4-rc1 and all fail. The error in chrome devtools is:

    index.js?ver=4.0.2:1 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'call')
        at c (index.js?ver=4.0.2:1)

    The error changes with 4.0.4-rc1 to:

    Font Awesome plugin error when initializing admin settings view TypeError: Cannot read properties of undefined (reading 'call')
        at __webpack_require__ (bootstrap:68)
        at Module../src/Alert.js (Alert.js:1)
        at __webpack_require__ (bootstrap:68)
        at Module../src/ErrorFallbackView.js (ErrorFallbackView.js:1)
        at __webpack_require__ (bootstrap:68)
        at Module../src/ErrorBoundary.js (ErrorBoundary.js:1)
        at __webpack_require__ (bootstrap:68)
        at Module../src/mountAdminView.js (mountAdminView.js:1)
        at __webpack_require__ (bootstrap:68)

    I will roll all sites back to 4.0.1 until resolved. Hope this helps.

    • This reply was modified 4 years, 7 months ago by Simon Foxe.

    I can confirm and agree with what @stefanmeier has posted.

    Despite having disabled the ‘content permissions feature’ in the plugin settings, the plugin is displaying an advertisement in the block editor. It opens every page/post edit and I had two customers call yesterday specifically to complain about this very thing.

    Please rethink your approach to advertising as this is coming across as heavy-handed.

    At the very least, only have the permissions block control (ie: ad) register and display if the “permissions” feature is enabled.

    Thread Starter Simon Foxe

    (@sfoxe)

    Thanks for the fast response! I’ve tracked it down, and that makes SO much more sense.

    The widget areas were using menu widgets, and the menus were using a plugin ‘Menu Icons’ – and this is where the images were referenced.

    Menu Icons is more commonly used to let you include font icon libraries like Font Awesome in your menus, but in this case it was custom PNGs referenced from the Media Library for each menu item.

    Thanks for suggesting this guys, I’d also like to add my enthusiasm for this feature. I’m not using the API key functionality on ANY site yet because of this lack of security.

    I have one Cloudflare account that services multiple clients and domains, thus one API key which could affect completely separate businesses. Too risky until this feature is added.

    Nice work. How about extending that a bit further so it only does it if WP Better Emails is activated, as well as forcing Disable AutoFormat so the output doesn’t have double linebreaks.

    add_filter('gform_notification', 'change_notification_format', 10, 3);
    function change_notification_format( $notification, $form, $entry ) {
    	if (class_exists('WP_Better_Emails')) {
    		// change notification format to text from the default html
        	$notification['message_format'] = "text";
    		// Disable auto formatting so you don't get double line breaks
    		$notification['disableAutoformat'] = true;
    	}
        return $notification;
    }

    @whiteweazel21 – I also find this is broken, even with the filter in place. I’ve tried setting the Gravity Forms email format to either “text” (as per their updated documentation) or “text/plain” (as per above), but no dice.

    Manually editing line #432 of wpbe.php to True gets it working properly, but the formatting of the content is now wrong. There are additional carriage returns and spacing around the content.

    I think this is the best plugin for this functionality, except Gravity Forms not working is a deal breaker. I’ll be using WP Email Template plugin in the meantime until this is resolved.

    Thread Starter Simon Foxe

    (@sfoxe)

    InfiniteWP (http://infinitewp.com/) is a standalone PHP application that allows you to manage multiple WordPress sites from one dashboard. It has a plugin (InfiniteWP Client) which you download from the WordPress Repository to your WP sites. This allows you to securely control that site from your one dashboard. I have ~30 sites I’m managing with it, and this number is increasing exponentially. This allows me to bulk update plugins / themes / wordpress core.

    I’m guessing the method by which the ‘InfiniteWP Client’ plugin searches the site its installed in, and interrogates what needs updating is being blocked by the Better WP Security settings (as detailed in my original post). I have no idea at this stage whether the issue lies with InfiniteWP or Better WP Security, and the workaround listed does keep me using both solutions successfully.

Viewing 12 replies - 1 through 12 (of 12 total)