bsandall

If you just want to be able to edit orders, newer versions of CubeCart allow that. It might be worth considering updating your store.

I'd much prefer using the option_ids and value_ids directly from the database, but what you've proposed is a potentially viable solution... I'm just always hesitant to use strings in that manner, especially ones that are both cached and potentially language-specific. Still, the performance of your proposal is bound to be vastly superior to iterating through all possible option combinations building options_identifiers until a match is found, most notably as the number of options increases. It's certainly worth giving a try!

It's powered by AJAX in the same fashion as (I presume) your dynamic stock indicator (and in fact it also dynamically updates stock levels among other things). The issue I was describing is going backwards from a matrix options_identifier without knowing any of the selected options, and having to figure out what those option selections should be. I'm thinking about this because you would only have the product_id + possible options_identifier available after a search result and would have to then extrapolate which options need to be selected when auto-navigating to that page or otherwise building specific links. In the case of adding all matrix product_codes, UPC, etc. to the HTML, that would indeed be trivial except that it isn't possible to tie them to specific options selections as in the example JackP used. I'm not that well-versed in SEO practices, so I'm not sure if that example is something to aim for or if simply adding them anywhere in the HTML would be sufficient.

In CubeCart v6 (not sure about earlier versions) you can login as the customer via the admin panel; from there, you could certainly add products to the cart for them. Adding products to customer carts without logging in as them could be done, but as far as I'm aware it is not supported out-of-the-box. I'm sure any developer would be able to help you code something like that.

Indeed, and with respect to jumping to a product page and pre-selecting options based on a matched matrix entry, given the matrix options_identifier (easily retrievable from the database during e.g. a search), there is no simple way of determining which options would need to be selected. The only way I can think of is to re-generate all possible product combinations and their resultant matrix options_identifier much like CubeCart does when initially populating the matrix, at least until a match is found. While this would indeed work, it does add overhead to the page load times especially for a product with many matrix options. As for the SEO issue raised by JackP, that would only be possible if each option mapped individually to a product code / SKU / UPC; for the vast majority of products, this is not the case. What if the product code / SKU / UPC was dynamically added to the page once all required options were selected? See for example this page, under the Specifications tab - the product code updates based on the selected options, and there is no reason why the UPC or other fields couldn't behave similarly (in fact, the weight and dimensions on that page also dynamically update, it's just not noticeable because they are all the same for this product).

I completely agree with @havenswift-hosting here - matching against the existing product code columns is exactly what we need. I don't think adding a new column for SKU is that necessary, at least not in the context of improving the search function.

Yes, one can open many tabs, but as soon as you post from one, all the others are invalidated. I would argue that this is not intuitive for the vast majority of users, and even understanding it I still sometimes forget which tab(s) can be submitted; as a result, I try to remember to always refresh the page before I do any editing. I haven't given much thought to how we can improve the admin user experience, but I certainly believe it can be improved.

Al you may also want to mention on that page about having multiple tabs open - this is quite common these days and I doubt most users would intuitively think 'ah I see, the security token is generated when a page loads, so if I load a second page, even if it's in a different tab, then any previously opened pages will have invalid tokens and fail when they submit...' So, perhaps a friendly warning to work in only one tab at a time?

I'd just like to chime in to second that depending on the industry, customers may only search by product code. In my industry, for example, it is more common to search for 'E214B10' than 'class 2 rubber glove.' I have used options extensively on my store - rather than having 100+ product listings for class 2 rubber gloves, there is only one with options. As a result, my store suffers the same search issue. For many products I have simply added a table containing each product code with some data to the HTML description; this has the benefit of allowing customers to easily compare as well as having the product show up in search results, but it is impractical for a case such as the gloves. For those cases, having the search include the options matrix table (specifically the product code field) would be a suitable solution. The only caveat I can think of is that CubeCart does not support displaying a link to a product that includes preselected options, so if you searched 'E214B10' it would only show you the base product, not the exact version of that product you are looking for. Perhaps including the matrix ID in the search results would allow for a more exact link?

