garrettlynch

Put this in the css file for wordpress and it should override the width setting for inputs that’s set in the plugin:

.shopping_cart form input[name='quantity']
{
width: 80px !important;
}

For the plugin developers: it would be very useful to have ids on all tags in the shopping carts and purchase buttons so that users can style them relatively easily.

Is there a way to dynamically update the shipping cost from something like jquery without getting “Error! The shipping price validation failed.”?

I’m trying to have two shipping costs depending on where an item is sent to e.g. local or international. I could have two buttons and alternatively make them display: inline;/display: hidden; but it would be easier with one button where the shipping attribute is changed directly.

This worked:

add_filter( 'post_link', 'custom_permalink', 10, 3 ); 
add_filter('rewrite_rules_array','wp_insertMyRewriteRules');
add_filter('init','flushRules'); 

function custom_permalink( $permalink, $post, $leavename ) {
  $category = get_the_category($post->ID); 
  if (  !empty($category) && $category[0]->cat_name == "Test" )
  {
      $permalink = trailingslashit( home_url('test/' . $post->post_name ) );
  }
  return $permalink;
}

function flushRules(){
  global $wp_rewrite;
  $wp_rewrite->flush_rules();
}

function wp_insertMyRewriteRules($rules)
{
  $newrules = array();
  $newrules['^test/(.*)$'] = 'index.php?name=$matches[1]';
  return $newrules + $rules;
}

That doesn’t work as I asked.

“Default selection of auto publish while editing posts/pages” – No

Only works when you edit a post. It is not set to No when you first create the post.

If you don’t want to publish posts then set “Publish wordpress posts to social media” as No , then it won’t appear.

I want the plugin panel to be visible on every post – However, I want it to be set to No by default regardless of whether I’m creating a post or editing a post. I do not want all posts to be pushed through social media, only some, because they are posts of different categories. For example ‘announcements’ or ‘news’ but not other categories. The plugin needs this third option that forces users to activate on a per post basis.

I was wondering if the rewrite to index.php was causing a particular issue. So I made a dummy test.php page and tried this:

RewriteCond %{REQUEST_URI} ^/(test|test/.*)$
RewriteRule . /test.php?pagename=$1 [L]

That works but I couldn’t get this to work:

RewriteRule ^/(test|test/.*)$ /test.php?pagename=$1 [L]

Anyway I could duplicate the index.php page in test.php as a work around – I’d rather not, if anyone knows how to get it to work that would be greatly appreciated.

Thanks but nope neither works. I had already tested with something similar:

RewriteRule ^/test/([^/]*)-([0-9]+)/$ index.php?pagename=$1 [L]

which doesn’t work either. Everything I’ve tried just does a redirect instead of a rewrite so for example /test/post1/ just changes in the browser address bar to /post1/.

No problem, many thanks for your help and continued success with the plugin – its very useful!

The json looks clean.

>we could consider that the problem is actually with the
>cache of the plugin, it caches the results from the API for 20 minutes

This makes sense and I did see a mention of caching of the plugin on a forum but couldn’t figure out where the clear cache they referred to is – which of the files under datastorage is the cache that should be deleted? Did a scan with 1.8.6 – still no errors. Swapped out for 1.8.8 again and did a scan (well after 20 minutes had elapsed) – now no errors. A bit mystified but seems to work now ??

Thank’s for your help on this. There’s no firewall. I deactivated all wp plugins and security modules in cpanel, contacted my host and they flushed any potential blocks – no change. Sitecheck works just fine.

Out of curiosity I just swapped back to Securi wp plugin 1.8.6 and the 403 error disappeared. I do believe you that this is an error caused Securi’s server side but what if the error isn’t actually occurring and that displayed alert is being triggered as a result of a malformed clause in some new code in the plugin? – it’s a possibility.

I saw on a forum post somewhere that whitelisting sucuri’s ip should resolve this, unfortunately the ip mentioned was an old one (192.155.94.43). I’ve now added:

allow from 192.124.249.7
allow from 173.255.233.124
allow from 162.216.19.183

to my .htaccess but no change – or perhaps I’m misunderstanding where you mean to whitelisting these. Can you give more detail please. Thanks.