Jer Turowetz

Sure does, thats my code you deployed. Thanks!

Here a fix for the callable: https://github.com/WPChef/limit-login-attempts-reloaded/pull/192

My pleasure! Lovely to see a simple PR assessed and merged swiftly. Really builds confidence in the plugin.

I think the right way to fix it would be to either have stricter validation on the file mime type on the file upload button on the organization tab. Even though WordPress doesn’t support SVG, it does support many other mime types which would trigger the same issue.

That said, you could just add a tiny description above the file upload button saying something like “be sure to use a JPG or PNG” which would lead to less confusion and is a super easy fix.

@romancieciuch I dont think escaping the error right before output is the right solution, as the error is useful to us because the whole point of the SEO plugin is to enrich the site with data. If we didn’t get the error we wouldn’t have known that our org logos were missing from the JSON.

• This reply was modified 3 years, 7 months ago by Jer Turowetz.
• This reply was modified 3 years, 7 months ago by Jer Turowetz.

@romancieciuch I know what the issue is: I bet your company logo is an svg (YOURSITE/wp-admin/admin.php?page=wpseo_titles).

The reason the 2nd argument for generate_from_attachment_meta() is false in my case is because Yoast is failing to resolve $this->context->company_logo_meta in the generate() portion of wordpress-seo/src/generators/schema/organization.php.

A lazy fix for us is switching your org logo to a png. I am sure @maybellyne or @devnihil will get the same results when trying to recreate the issue by setting the company logo to an svg. I also hope they take the resolution of this bug seriously.

Those are really annoying responses, I have the exact same errors here after the update. I’m actually paying for Yoast pro, does that elevate the status of the request?

So my issue was the result of the animated gifs hitting the imagemagick ram limit (they were big gifs) and so WordPress wasn’t creating intermediate sizes.

The issue is that when intermediate sizes don’t get created, the media library uses the full size image as the tumbnale and just scales it down (there were 25+ 1920px animated gifs in a single view slowing everything down).

Ideally, if files are too large for imagemagick (maybe just gifs), an icon would be used instead of the full size image? Thoughts?

Oh man, I just realized I’m answering a question for a plugin… I thought we were in the general support forums haha.

I imagine this would still work for you @pagan11460. Heck, if you’re capable of modifying the files in this way you might not even need this plugin (no offense team white-label-cms).

Hey there!

First off, it’s pretty easy to guess your login url from the url in the ‘background: url’ you posted above. If you’re concerned about this url being exposed, I’d change it to relative (at least for this thread).

As far as retina logos go, I totally remember seeing some kind of retina setup built in to core for the default wordpress logo, but this was a long way back . Looking at the core code now, it seems the default logo uses SVG (with a png fallback) to handle scaling seamlessly.

This is what load-styles.php spits out for the default login screen:

.login h1 a {
    background-image: url(images/w-logo-blue.png?ver=20131202);
    background-image: none, url(images/wordpress-logo.svg?ver=20131107);
    -webkit-background-size: 84px;
    background-size: 84px;
    background-position: center top;
    background-repeat: no-repeat;
    color: #444;
    height: 84px;
    font-size: 20px;
    line-height: 1.3em;
    margin: 0 auto 25px;
    padding: 0;
    width: 84px;
    text-indent: -9999px;
    outline: 0;
    display: block
}

I’d recommend following core’s good example and going SVG with your logo (with a png fallback). If you don’t wanna do that, you can try using a media query to target specific devices.

To do the latter, just start with the same css you were going to use:

.login h1 a {
    display: all;
    background: url(/wp-content/uploads/2017/03/[email protected]) no-repeat bottom center !important;
    margin-bottom: 10px;
    background-size: contain !important;
}

Then add a bunch of media queries to try and flip out to the high resolution logo on devices with a little more density:

@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min--moz-device-pixel-ratio: 1.5),
only screen and (min-device-pixel-ratio: 1.5) {
    .login h1 a {
    // retina code here
        background-image: url('../../custom-logo-2x.png');
    }
}

You might need to mess around with width and height (a 2x image should still be set to the same width as the 1x image) but this should give you the basic idea.

• This reply was modified 7 years, 7 months ago by Jer Turowetz. Reason: i suck at the editor

Hey there!

First off, it’s pretty easy to guess your login url from the url in the ‘background: url’ you posted above. If you’re concerned about this url being exposed, I’d change it to relative (at least for this thread).

As far as retina logos go, I totally remember seeing some kind of retina setup built in to core for the default wordpress logo, but this was a long way back . Looking at the core code now, it seems the default logo uses SVG (with a png fallback) to handle scaling seamlessly.

This is what load-styles.php spits out for the default login screen:

.login h1 a {
    background-image: url(images/w-logo-blue.png?ver=20131202);
    background-image: none, url(images/wordpress-logo.svg?ver=20131107);
    -webkit-background-size: 84px;
    background-size: 84px;
    background-position: center top;
    background-repeat: no-repeat;
    color: #444;
    height: 84px;
    font-size: 20px;
    line-height: 1.3em;
    margin: 0 auto 25px;
    padding: 0;
    width: 84px;
    text-indent: -9999px;
    outline: 0;
    display: block
}

I’d recommend going following core’s good example and going SVGh your logo (with a png fallback). If you don’t wanna do that, you can try using a media query to target specific devices:

.login h1 a {
    // non retina code here
    display: all;
    background: url(/wp-content/uploads/2017/03/[email protected]) no-repeat bottom center !important;
    margin-bottom: 10px;
    background-size: contain !important;
}

// a bunch of media queries to try and target devices with a little more density
@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min--moz-device-pixel-ratio: 1.5),
only screen and (min-device-pixel-ratio: 1.5) {
    .login h1 a {
    // retina code here
        background-image: url('../../custom-logo-2x.png');
    }
}

Hey there!

First off, it’s pretty easy to guess your login url from the url in the ‘background: url’ you posted above. If you’re concerned about this url being exposed, I’d change it to relative (at least for this thread).

As far as retina logos go, I totally remember seeing some kind of retina setup built in to core for the default wordpress logo, but this was a long way back . Looking at the core code now, it seems the default logo uses SVG (with a png fallback) to handle scaling seamlessly.

This is what load-styles.php spits out for the default login screen:

.login h1 a {
    background-image: url(images/w-logo-blue.png?ver=20131202);
    background-image: none, url(images/wordpress-logo.svg?ver=20131107);
    -webkit-background-size: 84px;
    background-size: 84px;
    background-position: center top;
    background-repeat: no-repeat;
    color: #444;
    height: 84px;
    font-size: 20px;
    line-height: 1.3em;
    margin: 0 auto 25px;
    padding: 0;
    width: 84px;
    text-indent: -9999px;
    outline: 0;
    display: block
}

I’d recommend going following core’s good example and going SVGh your logo (with a png fallback). If you don’t wanna do that, you can try using a media query to target specific devices:

.login h1 a {
    // non retina code here
    display: all;
    background: url(/wp-content/uploads/2017/03/[email protected]) no-repeat bottom center !important;
    margin-bottom: 10px;
    background-size: contain !important;
}

// a bunch of media queries to try and target devices with a little more density
@media only screen and (-webkit-min-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min--moz-device-pixel-ratio: 1.5),
only screen and (min-device-pixel-ratio: 1.5) {
    .login h1 a {
    // retina code here
        background-image: url('../../custom-logo-2x.png');
    }
}

• This reply was modified 7 years, 7 months ago by Jer Turowetz.
• This reply was modified 7 years, 7 months ago by Jer Turowetz.

Hey, I’m experiencing the same issue. Notices in the log & in the custom “Compression” column created by the plugin in the media library see here: https://imgur.com/a/TrJuR.

Issue seems to be for anything not an image (pdfs, other mime types).

All plugins disabled, issue persists. Is there a github? If so I can take a swing at it.

Par example:

// Contenu du formulaire
$valueName      = !empty($_POST['AddMediaFromURL_Name']) ? sanitize_text_field($_POST[ 'AddMediaFromURL_Name' ]) : null;

$valueUrl       = !empty($_POST['AddMediaFromURL_Url']) ? sanitize_text_field($_POST[ 'AddMediaFromURL_Url' ]) : null;

$valueUpload    = !empty($_POST['AddMediaFromURL_Upload']) && ( $_POST['AddMediaFromURL_Upload'] === "1" ) ? ' checked' : '';

$service0 = !empty($_POST['AddMediaFromURL_Type'])
            && ( sanitize_text_field($_POST['AddMediaFromURL_Type']) == self::COMBO_OTHER || !isset($_POST['AddMediaFromURL_Type']) )
            ?  ' selected="selected"'
            :  '';

$service1 = !empty($_POST['AddMediaFromURL_Type'])
            && ( sanitize_text_field($_POST['AddMediaFromURL_Type']) == self::COMBO_GDRIVE )
            ? ' selected="selected"'
            : '';

• This reply was modified 7 years, 7 months ago by Jer Turowetz.
• This reply was modified 7 years, 7 months ago by Jer Turowetz.

Stellar Michael! That was speedy!

will get on those changes – thanks.

Sorry, I was unclear before. I meant we already have a ton of data stored via the Taxonomy_MetaData addon. I’m hoping it’s not going to break on upgrade.

Thanks for the trunk link, for the speedy replies, for not giving me crap for being a bit off topic and the absolutely-best-wordpress-plugin ever.