'Sort by' wasn't working properly, but that was fixed (see here). Note also that search results are always sorted by relevance on the first page load - the admin product listing order setting is used when browsing the store categories, not for search results. You can change that behavior by removing the following lines from your `searchCatalogue` method: // starting on line 1618 using the most recent CubeCart code from GitHub: } elseif ($search_mode == 'fulltext') { $order['field'] = 'Relevance'; $order['sort'] = 'DESC'; } // leave this closing brace That will then default to the store setting for sorting search results. Of course, if you have a substantially modified version of that file, you will have to wait for bhsmither's assistance.

Are the prices tied to the option (e.g. +$amount1 for option 1, +$amount2 for option 2, etc.), or to the matrix (e.g. FU1-1 = $price1, FU1-2 = $price2, etc.)? If the prices are by matrix entry and you have access to price lists, you can export them to CSV and use this script to update everything at once in less than a minute or two. If the prices are all based on the options, then I'm afraid I don't know of any way to automate that - you'll very likely have to do them all manually.

That's pretty slick! I guess I never looked that closely at it, perhaps because the 'Import Catalogue' page in the admin panel is so sparse its usefulness is not apparent

Honestly, I don't even use the admin panel to manage images - for it to be competitive timewise with other solutions (see below), it would need to be able to upload entire folders of images at a time and then have the ability to auto-assign them to products based on the product code as well as the product code of any matrix entries for that product. Al's suggestion of using a CSV importing tool to import products would help with the products, though I am unaware of any tools that do so in a way that would also handle adding image relationships. For now, I use a custom script I wrote instead, staging my images offline and then running the script to auto-assign each of them to products based on filename:product_code matching. That can easily handle adding and assigning hundreds or even thousands of images in less than a minute. Then I upload the images via FTP (easy to do entire folders) and import the offline product and image table data to my live site. Way faster The script can also be run live, but I like to do all of my changes offline first.

If you hover over the element you want to modify the CSS for and right-click, you should be able to select the 'Inspect Element' option from the menu and your browser will display a small window showing the HTML markup, CSS rules that apply, etc. Doing that on a sub-category on the Foundation skin shows that the rule you wan to to modify is probably related to `.top-bar-section .dropdown`. The nice thing about using the inspector, though, is you can fiddle with the CSS right there in the browser in real time and see which rules do what you want. Messing around with it some it seems that the float:left nature of the categories is at least partly responsible for their width not spanning the page, but it will probably take a fair amount of effort to figure out what exactly to change so that it still looks nice.

For the UPS plugin, the handling charges you set in the plugin settings are added to whatever rate UPS returns via their API and the packaging weight is added to the item weight. Dimensional weight is not supported via the standard plugin which is a real shame because shippers are switching almost exclusively to dimensional weight, but if your store supports product dimensions, you may be able to use the custom UPS plugin I developed for my own use. Since the dimensional weight is greater than the actual weight for most items, not being able to send that information means the rates quoted and charged to your customers will usually be lower than what you actually have to pay - i.e., you either lose money or have to explain to your customer why you are charging them more for shipping, neither of which is fun. The UPS API is smart enough to apply additional charges where applicable so long as it is supplied the information it needs - since CubeCart does not support product dimensions at this time, there is no way for the shipper to determine whether it is a 'large' package or not. I would imagine the USPS plugin operates in a similar fashion, but I have no actual experience with it.

