jcdesign

Mehedi, I appreciate the ability to disable certain Spectra blocks, and overall I think the plugin does a great job, but please add the ability to disable ALL blocks, so we can pick the ones we want. I don’t want to confuse my editors. Thanks!

Okay, I’ve made the following change to classes/plugin.php:

– check that $doc->id is set before using it. If it’s not, use NULL, since the is_default_doc method has NULL as its default value.

FIND around line 106:

'get_callback' => function ( $doc ) {
  return $this->is_default_doc( $doc->id  );
},

REPLACE WITH:

'get_callback' => function ( $doc ) {
  $doc_id = ( isset( $doc->id ) ) ? $doc->id : NULL;
  return $this->is_default_doc( $doc_id );
},

This gets rid of the notice, and checking / unchecking the “Default Help Document” checkbox continues to work as it should.

Hope this helps someone!

cc @markjaquith

@vickita @markjaquith sorry, I was moving too quickly yesterday.

It should be:

	protected function get_cap( $cap ) {
	    if( ! is_object( get_post_type_object( self::POST_TYPE ) ) )
	        return null;
		return get_post_type_object( self::POST_TYPE )->cap->{$cap};
	}

– Need to actually GET the post type object before checking if it’s an object!

@vickita the notice you’re seeing should be hidden if you set WP_DEBUG to false, I was setting up some users to redirect on login, and I was seeing this too.

I added this to fix:

	    if( !is_object( self::POST_TYPE ) )
	        return null;

So the entire method reads thus:

	protected function get_cap( $cap ) {
	    if( !is_object( self::POST_TYPE ) )
	        return null;
		return get_post_type_object( self::POST_TYPE )->cap->{$cap};
	}

Hope this helps somebody. @markjaquith I’m sorry but SVN stumps me; otherwise I’d make submissions to help!

• This reply was modified 4 years, 10 months ago by jcdesign.

I’m seeing this whenever I have WP_DEBUG = true. If you’re seeing this with a generic theme and no other plugins, then it’s a problem w/ the plugin, and needs to be fixed.

Hi @sjnbham, just wanted to chime in and say, this was helpful for me. Until I enqueued the editor style using enqueue_block_editor_assets, I was not seeing styles show up in the block editor, but as soon as I did, they were applied. My style requirements were entirely different, but that hook did the trick.

Removing it via theme functions.php file:

// CoAuthors Plus has a broken filter for titles. 
// We will remove it.
if( class_exists('CoAuthors_Plus' ) ) {
  global $coauthors_plus;
  remove_filter( 'get_the_archive_title', 
  array( $coauthors_plus, 'filter_author_archive_title' ), 
  10 );
}

Hope that helps someone!

• This reply was modified 5 years, 10 months ago by jcdesign.
• This reply was modified 5 years, 10 months ago by jcdesign.

@cartoonsmart2 your response had me wondering, WHY, oh WHY hasn’t this been changed? Because I find it really annoying too.

So I did some poking around.

Turns out that this practice can prevent certain email clients from breaking URLs into un-connected garbage. My guess is that the VAST majority of email clients don’t need this anymore, but as a default at this level, it does kinda make sense.

The bad link is easier to deal w/ IMO than

    https://somelinkhere.com/?goesonforawhile%20=
    &continues_on&anotherline_butGETS&broken%20=
    wherever_theline_wraps

So I’ll live w/ it.

Hi @dilneinovaes, (1) the key word in my answer above is “think” — I thought this is what fixed it, but I was not absolutely sure. Your mileage may vary.

There’s not really a step-by-step answer I can give you beyond what I wrote above, although I can explain it a little better. If you have shell access to your server (or, if it’s local, whatever command line app you use), you’ll want to check the permissions and ownership of the wp-content folder.

Navigate to that folder in the command line and use this command to list files and directories with the verbose setting:

ls -al

You’re looking to see if the user and group look right. This is something you can safely do without making changes. Warning: the next step is not reversible. Be sure you have a compressed backup of your files before proceeding.

Run this command for each directory:

sudo chown username:username -R plugins

… where username is the one you want to own the content, and plugins is the directory. the -R flag means “do this recursively”, i.e. to all files and directories within.

Good luck,
Jeremy

Finally resolved this.

Difficult to say how the plugin was interacting with other factors, but it definitely was making things tricky, and moving it via FTP did not provide a quick fix. Thought Chrome’s aggressive caching might be part of the problem, but I saw it in other browsers, too.

That said, this seemed to be primarily an issue of file permissions and ownership. I was seeing other issues while setting up the dev site, such as missing a minified CSS file. I’d moved many files to a new location using the root user, and my plugins, themes, and uploads were all owned by root. I had to update that:

chown username:username -R plugins

(Okay, actually had to use sudo to do it, and I did this for the other folders, too. Could’ve run it on wp-content folder.)

This cleared up many problems. In fact most of them, and I think this was the main factor which was affecting All In One WP Security & Firewall’s odd behavior.

So, lesson for the day: pay attention not only to file permissions, but also to ownership.

The dev site still doesn’t have a proper SSL certificate, but I got everything working anyway, so I don’t think that was a factor.

Phew.

Upon further research, I agree — this is not related to the plugin. There does seem to be an issue related more to domain-level redirection which is unrelated. If I find a good answer to this, I’ll post it here in case someone else has a similar problem. So not marking resolved yet..

Thanks for responding, but I’m not setting up WordPress in its own folder, so it would be difficult for this to be the issue. (Although down the road, was planning to.)

I have two separate instances of WordPress running, one for the live site & one for the dev site.

This is exactly my question as well. Trying to figure this out…

Thanks @psicotony! I have not really been keeping an eye on this, appreciate your help. I’m wrapping up the next version of the plugin, and I’ve included your fix for the staticMap. Will also be able to style the map.

Just wanted to add, I had this exact issue, and this fix had no effect. I’m vaguely embarrassed to admit it was an old plugin I had installed—WP Firewall 2. Disabling that plugin was all it took… Sigh…