cokeyblokey

Resolved. For some strange reason the site was missing .htaccess file. I’ve put that in place and now plugin working as expected!

Hi @jenwhitedesign,

Probably too late to help but thought I’d post a simple solution for you just incase.

To use the ALT tag of the original image, all you needed to do was to replace:

<?php echo esc_attr($image['alt']); ?>

with:

<?php echo esc_attr($image['original_image']['alt']); ?>

nothing more needed. So your original code would become this:

<?php
   $image = get_field('cropper');
   if( !empty( $image ) ): ?>
	<img src="<?php echo esc_url($image['url']); ?>" alt="<?php echo esc_attr($image['original_image']['alt']); ?>" />
<?php endif; ?>

• This reply was modified 2 years, 3 months ago by cokeyblokey.

I’ve now realised that it must be something to do with my clients PayPal account.

When I use my own, in Sandbox mode, the postage costs are applied as they should be. When I switch it back to my clients account I get the issues described above.

Given that the author has formally abandoned this plugin and the plugins team has removed it from the repository, I strongly advise that you simply delete it from any sites on which it’s used and find another plugin. Perhaps, Advanced Custom Fields?

100% agree! I’ve given a pretty good description of how to move to ACF, above.

Maybe a fix for anyone using Simple Fields that hasn’t yet had it hacked, OR anyone who has a backup of their database, taken before the plugin got hacked and is able to restore the DB after getting hacked.

According to the information given here (and posted earlier by @kjy112):

https://www.pluginvulnerabilities.com/2019/09/16/hackers-may-already-be-targeting-this-persistent-xss-vulnerability-in-simple-fields/

The problem lies in the file ‘/inc-admin-options-export-import.php’

Now, unless I’m mistaken the following should work:

comment out line 30 of that file (or even remove altogether):

add_action("admin_init", array($this, "maybe_do_import"));

then comment out everything (or even remove altogether) from line 34 through to line 99, should stop this particular vulnerability:

	function maybe_do_import() {
		
		if ( isset($_POST) && isset( $_POST["action"] ) && ( $_POST["action"] === "simple_fields_do_import" ) ) {
			
			if ("file" === $_POST["import-what"]) {

				if ( empty($_FILES["import-file"]["tmp_name"]) || ! is_uploaded_file($_FILES["import-file"]["tmp_name"]) ||  $_FILES["import-file"]["error"] !== 0 ) {
					wp_die( __("Import failed: something went wrong while uploading import file.", "simple-fields") );
				}

				$import_json = file_get_contents( $_FILES["import-file"]["tmp_name"] );

			} elseif ("textarea" === $_POST["import-what"]) {

				$import_json = stripslashes( $_POST["import-json"] );

			}

			// We have JSON contents from file or textarea
			// @todo: create function of the next part
			$arr_import = json_decode($import_json, true);
			if ( is_null( $arr_import ) ) {
				wp_die( __("Import failed: JSON data is not valid.", "simple-fields") );
			}
			
			$arr_field_groups = isset($arr_import["field_groups"]) ? (array) $arr_import["field_groups"] : array();
			$arr_post_type_defaults = isset($arr_import["post_type_defaults"]) ? (array) $arr_import["post_type_defaults"] : array();
			$arr_post_connectors = isset($arr_import["post_connectors"]) ? (array) $arr_import["post_connectors"] : array();

			$import_type = $_POST["simple-fields-import-type"];
			/*
			$import_type:
			replace
			overwrite-append
			append-new
			*/
			#sf_d( $arr_import, '$arr_import');
			
			if ( "replace" === $import_type) {
				
				// Just update our options with 
				update_option("simple_fields_post_connectors", $arr_post_connectors);
				update_option("simple_fields_groups", $arr_field_groups);
				update_option("simple_fields_post_type_defaults", $arr_post_type_defaults);
				
				wp_redirect( add_query_arg( array(
					"sf-options-subpage" => "import_export",
					"message" => "import-done"
				), SIMPLE_FIELDS_FILE ) );

				exit;

				//simple_fields_register_post_type_default($post_type_connector, $post_type);
				
			} else if ( "append-new" === $import_type) {

				// import new fields
				// i.e. fields with slugs that do not exist in current data
				

			}

			exit;

		}
	}

