Rongo

@tkserver you can just do what many others have done and install “Disable Gutenberg”. It’s a single plugin from developer Jeff Starr. It works like a charm and, more importantly, doesn’t expire in 2022. It also eliminates the need for “classic” plugins completely.
https://www.ads-software.com/plugins/disable-gutenberg/

Thanks Predrag. Hopefully that addition is added sooner than later. Beyond checking for links in shortcodes, this plugin has become a must have. Having the ability to search shortcodes would be very welcome.

Incidentally, WordPress is reporting

Warning: This plugin has not been tested with your current version of WordPress.

I can confirm it is indeed working for me on WordPress 5.7

Thanks. And yes, understood that it’s just one line of code. Would have just been nice (and logical), to have some consistency in the wp-config as it pertains to auto upgrade functionality, since it is related.

I’ll go ahead and use the plugin option. Perhaps at some point the Devs will expand the directives available to wp-config, especially ones related to core functionality and/or behaviour.

Thanks again.

• This reply was modified 5 years, 11 months ago by Rongo.

Samuel, thanks.

Hmm, so in the end, WP does not provide a directive to be added to the wp-config file?

Example:

define( 'AUTOMATIC_UPDATER_DISABLED', false );
define( 'WP_AUTO_UPDATE_CORE', false );
define( 'DISALLOW_FILE_MODS', true );
define( 'auto_core_update_send_email', false);

Does that not seem logical to place it with other similar directives governing “update” functionlity?

I’d MUCH rather have a fixed directive than a plugin to alter core functionality.

• This reply was modified 5 years, 11 months ago by Rongo.
• This reply was modified 5 years, 11 months ago by Rongo.

Thanks, but you’re right, adding filters in wp-config is not ideal. I’m hoping there is an actual directive to toggle it on/off, not unlike toggling automatic-updates on/off. The idea of using a plugin for something that should be a simple true/false directive is not exactly appetizing.

Thanks. I don’t want to rely on theme functions as themes change among clients. Which means I have to add a functions.php edit for every theme activated or tried.

There has to be a simple means of toggling email notices wordpress updates on or off, and the most logical place would be a directive in wp-config.

An hopeful for a wp-config directive.

If you read the OP, you will see what I am saying. Unless they have changed it recently, all versions after 2.71 have this “prevent self destroy” limitation. Thus, the plugin will NOT let you change the URL of your existing site from http to https doing a simple search and replace. It’s ridiculous to not be able to say, “I understand the risk, do it anyway”.

I understand the reasoning that this is done to prevent the less technical from destroying their site, but the logic is flawed. For the less technical, they are now required to change a table prefix and export/import. If they don’t have the capability to read “Warning, this could destroy your site”, it’s a stretch to think they’ll understand how to do it with changing table prefixes and import/export procedures.

For the more technical, the limitation just makes it a pain in the ass to use and, thus, it’s just easier to do some Search and replaces from the command line. As such, the changes to plugin are less useful for the more technical who merely wanted a simple search and replace utility.

That said, for those who actually want a fully functional search and replace plugin, with the limitation to prevent self-destroy, they need to use Search-And-Replace plugin version 2.71 or earlier.

If the authors have actually permitted the ability to do the above in a more recent version, then I stand corrected. But the last version I tried would NOT write changes to the database to do a simple change from http to https. I ended up doing it via command line.

• This reply was modified 7 years, 10 months ago by Rongo.
• This reply was modified 7 years, 10 months ago by Rongo.

Rene, no, I am not wrong. I wanted something simple to let me do a search and replace for http to https. Your plugin USED to let me do that. Older versions of your plugin work.

I understand you want to make sure no one can screw up their install. But that’s the entire point of the dry run. If anyone uses the plugin and doesn’t back up their db first, then that’s their own fault. Even adding a prompt for “Are you sure?” would be better than requiring a table prefix change, export and import procedure.

Consider this. You have removed the functionality from this plugin in order to prevent the less technical from destroying their database. BUT, then you expect them to have the technical knowledge to change prefixes and do import / export functions. It’s flawed logic.

This plugin used to be very useful for the technically inclined and/or developer who did not want to do a series of command line SQL queries. I assume your target demographic is/was this one.

