Dirty Butter

It's SemperFi's AskAbout a Product plugin that makes it possible to let people Make an Offer if you choose that to be available. BUT that's all it does. It just provides a good way to identify exactly what they are asking about. Nothing automatic about the offer acceptance, counter offer, or rejection at all. And there seems to be a support issue on SemperFi's plugins which may not have been resolved - hope I'm wrong about that.

Since I may be the only one using the keywords this way, I will make an effort to follow your directions: "It isn't a big job to create a new database column equivalent to the keywords field, add that to the admin product source and change the custom search code to use the new field instead of the meta keywords. " We'll see how it works out.

I use the keywords for custom search terms. It might be easy for Havenswift to "easily reworked", but certainly not for me. If this is done, I would have to pay @havenswift-hosting to copy my meta data to a new database record and create the CC code to utilize it. Surely I'm not the only one who uses the keywords as a place to store alternative search terms. Will the customer search for bunny or rabbit? Will they type DanDee or Dan Dee? What if they use Carter's or Carter or Carters. All brand name variations and typical misspellings should lead to the correct search results. I never used the merged global SEO choice, but I really depend on the keywords for search.

I would agree with that completely, Ian. But our plushmemories "blog" became SO successful that I could no longer manage it by myself. I moved it to Facebook, where I currently have 5 Admins and 6,100 members - growing every day. Even though the plushmemories website has had NO changes at all for almost 3 years now, it still gets a large number of visits a month. The archive of information it contains about vintage toys is invaluable. I'm just trying to figure out a way to leverage that plushmemories traffic to help with our store. :) I do appreciate your advice :)

Thanks for the reassurance. At this point what I really need is a crystal ball to see if the move would improve our store traffic any or not. Store name would change as well, although that is no biggie with CC - hard to say if that's a biggie with sales or not. Still weighing it as a business decision, but at least the move itself is not on the Con side now. The biggest Plus, in my mind, is that the plushmemories domain receives way more hits than the dirtybutter domain does, even though it is an archive available to the public of plush information.

My toy store is currently at dirtybutter.com/plushcatalog. I'm considering moving the store to plushmemories.com/plushcatalog. Https://plushmemories.com is a WP site. I assume I would need to use a 301 to redirect traffic to the new site. The store has been open a long time, so there are probably lots of links to the current url. How much trouble with the Wordpress situation will it be to move the store? @havenswift-hosting your input here would be appreciated when you have time - NO hurry - 12AM where you are

I understood that these extras were not harming the CC function. But I would like to understand why these are created? I play around with test sites and sometimes can't remember if I have already run the Setup queries for a certain version yet or not - particularly when I am playing with commits within one version. Is THAT what may be causing duplicate keys?

What action on my part or CC's part causes all these duplicate KEY Indexes?

I'm pleased with the way I changed the skin and language wording for the Cart. Maybe it will be of use to you. Take a look at the purchase flow on https://dirtybutter.com/plushcatalog.

I can always create a custom language entry if it ever does get used in some other place. Since this is an important part of the Checkout Process screen as I have modified it - I will have to translate that phrase into every language I allow on the live store. I have a bad habit of forgetting to do that with most of the language edits I've made over the years.

Changing Refine Estimate is a little odd - It's in Common Language section - not Basket or Checkout. Is there any other place where that phrase is used? Doesn't seem like there should be.

I make no claim of knowing what I'm doing - in fact I made a mistake when I upgraded that just maybe is what you did. Be sure you have the new PHPmailer folder, not still using the old phpmailer folder.

I think I fixed it - getting everthing lined up was a little more challenging. There's probably a more elegant way to do it, but see what you think: {if isset($SHIPPING)} <tr> <td width="10%" nowrap="nowrap"><span class="redbold">{$LANG.basket.shipping} </span> <br> {if $ESTIMATE_SHIPPING} (<a href="#" onclick="$('#getEstimateSmall').slideToggle();"><strong>{$LANG.common.refine_estimate}</strong></a>) <div id="getEstimateSmall" class="hide panel callout"> <h4> <svg class="icon right" id="getEstimateClose" onclick="$('#getEstimateSmall').slideUp();"><use xlink:href="#icon-times"></use></svg>{$LANG.basket.specify_shipping}</h4> <div> <label for="estimate_country_small" class="hide-for-small-only">{$LANG.address.country}</label> <select name="estimate[country]" id="estimate_country_small" class="nosubmit country-list" rel="estimate_state_small"> {foreach from=$COUNTRIES item=country}<option value="{$country.numcode}" {$country.selected}>{$country.name}</option>{/foreach} </select> </div> <div> <label for="estimate_state_small" class="hide-for-small-only">{$LANG.address.state}</label> <input type="text" name="estimate[state]" id="estimate_state_small" value="{$ESTIMATES.state}" placeholder="{$LANG.address.state}"> </div> <div> <label for="estimate_postcode_small" class="hide-for-small-only">{$LANG.address.postcode}</label> <input type="text" value="{$ESTIMATES.postcode}" placeholder="{$LANG.address.postcode}" id="estimate_postcode_small" name="estimate[postcode]"> </div> <div> <input type="submit" name="get-estimate" class="button expand" value="{$LANG.basket.fetch_shipping_rates}"> </div> <script type="text/javascript"> var county_list = {$STATE_JSON}; </script> </div> {/if} </td> </tr> <tr> <td colspan="6"> {if !isset($free_coupon_shipping)} <select name="shipping" class="nomarg"> <option value="">{$LANG.form.please_select}</option> {foreach from=$SHIPPING key=group item=methods} {if $HIDE_OPTION_GROUPS ne '1'} <optgroup label="{$group}">{/if} {foreach from=$methods item=method} <option value="{$method.value}" {$method.selected}>{$method.display}</option> {/foreach} {if $HIDE_OPTION_GROUPS ne '1'} </optgroup> {/if} {/foreach} </select> {/if} </td> </tr> <tr> <td colspan="6" class="text-right"> {$SHIPPING_VALUE} </td> </tr> {/if} I added one little tweak to keep the shading behind Shipping consistent with the rest of the shading: <td colspan="6"><span class="redbold">{$LANG.basket.shipping} </span> instead of <td width="10%" nowrap="nowrap"> One thing I did notice is that the drop down for Estimate provides space for State even when I have that choice Disabled in Zones. No harm - the drop down works correctly with it left blank. Should work just like the Checkout choice - see the blank there only if Zones settings offer the option. Bug?

I can re-word to "Add Delivery Info for Accurate S/H" - but does not help enough to matter.

I played with the test site and am very pleased with the medium to large screen, Moving the Estimate link to the left makes it more intuitive, plus changing the Language wording helps. BU I need spacing help with the Small screen - I can't get the shipping options and final s/h price to properly move to a new line to keep from being squeezed.