Assuming your custom skin is based on CubeCart's Foundation skin, you can use Git to help you apply all of the changes between when you made the skin and now, even if you've never used Git before. If you've got 15 minutes, you can try it yourself: 1. Install Git for your operating system: https://git-scm.com/downloads When installing it, keep in mind that you'll likely want to be able to open a Git shell from anywhere, so if you see an option like that during installation, make sure it's enabled! 2. Create a folder somewhere that will be convenient to work on your skin, e.g. c:/wamp/www/git/cubecart_skin 3. Open a Git shell ('Git Bash') in the folder you just created - in Windows, you should be able to do so by ctrl-right-clicking in file explorer and selecting it from the menu 4. In the shell that opens up, enter each command below that follows a '>' symbol: Do NOT forget the ending '.' - that tells it to clone in the current directory (assuming you opened the Git Bash from the directory you want, otherwise you should specify the directory e.g. c:/wamp/www/git/cubecart_skin) > git clone https://github.com/cubecart/v6 . Checkout whichever version tag your current skin is based off of, e.g. v6.0.12. Git will warn you that you are in 'detached HEAD' state - don't worry > git checkout v6.0.12 Switch to your new branch! Yay! > git checkout -b custom_skin What that all does is set up a copy of CubeCart's code repository, reverts the code to whatever previous version you based your skin on, and then creates and moves to what is called a 'branch' - so long as you are on this branch, you can play with the code to your heart's content without fear of breaking anything. 5. Copy and paste your current skin into /skins/foundation, overwriting all existing files. Don't worry - you are still on your custom_skin branch so you won't be messing up CubeCart's code, but you can now see exactly what you changed! If you want to see what you changed using the command line: Show all files you modified: > git status Show all changes you made - green for additions, red for deletions: > git diff master Show changes you made to a specific file: > git diff master <filename> e.g. > git diff master skins/foundation/templates/box.basket.php 6. Stage and commit (basically 'save') your custom skin changes so we can get the latest changes more easily: > git add --all > git commit -m "My custom skin based on the Foundation skin by CubeCart" 7. Now you're ready to apply whatever awesome updates have happened and apply them to your skin! The master branch should still have the latest code, so you can choose to merge all of the latest code OR you can choose to merge only up to the latest release: > git merge master OR > git merge v6.1.0 If you only made a few changes (or if you are lucky), everything will go smoothly and your skin will be all up to date! If not, you'll see the following terrifying message: "Automatic merge failed; fix conflicts and then commit the result." This is likely going to take longer than 15 minutes now, but don't give up yet! See below for conflict resolution. 8. Now you just need to upload your newly updated skin to your site! Copy all the files in /skins/foundation to wherever your site is stored and all should be well. KEEPING UP TO DATE Keeping up to date is easy - simply open the Git Bash shell in the directory where you cloned the CubeCart repo and type the following commands: Make sure you are on the master branch > git checkout master Download all of the latest updates > git pull origin master Switch to your custom skin branch > git checkout custom_skin Merge the changes in! > git merge master (or whatever CubeCart version tag you wish) CONFLICT RESOLUTION Conflicts occur when both you and the CubeCart team have modified the same areas of the same files. Often you can resolve it simply by editing the file and removing whichever change you don't want, but sometimes you will need to combine the changes somehow. When you open a conflicted file in your text editor, you will likely see "<<<<<< HEAD", "=========", and ">>>>>>> master" scattered throughout the file; all the code between "<<<<< HEAD" and "=========" is from the current branch, and the code between the "=========" and ">>>>>>> master" is from the branch you are merging changes from ('master', in this case). As mentioned, you usually decide to keep one or the other, but you need to compare carefully as there could be important changes that were made. For a skin, it is often easier to keep the 'master' code and reapply whatever changes you had made manually on top of it. Here is a brief workflow for resolving conflicts: To find which files require conflict resolution: > git status - Open each conflicting file in your favorite text editor and resolve the conflict. > git add --all > git commit - You'll likely see a bunch of colored text at this point - this is the VIM editor. To save and exit, type a colon ':' followed by the letter 'x'. - The merge may now continue, possibly resulting in further merge conflicts; follow the workflow again to resolve them and continue with the merge. Conflict resolution can be scary, but there are lots of online resources discussing merge conflict resolution in Git as well as a fair number of tools - try a few out, take your time. Most importantly, if (haha, when!) you ever completely screw up, DO NOT PANIC! It can be fixed so long as you don't panic and do something irreversible, and even then most things aren't really irreversible in Git especially if you DO NOT PANIC. If you're not confident with Git, then stop what you are doing, keep the bash shell or whatever tool you were using open, and ask for help from a more knowledgeable friend, in an online forum, or on a site like StackOverflow. CLOSING WORDS Please do not let the section on conflict resolution scare you away - Git is an amazing tool. It does take time to learn, many commands are far from intuitive, and there will likely be days when you hate it, especially in the beginning. If you stick with it, however, Git can make your coding life so much easier. There are also some very good graphical programs (such as Atlassian's SourceTree) that make using Git more intuitive for a lot of people - I recommend giving one or more a try. Also, I am not affiliated with Git or any other website or product mentioned in this post, in case that matters to anyone.

Depending on the industry / types of products you are selling, your customers may only know the part number and not actually know what the product is, or there may be a group of products that would share an identical name unless you do something drastic like use the description for the name. The utility industry falls into both categories, for example. In cases such as those, having the product code as part of the name makes it much easier to determine if an item is the one you really want. Using only the product code as the name wouldn't make sense in any situation I can think of.

