foxycart/foxyshop

FoxyShop - WordPress plugin for FoxyCart

foxyshop's Issues

Change links/assets to 'https' throughout FoxyShop

FoxyShop stores are seeing warnings for insecure content in the dashboard and where applicable, assets aren't being displayed, so we should change links to https throughout the code.

To Reproduce:
Go a store dashboard->settings and observe the console warnings.

Feature Request: WP All Import to Work with FoxyShop

More information on the importer at www.wpallimport.com

Add overflow style for .foxyshop_product_list element

The li elements that display products within the ul.foxyshop_product_list is floated, but the ul itself is not. Generally browsers work things out, but some don't, such as Firefox when looking on mobile.

Quick fix here is to simply add overflow:hidden; to the .foxyshop_product_list element.

Update `orders.php` to only include `status_filter` if the store is 2.0

We recently added the status_filter=all filter for the orders.php API requests so that all transactions would be returned. This filter is only supported in 2.0 though, and so it was causing the page to not return any options for Foxy store versions 1.0 and 1.1.

We should update the code to only include that filter if the store version for FoxyShop is set to 2.0.

Form inputs inside sortable elements (like variations) don't work on mobile

For aspects that we support as sortable, such as product variations, when on mobile it's not possible to interact with the form inputs within the sortable element.

If you click the label, it will focus the form element, but you can't directly interact with the input/textarea/select.

This appears to be a bug with the jQuery UI sortable plugin when jQuery Touch Punch is also included on the page, but from a quick search I can't see a clear solution to the direct issue. One approach we could take is to introduce a handle that is used for sorting, rather than just using the whole element as a handle. It means that people need to be more deliberate about where they grab - but would fix this issue.

Add a full-page cart template like for the checkout and receipt

We have templates for the checkout and receipt that can be used - but there isn't one for the full page cart that was introduced with 2.0. We should add support for that.

Clarify API key language to note it needs to be added as the store secret in Foxy

As the Foxy language for the store API key has been updated to the "Store Secret", it's not immediately clear that that's where you need to set the FoxyShop API key when linking the two.

We should make a quick change to our note on the FoxyShop settings page that it's set in the "Store Secret" setting on the advanced settings page in Foxy.

Update to version 4.8.1

Update to version 4.8.1

Broken <textarea> tag attributes in inventory.php

On line 170 of inventory.php there is a tag that has broken attributes:

<textarea id="name="foxyshop_inventory_updates" name="foxyshop_inventory_updates" wrap="auto" style="float: left; width:650px;height: 200px;">

The id attribute and name are munged together: id="name="foxyshop_inventory_updates"

Update Custom File Upload Functionality

See Custom File Upload at https://www.foxy-shop.com/documentation/product-variations/ to see the current workaround and integrate this natively.

Setting the code in a variation breaks inventory checking

It appears there is a small bug in the variations javascript which is causing the inventory checks to fail if there is a variation which sets (rather than adds to) the code along with other variations that add to it.

Specifically it looks to relate to this line in variation.process.jquery.js:

if (new_codeadd) inventory_code = $("#fs_code_" + current_product_id).val() + new_codeadd;

That's getting the default code from the form, but it should instead just use the new_code variable passed to it, which has already been set as inventory_code:

if (new_codeadd) inventory_code += new_codeadd;

Replace jQuery deprecated live() with on()

Live() is deprecated as of jQuery 1.9 and FoxyShop uses 1.11. Error for live() is causing Orders to malfunction.

