alderete

Hmmm, a quick look through the code on Trac, and I think my real issue is that I have Jetpack installed and activated. It seems like the XML-RPC service checks for this, and won’t activate if that (or other XML-RPC-dependent plugins) are active?

I also found the .htaccess rule to add manually, in …/templates/xml-rpc.tpl. Which I’ve done, and tested manually. (Both via direct URL access, and running the WPScan test again.)

I notice that the SG Security plugin is not noticing that I’ve added the rule. For whatever reason, the ‘enabled’ regular expression must be failing. Here’s the exact contents I added to my .htaccess file:

# SGS XMLRPC Disable Service
<Files xmlrpc.php>
    order deny,allow
    deny from all
</Files>
# SGS XMLRPC Disable Service END

Plus blank lines before and after.

In case it’s useful, the site I’m testing against is https://aldosoft.com/.

• This reply was modified 3 years, 5 months ago by alderete.

@stoyangeorgiev Ah, that starts to explain it. There does seem to be an issue here, but it’s not compatibility between the two plugins. It turns out that SG Security isn’t actually disabling XML-RPC on my site.

I think there are two bugs/opportunities for enhancement here.

1) The XML-RPC setting defaults to on. (Correct? I don’t remember needing to enable it.) However, when the plugin is activated it doesn’t check to see if it was actually able to add the .htaccess rule. It just shows the setting enabled, even though no such rule exists in my .htaccess file.

2) When I disabled the SG Security setting for XML-RPC, and then tried to re-enable it, I get an error that it can’t be enabled. “ERROR. Failed to enable XML-RPC.” And the setting remains disabled.

I suspect that the issue is that I’ve manually added a couple of rules to my .htaccess file, and that the plugin’s parser is erring on the side of safety, and not making changes when it can’t be certain it’s not going to break anything. (Yay!)

Seems like the top priority would be making sure the plugin notices errors when it activates settings during initial plugin activation. That’s a genuine bug.

The opportunity for enhancement is to be able to handle .htaccess files that have been touched by more than just WordPress plus the two SiteGround plugins.

For now, I can work around this, and just add the rule manually. Uh…any chance you could provide the right rule here…? (Or, better yet, in the plugin documentation.)

Thanks!

Wow, that worked and it’s easy to implement! Thank you!

One note, worth including for future searchers, is that you need to edit existing posts and hit the Update button to force Jetpack to pre-render the post again with the new filter in place. If you don’t do this, Enlighter can’t “see” the GFM fenced code blocks, because the new filter only takes effect on new saves.

And, one minor bug, the inline regular expression works great for inline code in the middle of a sentence, but skips it if it’s at the end of a sentence, followed by punctuation such as a period or colon. For example (Markdown backticks escaped into quote marks):

Works great:

... whatever you can put in an ?if()? or ?elseif()? statement.

Doesn’t work:

Again, this goes into ?custom_functions.php?:

I can easily work around this, and don’t really need rich syntax highlighting for inline code anyway. But, I noticed it.

• This reply was modified 4 years, 2 months ago by alderete.

Ummm… Nevermind.

(It turns out that I have the Redirection plugin installed, and it automatically captures the permalink changes and creates hidden redirections to preserve old URLs. I deleted them from the database, and now it’s working fine.)

Sorry!

You’ve basically written echo(“X” . echo(“Y”)), which is always going to print “YX” to the screen, because echo() emits its arguments immediately, which is before you want it to do so. You will _never_ get the results you expect when you embed an echo statement inside another echo statement.

In your postimage() function, try _returning_ the value you want for the image reference, instead of echo()ing it in the function itself.

macmanx, sorry for not including live URLs, I haven’t made the WordPress version of my blog live yet, it’s just a localhost version where I’ve got aldoblog.wp set up as an alias to localhost.
rboren, that sounds like the problem, just a bug. Not a huge deal, I’m not planning on using the archive links, but I would like the calendar, eventually.
Thanks!