The reason you should not have both PayPal plugins checked is that Standard is included in Pro. I am not sure if it will cause problems having both, but it is certainly redundant. See the PayPal website for further comparison of features.

This is indeed a complex problem. If money is tight and you are not averse to doing some coding yourself, I have some things (all free) that may assist you: - Adding product dimensions to CubeCart - Shipping library I developed that can pack items according to any algorithm you want with a couple of default algorithms included - Custom UPS shipping module developed for CubeCart using the above library (used the original CubeCart UPS module as a starting point) Using the original USPS module as a starting point and the above UPS module as an example, you could write a USPS module with the above library that would then give you a lot of the flexibility you need. Support for specific box sizes could be handled by clever use of constraints, e.g. FlexibleConstraint containing each of the box sizes as a custom constraint. Minimum box sizes could be enforced by extending one of the current packing algorithms. I hope it's evident that this will require a fair amount of work and knowledge on your part, but if you are willing and able, I believe the library is flexible enough to meet your needs. However, if money is not an issue for you, you can save yourself many hours (potentially entire days or more) of effort by finding an existing module that is close enough (such as the one by Noodleman) and perhaps modifying your shipping procedures slightly to account for that, or by hiring someone to create a module that does exactly what you need. Either way, good luck!

I've made an issue and a pull request for this on GitHub that would allow admins to specify exactly which products show up in the Featured Product box independently from those that show up on the home page. If you are handy with Git, you can pull those changes in to your code base; if not, maybe adding a comment on GitHub in support of merging the Pull Request will help get this feature implemented.

Sounds like you're well on your way to success, then. Luckily for us, CubeCart's development tree is pretty linear, but I have well over 20 branches in my fork of it tackling various issues and new features so yes, it can definitely get messy. You are correct, too, that if the next major version of CC diverges too much from the current codebase, it will be quite a mess to untangle. The best we can hope for in that case is that the changes will be committed incrementally and we can merge them in one or a few at a time. If not, well, at least with Git you can try to reapply your changes onto a fresh copy of the code, and barring that, you have a history of all the changes you made in comparison to the original CC code. While there are certainly dragons, I find they are of a much less fierce variety than those found in the version-control-less lands.

At the risk of sounding like a broken record... if you are making edits to the core code, you really ought to be using some form of version control such as Git. It has a fairly steep learning curve, but once you get the hang of it, maintaining and updating your custom version of CubeCart becomes so much more manageable. If you ever get stuck, you can usually find the answer to your question on StackOverflow (easiest via Google). If you are not comfortable with the command line interface right away, no problem - there are graphical interfaces such as SourceTree, GitHub for Windows, and others. You can even host your Git repository online for free with GitHub or BitBucket, or keep it all local if you don't want your code online. This all goes hand in hand with using a local server (e.g. WAMP/LAMP) during development so that you're not playing with and breaking your live site.

To save your future self a lot of headache, you may want to consider using Git to track all changes you make to your code, and make those changes locally first (so you can test them!) before re-uploading the changed files to your server; editing your live files directly is quite the gamble even if you know what you are doing. Not that the above edit is going to break anything - this is just general advice for if you make more than one or two edits to your code. The more edits you make, the more likely something is to go horribly wrong and leave you with a broken site for however long it takes you to track down what went wrong. Using Git, you can just checkout the last known working version, upload it, and then work locally (or on an alternate staging site) to figure out what broke while your live site continues on its merry way.

See this Pull Request. If you're handy with Git, you can pull it into your own repo and be done; otherwise, click on the 'Files Changed' tab to see which edits you need to make. Note that these edits allow you to have any number of specifically featured products.

@jasehead In that case, you can un-check the 'Status' box for any options no longer available. So in your example, uncheck black and only white will remain, including in the option matrix. If that is the only choice for the option, customers will not need to select it. When black becomes available again, re-check the option Status and the matrix entries will reappear as they were. The only caveat is when you uncheck all options for a specific option group (e.g. both black AND white), that may cause new matrix entries to be created with the remaining options for which you would then have to fill in whatever data you needed such as stock levels. If one or more of the options then became available, the old matrix entries would be used. Since at least one entry for each option should remain, I doubt that will ever be an issue.