Example of problematic code in orders.php:
$("#foxyshop_searchform button").live("click", function() {

Change this to:
$("#foxyshop_searchform").on("click", " button", function() {

Look for other instances to replace.

Turning off Enable Subscriptions Removes Settings from Active Subscription Products

If there are existing subscription products and Enable Subscriptions is subsequently turned off in settings, you can disable the setting while the product still remains a subscription product, but the subscription options are removed from the product edit view. Then if the user wants to disable subscriptions for that product, they are unable to do so without knowing they need go into settings and re-enable subscriptions to see the settings and make the changes.

Possible solutions:

• When disabling subscriptions check to see if there are any active subscription products and don't allow disabling unless there are no subscription products.
  —or—
• When displaying products details, check to see if the product is a subscription-type product. If it is, always display the subscription settings, regardless of whether or not subscriptions is enabled.

For the second solution, check the Enable Subscriptions feature and see if there is any reason to not do this. I think I lean toward the first solution.

Add support for JSON webhooks

Currently FoxyShop just supports the legacy XML datafeed, which while that still works, we should add support for the Foxy JSON webhook to get access to the benefits that that provides (like auto-retrying, JSON payload etc)

We will need to maintain the XML datafeed still for backwards compatibility, but we could utilise the same route in FoxyShop, but based on the payload we receive, detect if it's the legacy datafeed, or the new webhook (based on the presence of the headers of the new webhooks). If we detect it's the legacy, then send on to the legacy file, but if it's the new JSON webhook, pass on to the new file.

The JSON webhook endpoint will be largely a duplication of the existing functionality that the datafeed supports, including handling inventory updates, SSO syncing, and supporting events for people to hook into. It should also be a file that people can duplicate into their theme folder to customise further.

The existing endpoint in FoxyShop has some helper logic which pulls in the values from the payload into variables in the scripts, and provides commented places for users to interact with that information. Let's duplicate that same logic for the webhook as well - grabbing the values from the respective elements in the payload.

We should ensure we handle the fact that a single transaction can trigger multiple webhooks as well, if it is an initially pending status transaction, and then becomes approved later, by checking that the status is either blank, approved, or authorized. Anything else we can ignore. (Or alternatively, just skipping if the status is either declined, pending, or rejected).

The legacy datafeed also has a subscription datafeed which sends information about failing or cancelling subscriptions - this isn't a part of the new webhooks, so we can skip most of this functionality with the new endpoint (all the reminder functionality is handled natively now). We do have the subscription/cancelled event though, which sends a payload when the subscription is actually ended - we should pick up that event (if the user subscribes to it for the webhook) and set the subscription as inactive within FoxyShop like we do with the existing datafeed handling.

We don't need to support sending the payload on to external datafeeds like the legacy approach does - as multiple endpoints can be defined in Foxy for the JSON webhooks.

Tasks:

• Detect the new webhooks in the existing datafeed route in FoxyShop
• Add a new optional setting for users to be able to specify the JSON webhook encryption key, below the existing datafeed route in the settings. Add a note for "If using the JSON webhook, optionally set the webhook encryption key here to validate the webhooks being received".
• Create a new webhooks endpoint themefile mirroring the existing functionality
  • Support both encrypted and raw payloads (depending if it's HTTPS or not) as documented on the Foxy wiki
  • Support only the transaction/created and subscription/cancelled events (detected via the Foxy-Webhook-Event header)
  • Validate the payload using the Foxy-Webhook-Signature header, if the webhook encryption key is set.
  • Ensure we only handle completed transactions, not pending or declined
  • Take this ticket into account when duplicating SSO functionality

Look at adding Inventory Levels to quick edit feature

See if we can add inventory level when quick-editing a product.

Here's an article that user shared to do this: https://ducdoan.com/add-custom-field-to-quick-edit-screen-in-wordpress/

Add backward compatibility for recent changes

We can help FoxyShop users who have custom templates by making the previous changes for some IDs to classes backward-compatible. Specifically, this change: https://github.com/FoxyCart/foxyshop/pull/45/files#diff-ddb5a5c7456b15c787c4a0d1a93d384d899fafd5d6d994341b418ec2edfa7f0fL190-R191

Reference the IDs in addition to the classes, for example:
$(parentForm + " .productsubmit").removeAttr("disabled").removeClass("foxyshop_disabled");
to
$(parentForm + " .productsubmit, " + parentForm + " #productsubmit").removeAttr("disabled").removeClass("foxyshop_disabled");

Update Plugin to 4.9.1

Update Plugin to 4.9.1

Update links for buttons at top of settings page

Need to update links for buttons at the top of settings page to the most recent URLs.

Consider showing un-hidden orders in the FoxyShop menu

Think about adding a flag on the Orders menu item that shows un-hidden orders (previously unfilled). Here's an example of what that would look like.

Add support for the pre-payment webhook

Now that Foxy has the pre-payment webhook, support for this should be added to FoxyShop too.

By default, it should support checking inventory levels, and preventing a checkout if a customer is trying to checkout with a larger quantity than currently exists.

Example stand-alone implementation can be seen here: https://pastebin.com/raw/iCAaddg5, although this doesn't differentiate between limited stock and out of stock.

Add minified versions of any javascript and CSS files

To improve performance as much as possible for users of the plugin, we should provide minified versions of our javascript files that get included on the website. Let's maintain un-minified versions for editing and reference, but include the minified versions in the output.

We also have some CSS that we include. Let's switch those to minified versions as well if they are not already minified. Again, maintain raw versions so that they can be used for updating and reference, but don't output them to the page.

Replacing the deprecated get_currentuserinfo()

I have created a PR for this issue here: :)
#37

Consider adding support for changing stock Alert Levels in Inventory settings

Currently, you can update stock levels on the Inventory settings page. User is requesting that we add support for updating stock alert levels as well.

Ensure SSO update runs after the user creation in datafeed endpoint

The datafeed endpoint is currently set to run the SSO update function (which adds any active subscriptions into the user meta data) before the user update function (which actually creates the user).

This results in any purchase of a subscription from a new customer not actually adding the subscription details in the meta. These two functions will need to be switched around to ensure the user exists before trying to add the subscription details.

Replace use of money_format due to deprecation in PHP 7.4

The money_format function is deprecated as of PHP 7.4. It's used within the plugin, so needs to be replaced with the equivalent function NumberFormatter::formatCurrency().

We should probably check if the new function exists, and use that - otherwise fall back to money_format, unless we're ok at this point limiting to a minimum of PHP 5.3 - which considering that hasn't been officially supported in 6 years, we probably should.

[suggestion] foxycart widget visibility behavior

method:
go to wordpress > admin > appearance > widgets
add foxyshop cart widget.
tick checkbox says "show link if cart not empty"
save & visit a page that shows the widget.

witnessed: widget saying only "your shopping cart" and nothing underneath.

expected: entire widget gone if cart empty.

why: looks silly hanging there by itself.

Test with WP 5.6.1 and update readme

Test with WP 5.6.1 and update readme

IE 9, IE 11, Edge issues

Anyway, in IE 9, IE 11 and Edge foxyshop (foxycart) not using foxyshop-checkout-template-2.php for displaying checkout template, but in other browsers it is working fine. I don't know how this happens, if someone have solution to this issue, please let me know.

Remove expiring credit card email functionality from FoxyShop

This is now handled in Foxy natively, along with other dunning functionality. To avoid duplicating functionality, this should be handled in Foxy directly.

Look at improving Add to Cart availability when product is out of stock

Currently, JavaScript is used to make Add to Cart unavailable for items that are set to Out of Stock. Can we make this check server side so that there is no period of time when the button is active while the JavaScript is loading?

Add Variation Type for Entering a Custom Price Amount/Donation

We can create a dkey text field for the customer to enter an amount as a price (such as in a donation), but the current js doesn't update the foxyshop_currentprice on the product page like the modifiers do. It does update in the cart so users can hide this field if they wish. However, we probably should add this as another variation type.

See donation docs here: https://www.foxy-shop.com/donation-gandhi-step-by-step-guide-for-nonprofits/

Move to native Wordpress APIs/functions for improved performance

The Wordpress API has continued to improve and some of the legacy aspects of the code have taken manual approaches to things. Making use of native Wordpress approaches instead gives us the benefit of leaning on the WP codebase for performance and security benefits.

[Request] Orders page ideas

Most of the time I don't need Search Options. That is to say when I do something has gone very wrong. So most of the time it eats page above the fold for nothing, and is probably expensive to transmit and display. It would be great if this could be collapsible so I can see more of my most recent orders. Remembering the collapse state in the cookie and starting collapsed by default would be extra nice.

It would also be very convenient to have a notification count on the "foxyshop" tab and the "orders" tab (on the left in the picture).
I would like it to display the number of orders that are not hidden. I use the hide feature so that I only see outstanding orders.
When I say notification count i mean like the ones on cell phones that show number of unread emails on the mail app icon. usually white number in a red circle in the top right corner.

Thank you, stay awesome!

Test FoxyShop with Latest Version of WordPress

Check FoxyShop to ensure it's compatibility with the latest version of WordPress.

Ensure add to cart signing functionality is up to date with recent additions in FoxyCart

Some additional fields have been added to the native add to cart validation functionality in FoxyCart that should be excluded, we should ensure that the functionality within FoxyShop is up to date with those changes so variations work as expected.

Update Version to 4.7.7

Update Version to 4.7.7

Update any resource links to be https by default

We have some resource links, such as jQuery, which we're outputting on the page in specific situations. While our logic conditionally outputs them as https based on the server port. A user noticed that they were still seeing the file being output insecurely as http.

We should drop the conditional logic and just output the files directly as https by default. For example, from adminfunctions.php:

$jquery_url = "http" . ($_SERVER['SERVER_PORT'] == 443 ? 's' : '') . "://ajax.googleapis.com/ajax/libs/jquery/" . foxyshop_get_jquery_version() . "/jquery.min.js";

Include display ID, filter for "archived" status, and Include Stripe orders

Some quick improvements to the orders.php file to get better consistency with the Foxy admin

• Update the "Transaction Status" filter to "Display Status" and refer to Visible and Hidden rather than Unfilled and Filled
• Add a filter for display_id_filter labelled as Display ID, duplicating the existing Order ID filter.
• Update action and bulk action labels to refer to Hide Transaction rather than Archive

There's also a separate issue where some hosted gateway transactions are not showing (such as Stripe, which is technically a hosted gateway now). This is due to the legacy API filtering to only approved transactions and Stripe getting a transaction status of captured. This can be fixed by adding an additional API filter for "status_filter" => "all" to the two calls for transaction_list on the page.

These changes are in the following file (except for the changes to the archive labelling): https://pastebin.com/raw/rR2Lc0V1

Allow checkbox saved variations to be marked as required

It appears that the required option for "checkbox" saved variations isn't available. As it's possible to make a variation required on the individual products, it should be possible from the saved variations too.

Should just be a small change to the tools-page.php file:

			<!-- Required -->
-			<div class="variation_required_container" rel="<?php echo $i; ?>"<?php echo ($_variation_type == 'dropdown' || $_variation_type == 'text' || $_variation_type == 'textarea' || $_variation_type == 'upload' ? '' : ' style="display: none;"'); ?>>
+			<div class="variation_required_container" rel="<?php echo $i; ?>"<?php echo ($_variation_type == 'dropdown' || $_variation_type == 'text' || $_variation_type == 'textarea' || $_variation_type == 'checkbox' || $_variation_type == 'upload' ? '' : ' style="display: none;"'); ?>>
				<input type="checkbox" name="_variation_required_<?php echo $i; ?>" id="_variation_required_<?php echo $i; ?>"<?php echo checked($_variationRequired,"on"); ?> />
				<label for="_variation_required_<?php echo $i; ?>"><?php _e('Make Field Required', 'foxyshop'); ?></label>
			</div>

Consider consistent labelling for product code

There are a few different variations of labelling for a product's code, including Product Code and Item Code. For consistency, I suggest we move to referring to it as Product Code, and if a shorter form is needed, just Code. While Item and Product are similar enough that it makes sense, it may cause confusion.

There is also a PHP short-tag in use in customposttype.php:618 that causes the Product Code label to not be output on servers with short-tag support disabled.

Add support for PHP 7 by replacing mcrypt with openssl

Deprecated: Function mcrypt_encrypt() is deprecated in [ROOT_DIR]\wp-content\plugins\foxyshop\tools-page.php on line 226

Seeing this error after upgrading to PHP 7. Is there an update coming soon for this? I have a client who insists on using the Foxycart platform and the Foxyshop plugin saved me days worth of development time. I would hate to have to switch at this point in the development process.

Use FoxyCart's native functionality for relative subscription start dates

http://www.foxy-shop.com/documentation/subscriptions-and-single-sign-on/ says:

Note that FoxyShop expands on the FoxyCart functionality by letting you set a strtotime() value in the start or end dates like +3 months.

FoxyCart supports this syntax natively now, so we can ditch this in FoxyShop and rely on native Foxy functionality.

Hide Featured Product Images that Have Been Removed from FS Product

The featured image for a given product appears to be first pulling from the WordPress posts "featured image" option, before falling back to the FoxyShop "Product Images" option. The "featured image" option is hidden by default within the FoxyShop product pages in the admin though, so it can lead to a confusing situation where an image is linked to a product with no clear way to see or remove it.

The plugin hides that featured image section with some custom CSS - but if the checkbox is checked within screen options, it's displayed at that point because of an inline style on the element which overwrites the plugins custom style. After saving or refreshing the page, the featured images section won't be visible (as tested), even though it's still checked in the screen options.

This style in FS just needs to be made !important to fix:

body.post-type-foxyshop_product #postimagediv {
    display: none;
}

We may want to look into if there may be a specific reason why the featured image is still pulled in within the helper function for building out the gallery too.

Steps to reproduce

• Click "screen options" up the top right of the product edit screen and check the box for featured image. It adds an extra panel to the sidebar which is separate to the FS images.
• Add a product image through the featured image section and save. It will now display as the primary image on the product page - but as the "featured image" panel is now hidden in the admin, there isn't any way to remove it.

Update version to 4.8

Update version to 4.8

Minor Update to version 4.9.3

Minor Update to version 4.9.3

Variations with a price modification setting to 0 not correctly updating price display

If you have a variation with a product option modifier like {p:0}, while it will work when added to the cart, the dynamically updated price total on the product page won't adjust to $0.

It appears this relates to the foxyshop_run_variations() function, and the $priceset variable being interpreted as false. Switching to strict comparisons (!== instead of !=) or setting the variable to null by default, and checking for !is_null($priceset) instead of $priceset != "" appeared to work from a quick test.

Trigger a profile update after syncing hashed password from the webhooks

As WordPress doesn't appear to support updating a users password with an already hashed password, it is currently updated by an SQL call when syncing users back to WordPress from FoxyCart. To ensure any functions that are being triggered on customer update are run, we should look at inserting a call like do_action( ‘profile_update’, $user_id ); after the SQL has completed to update the password.

FoxyShop also hooks into the profile_update event to sync back to Foxy, so we'll need to consider if triggering that extra API call is acceptable or not or if we can avoid it by temporarily removing the action.