bsmither

This is not 'hacking'. (It is an unfortunate choice of word, but) In this context, it is a term to mean "time hack", as when marking the time from a timer or stop watch. The value after the work 'Hack' is the UNIX Time value -- number of seconds since 12:01am, January 1, 1970 (including microseconds after the decimal point). Technicians assigned to troubleshoot slowdowns or bottlenecks will use these values to determine where and what took a long time to get from one database query to the next.

A very brief run of the storefront and admin dashboard shows that CC6114 has preg_replace() issue. See the Github issue #2220. But, since you are running this under PHP 7.0, you should have already made that fix.

I will install a stock CC6114 and run it under PHP 7.4. I'll report back if there are any issues. Also, be advised that any ionCube encoded third-party modules built for PHP 7.0, will need to be given some consideration when creating an environment with PHP 7.4. The ionCube decoder may need to be upgraded to run under PHP 7.4, and that means the encoded modules will have to have specific versions available for that environment.

CC646 says PHP 5.5 is the minimum, but that was not correct. CC647 incorporated a correction to state that PHP 7.1 is the minimum. CC645 says PHP 5.5 is the minimum, and also says it will not run under PHP 8. I have CC6012 through CC645 running under PHP 7.4. So, maybe I misunderstood your initial question? Are you saying you have issues running CC6114 under PHP 7.4?

Short answer -- no.

Not familiar? It is admin, Orders with: no items per page selector, no javascript, no images, no CSS, and added table column showing data from CubeCart_order_summary.gateway field. (Not familiar with the red-colored order number, unless color applied in this post to draw your attention to it.)

Should there be a project to add the means to instantly create a related customer record while creating a new order, the result would be a narrow implementation. That is because a customer record will have a name, where that customer's related various addressbook records can have different names. So, maybe building a code snippet to be used by those that can use this specific implementation.

Please know that when an admin creates an order, providing delivery and billing details (which includes customer names and addresses), saving such an order, currently, does not automatically also use the customer details to create a new customer record in the database. (But it should be possible to add the necessary code to do that.) When listing orders, if there is a customer_id accompanying that order, then yes, there will be a link to bring up the editing page to show that customer's details.

So your question at first was not "Is this how it happens?", but rather "Can I make it do this?" And by "this", perhaps you meant that the module should tell CubeCart to set the order's status to "Declined" when Authorize.net sends back a response code of 'Declined' (case 2). The gateway.class.php file will need to be customized so that it will tell CubeCart to set the order's status to match that that of Authorize.net's response.

Yes. The Authorize.net gateway code (version 1.1.1 is what I am looking at) will tell CubeCart to set the order to Pending if the response code is anything other than Approved. That is: Declined, Error, and Held for Review. It will do this regardless whatever status the order had previously. This module (which might not be the same as the latest Authorize module from the MarketPlace) has two modes: SIM and AIM. The SIM mode does not record the order status in the respective order's Transaction Logs tab. The AIM mode does.

"Removing the parentheses still results in the same behaviour." To be clear, when using the flyout to enter a customer's name (a job number), you were able to enter a left parenthesis? I changed the Last Name of a customer to be (3456789), of which entering 345 brought up that customer for selecting. (The 'autocomplete' script requires three characters before an ajax request for search results is fired.) Note: I also found out why my browser (Firefox 115) will not accept a left parenthesis in the search string. So, on Orders, Search Orders tab, entering Mar in Customer Name, but not also clicking on one of the suggested results, then clicking the Search button, this has failed to assign to the Customer Name text entry field the customer_id value of the selected choice from the list of suggestions. Thus, in this scenario, having clicked the Search button will submit the form but with nothing to search against. You mention administratively creating orders with no customer info? That does seem to be possible, and is there a workflow reason to not include a job number (Last Name)?

Where are you searching? If using the flyout that appears at the upper-left corner, the text entry field for searching on customers does not accept parentheses.

In admin, Store Settings, Layout tab, there is "Product List Sorting" that will set the default sort for simple search results, and a category's list of products. Sale Items have a default sort of sale price, and Latest Products have a default sort of last modified time.