Be warned though – the article I’ve linked to warns of other possible vulnerabilities in the plugins code. So this may not be a strong fix.

EDIT (while my post is held for moderation): Just seen that Par, the plugin author, has replied – his post must have gotten held for moderation, and he’s basically saying the same as I have above.

• This reply was modified 5 years ago by Steven Stern (sterndata).
• This reply was modified 5 years ago by cokeyblokey.
• This reply was modified 5 years ago by cokeyblokey.

Had this on 3 older sites now. My method of fixing the sites (not the plugin) is as follows, but it does involve a bit of time and effort.

The immediate fix is to use a backup of your database, presuming that you have a recent backup. In PHPMyAdmin (or whatever db tool you use) drop all tables, then import your backup. This will roll your site back to a 100% working state, getting all your Simple Fields data back, and allow you to work on the next step.

Now you need to install the Advanced Custom Fields plugin. I use the Pro version (have an unlimited dev license and it’s worth every penny). I’ve been using ACF Pro ever since Simple Fields was abandoned, and it’s fantastic.

Now you need to recreate each and every Simple Field, in ACF. This needs to be done manually. Of course, I had a headstart as I’ve been using ACF for years now. So apart from being a bit laborious, it was easy enough for me. If you’re good with Simple Fields then you should be able to work out ACF pretty quickly – it’s more intuitive, to me at least.

Once you’ve got all your field groups sorted, you can go into each page and post editor and copy and paste the data from each simple field into it’s ACF counterpart. I dread to think how much work that could be for anyone with a lot of posts, but thankfully for me, the 3 affected sites were quite static, without a great deal of dynamic posts.

Now you’ll need to recode your template files to use the ACF fields instead of the Simple Fields. The PHP is similar and ACF has great documentation and examples on their site.

Once you have that all working, remove all the Simple Fields code from the templates, do a final frontend check to make sure all your pages and posts are working as expected, then delete the Simple Fields plugin completely.

I realise this could take a lot of time for some users, but unless some clever person out there can find an actual fix for the plugin, it’s the best I can offer.

Braintree have assured me that my account is all fine and correctly configured, and that the problem is with the plugin and woocommerce are aware of the issue:

We have been informed by WooCommerce that they are temporarily unable to process transactions with 3DS enabled. WooCommerce has suggested that merchants disable 3DS temporarily until the issue is resolved.

Thanks for your reply @johndcoy,

My 3D Secure settings within my Braintree account are as they should be. Payments have been working for over 2 years. I’ve opened a ticket with Braintree to request they look into any issues with my account, but I suspect they’ll point me back to Woocommerce.

Ah ha! That’s awesome. I was unaware of custom templates for your plugin, but that all makes perfect sense and gives a very simple solution.

I’ll get this in place shortly, when I return to this particular project.

Many thanks for the support!

@biswajitg I manage many WP sites and I’ve had this exact same issue on 2 sites this week.

The main thing that stands these 2 apart from the other sites I manage is that they’re both hosted with 1&1 on VPS Cloud servers.

I found the only solution that worked was to switch the PHP versions from PHP 5.6.31 to PHP 7.

Before you go ahead and do that though, I’d strongly recommend running a PHP compatibility check first, to ensure your plugins are all PHP 7 compatible. https://en-gb.www.ads-software.com/plugins/php-compatibility-checker/

Good luck, hope this helps solve your issue.

Please report back so we can all learn from each other!

thanks for your reply @johngoold-1

I’m using a sub-directory install for the multi-site, as I’ve done many, many times before for other sites.

In the end I gave up on using an .htaccess rewrite approach and used a plugin called
‘Force SSL URL Scheme’ instead.

I’m still at a complete loss as to where or what the issue was, and I’m disappointed that I had to give up on it due to lack of budget, but since using the plugin everything seems to be ok now.

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

Both produce the same result. The rewrite happens but site goes into an infinite redirect loop.

Thanks for replying @jkhongusc

Here’s my .htaccess rules when the site experiences infinite redirect loops:

# BEGIN WordPress
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteBase /
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
# END WordPress

The rewrite from http to https actually happens but site goes into loop.

Yes, that works thanks, but a shame that it doesn’t now save the track position when navigating to another page.

Yes, same with an incognito window and no console errors at all. Same problem across all my browsers: Chrome 57, FF 52, IE11 and Safari Mobile.