bsandall

Generally speaking, data should always be stored exactly as it was entered. Otherwise, you end up making a lot of assumptions while 'cleaning' that could destroy the data integrity. For example, say you are cleaning phone numbers to match 123-4567-8901 format; well what if I have an extension? What if I live in a different country? Etc. etc. It forces you to think of a lot of 'possible' cases that you can't hope to ever fully encompass, so storing the data as it was entered is the only way to maintain its integrity. Then, when you actually want to DO something that said data, that's when you clean it up to your expected format. If there are any problems, e.g. an entry doesn't fit the formatting, you can inspect what was input and adjust your formatting code accordingly, whereas if you had forced it into that format from the beginning, you wouldn't be able to do that. With the HTML example, if you stripped all the HTML code, how would you go about displaying that data back as HTML? All of the formatting data the user had entered would be lost. Anyway, hope that gives some insight into why a programmer might go the route chosen by CubeCart. In my opinion, it is the only choice.

The Pro-Git book / PDF is freely available. That's how I learned to use git (that and LOTS of practice and Googling). To set up a basic repo is simple if you know how to open a command window or install SourceTree, but it can be a lot to process at first because of the multiple tools involved: Download the git utility / install a program like SourceTree that comes with itRun 'git init' in an empty directory to create the repository (or create a new repo using SourceTree's interface)Copy all your files into that directory - I recommend adding the images and cache directories to the .gitignore file (or, again, ignore them from the interface)'git add --all' or add all files from within SourceTree'git commit' then type a message like 'initial commit' - you might be in Vim editor, so you'll want to become familiar with the basic commandsNow you're basically doneOnce you have the first commit to your repository, you can set up a Github (only recommended if you want your source to be public or you are willing to pay for private repositories) or Bitbucket (allows up to 5 free private repositories) account and push your code there so you have an online 'backup'. It also allows you to collaborate, e.g. if you have a team of coders / designers. From this point forward, any changes you make will be immediately apparent from within SourceTree or by running 'git diff' against any commit or branch. Make small commits containing a single feature / changeset at a time, get familiar with branching and the Git Workflow, and your life will be good. Now you have two options to update your code: NOT RECOMMENDED WAY: Simply copy the latest CubeCart version files into your directory (make sure any uncommitted changes are stashed or committed first!) and you will see what has changed. You'll want to check every single file and every single line for conflicts and manually resolve them.RECOMMENDED WAY: This way is a little more to chew, but it is far superior. Instead of creating a completely new project like in step #2 above, fork the actual CubeCart repository on Github, then paste YOUR changes on top of it. Add the original repo as an upstream remote, and you can pull the latest changes into your branch at any time and Git will inform you of any conflicts automatically.I know it can be pretty daunting, but the results are awesome. You can make experimental changes on a new branch - if it doesn't work out, just throw it away and you've still got your original code in working order. If it does work out, just merge it in. Did it introduce a serious bug? Checkout the last known bug-free version and put that on your live site, then checkout the buggy one locally while you sort out what happened. If you're doing any amount of modifications to the core files, this is, in my opinion, the only way to do it while keeping your sanity. Good luck.

What Ian says is true, but a much better solution than making copies is to use a version control system such as Git - then whenever you upgrade, it is a simple process to re-apply all of your personal changes on top of the latest CC version. This becomes more and more useful the more changes you make.

Yikes, that sounds like a nightmare depending on how complex your descriptions are. For my particular scenario, I was able to resolve it simply by replacing the hexadecimal version of the character with the one I want: UPDATE `cubecart_option_matrix` SET product_code=REPLACE(product_code, CHAR(0xe28090), '-') WHERE product_code LIKE CONCAT('%',CHAR(0xe28090),'%');Thanks @bhsmither for pointing me in the right direction - I wouldn't have thought to check the hex value of the strings otherwise.

I'm not sure if this is what you meant, but I cast the product codes to binary in my SQL query and some of them are correctly encoded as '2d' for the hyphen - these display correctly in all cases - and some do not appear to be encoded the same - instead they have 'e28090' for the code, which is the UTF-8 encoded UNICODE hyphen... So, I think what happened is I copied and pasted some of these codes in from online and/or a spreadsheet file, and the source must have encoded the hyphen in the above manner. Oh, the joy of working with character sets with invisible differences.

Guess my edit didn't make it in time - you're too fast

Nevermind, I was working with a modified copy that I'd mangled... derp.

That was using MySQL console to query the database (it's a local copy) - using the local PHPMyAdmin, however, does correctly show hyphens. CubeCart tables are all encoded using UTF-8, though, and I've never seen hyphens fail to be encoded properly like this before using UTF-8 encoding. Is it possible that the CC admin pages are using a different encoding?

I've noticed that any of my product codes that contain hyphens, e.g. 'ABC-1', are stored in the database instead as 'ABC?1'. They do display correctly in the store, so somewhere in CubeCart they are converted back and forth, but I haven't been able to find out where yet. This becomes an issue (albeit one that can easily be worked around) when trying to match product codes using direct SQL queries or, for example, reading in a CSV file to automatically update prices. Anyway, since hyphens don't have any particular special meaning in SQL when included in a string, what is the reason for the conversion?

Alternatively, you could add the `required="required"` attribute to the parent select element on the previous line: <select name="tax_type" id="tax_type" class="textbox" required="required">That should cause the form to highlight that input element upon submitting without selecting an option.

I ran into this same issue so I wrote a script to import already uploaded files (i.e. FTPed to your site) into the CubeCart database. It's smart enough not to generate new file_ids for already existing files, and can even auto-associate files with products if the filenames match a product code. It has a Dry Run mode that I suggest you run first to see what will change; only hit Submit after reviewing the results and making sure they are what you expect. Hope you find it useful EDIT: I should mention that I have only been using the script locally so far, so let me know how it works on a live site if you give it a go. Cheers.