On the Overview tab, at the bottom, there is a Shipping Information -- which also includes the payment gateway. (At least CC652 does - I haven't checked what CC6114 shows.) Shows in the Transaction Logs tab. That points to a problem (yet to see if it has been fixed) in the Order class, as opposed to a problem in the PayPal module - whether it be PayPal Standard or PayPal Commerce. How long ago did this particular order happen? Today? Last month? Last year?

I do not know why the PayPal Commerce module accepts the customer's PayPal data and overwrites existing CubeCart's customer data. It's not a bug. As for the missing gateway data item in the Orders list, having brought that order up for editing, is it also missing on that order's Overview tab? Is it also missing on that order's Transaction Logs tab?

I am not sure if this is related, but see (I hope these web addresses show -- replace the h??ps with https): h??ps://forums.cubecart.com/topic/58031-paypal-phone/ h??ps://forums.cubecart.com/topic/58078-customers-phone-numbers-are-corrupting-since-new-update/

Please see Github issue #3375. I would tell you how to fix it, but new security measures implemented on these forums prevent me from posting lines of code. So, in the file mentioned in the Github issue, find lines 17 and 18. Remove the leading spaces in front of the script tag and the EOT; statements.

As best I can determine, there are about three areas in the code that affect the page=all situation on the storefront. None actually stop CubeCart from delivering all pertinent records. But these changes do implement a new pagination sequence on the storefront and a per page selector - the selections of which can be customized. Let's look at the skin's config.xml file: <products>, <perpage> array. Note that the last array element is (probably) set to an amount equal to 96. More <perpage> elements can be added - an amount equal to 192, for example. (Have CubeCart clear its internal cache if this file gets changed.) The first area in the code is the element.paginate.php skin template. In the various skin's that were published with and for CC5, there is code to show a 'All' link when the Smarty variable {$view_all} is true. For Foundation (the only skin published with CC6), that 'All' code was commented out, showing instead a drop-down selector listing the various <perpage> amounts. In CC652, that commented out 'All' code was removed. Should the visitor want to see more products per page, using the drop-down selector is how it is done. Should the store owner want to have a 'All' pseudo-capability, add a <perpage> element with an amount equal to some large number - 192, for example. As was mentioned, be sure the environment that hosts your site is capable. (And, if the page is to show a couple dozen rows of product panels, look into implementing a "lazy-load" of product images.) The second area is in the database class, pagination function. In CC6410 and CC652, when calculating the pagination data for the skin's element.paginate.php template, if there should be page=all in the link, then the data given to the template will be changed to page=1 and per_page=X where X is the last <perpage> amount - 192, for example. So, if there are less than this amount to show, there will be no pagination, thus, a 'All' pseudo-capability. Note that this pagination function still provides a true (default) or false value to the Smarty variable {$view_all}, for CC5 skins, or any skin that really wants to have this in the pagination string. The third area is in the catalogue class, searchCatalogue function. This function returns search hits, products on sale, and products belonging to a given category. If page=all is found here, CubeCart sets a hard limit of 100 records to be returned from the database for sale items and search hits. For products belonging to a given category, the getCategoryProducts function will not use page and per_page when page=all, thus all pertinent records are returned. Lists in admin have also, recently, adopted this paradigm.

Have CubeCart clear its internal cache.

Go here and download the jquery.validator.additional-methods.js file: https://github.com/jquery-validation/jquery-validation/tree/1.19.5/dist Place the file in the skin's /js/vendor/ folder. Edit the skin template element.js_foot.php file: Find: {assign var=js_foot value=[ 'skins/{$SKIN_FOLDER}/js/vendor/jquery.rating.min.js', 'skins/{$SKIN_FOLDER}/js/vendor/jquery.validate.js', Add after: 'skins/{$SKIN_FOLDER}/js/vendor/jquery.validator.additional-methods.js', Edit the skin's javascript 3.cubecart.validate.js file: Near line 355, find: $("#addressbook_form").validate({ rules: { Then find: postcode: { required: true } Change to: postcode: { alphanumeric: true, required: true } Near line 214, find: $("#checkout_form").validate({ rules: { Then find: 'billing[postcode]': { required: true }, Change to: 'billing[postcode]': { alphanumeric: true, required: true }, Then find: 'delivery[postcode]': { required: true }, Change to: 'delivery[postcode]': { alphanumeric: true, required: true }, Log in to the storefront and view your addressbook. Edit an existing address. Change the postcode to have a character other than a letter, number, or underscore (not dashes or spaces). When the Save button is clicked, there should appear a red banner saying to use only certain characters. The additional methods file include rules for various postal code formats: CA, NL, IT, UK, US. But I have yet to learn how to get the validator to cycle through them until one returns true, or to positively choose which one to use.

https://github.com/FortAwesome/Font-Awesome/tree/master/svgs/solid

Using a programmer's text editor, open the file icon-sprites.svg. Find: <svg display="none" version="1.1" xmlns="http://www.w3.org/2000/svg"> <defs> Add after: <symbol id="icon-play" viewBox="0 0 384 512"> <path d="M73 39c-14.8-9.1-33.4-9.4-48.5-.9S0 62.6 0 80V432c0 17.4 9.4 33.4 24.5 41.9s33.7 8.1 48.5-.9L361 297c14.3-8.7 23-24.2 23-41s-8.7-32.2-23-41L73 39z"/> </symbol> Save. In the template BRANCH code: Find: <use xlink:href="#icon-angle-right"></use> Replace with: <use xlink:href="#icon-play"></use>

The (jQuery-based) Validator code that the Foundation skin uses has an 'additional package' that can be incorporated. This package has several postcode tests, as well as a 'numbers, letters, and underscore only' test. I will be experimenting with that soon.

The greater-than symbol is the closing angle of the first part of the <a> tag. Everything after that, up to the second half of the <a> tag, </a>, is the "friendly-text" seen as the link. It will become apparent when you collapse the multiple lines into one line, if you so choose.

Since you are calling this a "ZIP Code", may we assume your only country of delivery is the USA? If not, a different test must be developed.