The dry run is a fantastic addition. The lack of functionality to make any real changes, such as URL changes, is prohibitive. If I have to change table prefixes, export and import, I may as well just do it via the command line. And that’s exactly what I did as your plugin now is prohibitive to making any real changes.

Your older version, Version 2.7.0 (authored by Frank Bültge) allows people to do what they expect to do, search and replace whatever they want — at their own risk. And it’s the one I recommend people use who still want a fully functional utility.

• This reply was modified 7 years, 11 months ago by Rongo.
• This reply was modified 7 years, 11 months ago by Rongo.
• This reply was modified 7 years, 11 months ago by Rongo.
• This reply was modified 7 years, 11 months ago by Rongo. Reason: typos

Forget the above request. Found an older version where Search and Replaces actually does a search and replace again.

This used to be such a useful plugin before they removed the ability to actually write the changes to the database.

Thanks for the tip on “Better Search and Replace”. I’ll advise the companies I work with to give that one a try instead.

@tepelstreel: thanks for the tip. It was indeed an easy enough edit to allow for larger images.

For anyone in need of the ability to use larger images, it’s a pretty easy fix:

1. In the plugin folder, go into the class-lib sub-folder
2. Open the file RIF_AdminClass.php in a plain text editor
3. On line number 232 (or near there), locate this code:
   if($newinput['image_size'] > 999) :
4. Replace 999 with whatever you want as your longest side (for example, 1600)
5. Save it and upload it

That’s it. Now your featured images will scale anything larger than 1600 down to 1600. And anything 1600 or less will be full original size.

Please NOTE, as this is a code edit, anytime you update this plugin, you will need to re-edit the file.

@tepelstreel: perhaps as a suggestion, make the 999 a variable, %featured_size%, that can be entered into a field on the plugin’s settings page. This would permit anyone to use whatever sizes they needed, while still providing a default of 200 for those that do not.

@tepelstreel: thanks for the reply. Perhjaps a feature request could be an admin option to “Use Original Image Size: yes/no” and if no, set the size you prefer.

Alternatively, perhaps using 0 as the maximum size could be the toggle.

We use feeds with original sizes to populate some of our hub sites, which can then import the full size image and create the thumbs from it according to that specific site’s media settings. Thus, we’re not using it for use with feed readers, but rather to populate our other sites with specific updates.

Your plugin is actually such a useful plugin that it is one we’d certainly pay for. Insofar as plugins go, some are just worthy of being premium, and this is one of them.

Thanks again for the reply.

philsp: same concerns here.

Arnee, will you consider an option to write out the files statically. Frankly, I have little interest in having sitemaps generated on every request dynamically considering how often bots are hitting and indexing my sitemaps.

At the absolute very least, I would assume you should write them out for caching purposes.

Some of us have heavy traffic blogs (more than 100,000+ uniques a day) and having dynamic output on each request is certainly not ideal, more especially without caching.

acmdesigns: We’ve since starting using Social Media Feather. So far it appears clean, there is no data mining at play that we can tell, there is no running data through 3rd party servers, no redirecting via 3rd party servers to mine data, etc.

Granted it doesn’t included related content, but it does what it does extremely well — provide a very lightweight footprint that is fast loading, and all localized on your own server.

Incidentally, there was a discussion about the practices and concerns brought about Shareaholic practices, and to their credit, Shareholic addressed some of the concerns. The thread can be found here:

https://www.ads-software.com/support/topic/duplicates-in-related-content?replies=12

Having said that, we’ve migrated all of our clients and services away from Shareaholic entirely.

ETA: cloudfront is Amazons’s cloud service which is where they store data and files. While Amazon is a solid service, we simply refuse to use Shareaholic going forward.

Jay, thanks for reaching out. I am away for the weekend but will certainly contact you by Monday.

Incidentally, I was not speaking to the passing of PageRank. I was speaking to the issue of link density/value. Rather than linking directly to one’s content, which provides for a natural progression of information internally, the link is instead sent offsite (outbound link) then redirected back to the site as an inbound link, via your traffic / analytics server. Ultimately, this is still an outbound/external link.

In any case, I will speak with you directly. Thanks again for reaching out.