bsmither

When you created the sitemap, did you log in to admin under SSL? (Even if the store is set to use SSL, one can still log in to admin not using SSL.) If you did not log in under SSL, then that may be the reason why the sitemap was created using non-SSL links.

In an earlier post, you gave a sequence of links. From the first to the second, the URL is getting switched to https while retaining the rewritten URL. This issue in the Github mentions it, but was dropped. This fix answers why a SSL-enabled store still has non-ssl links in the sitemap.

"Is there a way to make Mican work with the SOCIAL_LINKS?" Working with Mican, make these edits: In common.css, find near line 90: #header #boxes, #main_body, #header #cart_box, #documents { -moz-border-radius: 10px; border-radius: 10px; -webkit-border-radius: 10px; } Change to: #header #boxes, #main_body, #header #cart_box, #documents, #social_list { -moz-border-radius: 10px; border-radius: 10px; -webkit-border-radius: 10px; } Find near line 225 a series of six rules for #documents. COPY these rules to a new blank line after them. Change the copied rules from #document to #social_list In layout.css, find near line 5: #header #boxes, #header #cart_box, #main_body, #documents { border: 6px solid #989898; background-color: #FFF; } Change to: #header #boxes, #header #cart_box, #main_body, #documents, #social_list { border: 6px solid #989898; background-color: #FFF; } There are three rules for #documents near lines 30, 33, and 46. COPY these three rules to a new blank line after the third rule. Change the copied rules from #documents to #social_links Create a new template named element.social.php and for its contents: <ul class="documents"> <strong>{$LANG.common.follow_us}:</strong> {foreach from=$SOCIAL_LINKS item=link} <li><a href="{$link.url}" title="{$link.name}" target="_blank">{$link.name}</a></li> {/foreach} </ul> In the template main.php, find near line 83: <div id="documents">{if isset($SKIN_SELECT)}{$SKIN_SELECT}{/if} {$SITE_DOCS}</div> Change to: <div id="documents">{if isset($SKIN_SELECT)}{$SKIN_SELECT}{/if} {$SITE_DOCS}</div> <div id="social_list">{$SOCIAL_LIST}</div>

We can add to core code the additional options to send the admin an email when an order moves to that status.

" It still leaves the /index.php?seo_path= part in the link. Should it remove that? " CubeCart should be removing that. We will have to find out where it doesn't when it is supposed to.

" I think once the seo link has been deleted, it takes the page being clicked on to refresh it. " There is an issue with having the Maintenance kill SEO links. See: https://github.com/cubecart/v6/issues/1490

" but after 5 or so refreshes, the page pulls up " I was going to say this sounds like an external caching issue (not your browser and not CubeCart, but something your hosting provider is running your site through). But that doesn't make sense. A new seo path wouldn't be in the external cache.and no external cache would block a request for a page it doesn't have. If it is CubeCart that is returning a 404 (a "404 message" within a regular Cubecart page), then either: The URL is not getting rewritten in the .htaccess file, or The seo path cannot be found in the CubeCart_seo_urls database table. Check the table for the exact, correct spelling of the seo path being used.

There is a disconnect between CC61X and the Mican skin. In CC61X, the admin Store Settings, General tab, has a list of Social Accounts, in which for each entry, you enter the social account's URL or user name. These entries pass through some validation checks at GUI->_displaySocial(). Finally, the URLs are given to the template variable SOCIAL_LINKS and the template file element.social.php is rendered. This does not work with Mican (unless the template is made to work with CC6 in this way). CC61X also collects up the social plugins found in /modules/social/. Each plugin should have a function called getButtonHTML(). The HTML that this function creates is given to the template variable SHARE in Cubecart->_product() and ->_document(). The list of URLs you can add in Store Settings (for Foundation and compatible skins) is not the same as the collection of social plugins you install (originally for CC5 compatible skins, as well as Foundation and compatible skins). So, see if there is a Facebook Social Plugin at the MarketPlace.

The following is a plan to create two Code Snippets for CC615: one to "globalize" the Mailer class instance instantiated by Order->orderStatus(), and the other to toss in all admin emails that have been set to receive such notifications to a BCC array. In admin, Manage Hooks, Code Snippets tab, click Add Snippet. Enabled: Checked Unique ID: classize_mailer@cubecart Execution Order: 99 Description: Class-izes the Mailer instantiation so that it can be seen outside the orderStatus() method. Trigger: class.order.order_status Version: 1.0 Author: https://forums.cubecart.com/topic/52330-how-to-add-admin-as-bcc-of-all-customers-order-status-emails/ PHP Code: <?php $this->_mailer =& $mailer; Save. Start another Code Snippet. Enabled: Checked Unique ID: bcc_admin@cubecart Execution Order: 99 Description: BCC's the admins on all customer emails. Trigger: class.order.assign_order_details Version: 1.0 Author: https://forums.cubecart.com/topic/52330-how-to-add-admin-as-bcc-of-all-customers-order-status-emails/ PHP Code: <?php //$this->_mailer->SMTPDebug = 2; //$this->_mailer->Debugoutput = 'error_log'; $addBCC_notify_admins = explode(',', $this->_notifyAdmins()); foreach ($addBCC_notify_admins as $admin) { $this->_mailer->addBCC($admin); } Save. As I have been testing this, a couple of things are preventing me from discovering if this really works. I see the names getting added to the BCC array, and I see the names being mentioned in RCPT TO commands to the SMTP Server. But (due to a funny thing about my web server), the Test Gateway does not complete, so I do not get all the diagnostics I want, and maybe the SMTP server I am sending this out to is grouping all the email addresses (as the customer and all admins have the same domain of an email address). I do not see any BCC TO command. So, more experimenting. But I wanted to get this posted.

Where is the message in the page, and what else is on the page? If the message is in a weird place on a standard CubeCart page, then the message may be coming from the social site. There is no such phrase in CubeCart's lexicon.

I am not seeing any difficulty.

Please keep in mind that the browser that receives the order.print.php rendered file will likely have cached the print.css file. So, no matter if edited, unless the browser is 'tricked' into loading this file all the time (as opposed to using the copy in its cache), nothing changes. Feel free to post copies of those files here, or ZIP them up and make them available for download from some site. We can take a look. If the browser using the copy in its cache is the problem, try: In orders.print.php, find: <link rel="stylesheet" href="../{$SKIN_VARS.admin_folder}/skins/{$SKIN_VARS.skin_folder}/styles/print.css" media="screen,print"> Change to: <link rel="stylesheet" href="../{$SKIN_VARS.admin_folder}/skins/{$SKIN_VARS.skin_folder}/styles/print.css?v={$smarty.now}" media="screen,print"> This adds the current epoch timestamp to a querystring. It's guaranteed to be unique, (supposedly causes all caching mechanisms from your browser to CubeCart inclusive to to be bypassed, and is completely ignored. That is, will not affect what the web server sends back.

I will have to study your 'trailing space' issue separately. I have not tried the following, but these two lines will remove characters that would interfere with the RLIKE word boundary syntax. But that opens other considerations. In catalogue.class.php, searchCatalogue() function, find: if(strtolower($search_mode) == 'rlike') { $like_keyword = "RLIKE"; $like_prefix = '[[:<:]]'; $like_postfix = '[[:>:]].*'; } else { $like_keyword = "LIKE"; $like_prefix = '%'; $like_postfix = '%'; } for ($i=0; $i<$noKeys; ++$i) { dbgClue('Working with this term from $searchArray: '.$searchArray[$i],array(),false); $ucSearchTerm = strtoupper($searchArray[$i]); if (($ucSearchTerm != 'AND') && ($ucSearchTerm != 'OR')) { On a new blankline AFTER that, add: if(strtolower($search_mode) == 'rlike'){$searchArray[$i] = str_replace(array('.','^','$','*','+','?','(',')','[','{','\\','|'),'',$searchArray[$i]);} if(strtolower($search_mode) == 'like'){$searchArray[$i] = str_replace(array('_','%'),array('\_','\%'),$searchArray[$i]);} So, AND I.product_code RLIKE '[[:<:]](not[[:>:]]' AND I.product_code RLIKE '[[:<:]]sold)[[:>:]]' will now look like: AND I.product_code RLIKE '[[:<:]]not[[:>:]]' AND I.product_code RLIKE '[[:<:]]sold[[:>:]]' Even if escaped, as in '[[:<:]]sold\)[[:>:]]', the database engine would still ignore the escaped closing parenthesis because it is not an alphanumeric character. In an RLIKE search term such as St.Louis, (no space) the period will be stripped, resulting in the term being StLouis.

A proper solution would be more involved than the following (a proper list item on the Transaction Logs tab, for example), but here is an edit that puts a field on the Billing tab - which I think is more appropriate than Delivery. In the admin template orders.index.php, find near line 264: <fieldset> <legend>{$LANG.account.contact_details}</legend> On a new blabnk line ABOVE that, add: <fieldset> <legend>{$LANG.orders.gateway_name}</legend> <div><label for="sum_gateway">{$LANG.email.macro_gateway}</label><span><input type="text" id="sum_gateway" name="summary[gateway]" value="{$SUMMARY.gateway}" class="textbox"></span></div> </fieldset>

Good observation. I think posting an issue in the Github is in order.

I do not see anything wrong with the overall structure of the query. I would therefore conclude the problem is within a regex pattern, which does use parentheses for 'grouping'. So, AND I.product_code RLIKE '[[:<:]](not[[:>:]]' AND I.product_code RLIKE '[[:<:]]sold)[[:>:]]' has parentheses which will cause problems. This illustrates a need for the search terms to be "escaped" against regex control characters, or have those characters stripped out.

Depends what you want to do. If the edit is to change a wortd or two, then an UPDATE query should work. More than that, I suggest you find a CSV Editor dedicated to the task of editing and managing CSV files. As always, there are free, but competent, tools with a basic, but common, feature set. Then there are not so free applications that can do wonders on a CSV file. A spreadasheet is NOT the tool to use on a CSV file, even though spreaadsheets usually read and write CSV files. They are horrible at managing the data in them. Have phpMyAdmin dump the inventory table to a CSV, make your edits as efficiently as possible, then import the CSV back into a truncated table.

If the command ini_set() is still disabled, the consequences -- not seen as yet -- will come back to bite you in the ....

The Warning, not so much of a critical issue. The call to mb_strlower() is necessary for CC615 (and maybe a couple earlier versions). If you are hosted by a commercial operation, you will need to have them change to a more recent version of PHP, or to somehow add the Multi-Byte library to PHP. This may involve re-compiling PHP from its source with Multi-Byte capability included in the options. (On Linux systems, apparently it's fairly easy to compile PHP with whatever optional capabilities are needed.) The command ini_set() being disabled is a critical concern. Even the admin side of CubeCart wants to use ini_set(). So why admin works is a mystery. Why CC5 worked is a mystery. If there are only some settings that can't be overridden, maybe that's what is going on. But this is a critical issue that must be resolved with your hosting provider.

The 'missing column' situation should not be causing the Homepage to not display. That particular query simply gets a "friendly" version of a link to a category page. If there is no result from the query, CubeCart should not crash. If a blank Homepage is still an issue, please create the error_log and maybe there is a clue we can explore.

If the latest CC6 codebase overwrote the CC5 codebase (typical procedure of a CubeCart upgrade), but you did not run to completion the www.mystore.com/setup/index.php process, then the database may not have the necessary structure to successfully run CC6. If you haven't run setup, please do so. Make sure it runs to completion. (Some browsers can have meta-redirect disabled - meaning for each step of the database upgrade sequence, the user will need to click Continue.) I mention this because having the 'custom' column missing in the CubeCart_seo_urls table indicates to me the setup did not run to completion.

There is this: https://www.cubecart.com/extensions/plugins/absolute-matrix-option-prices-price-list-hide-out-of-stock-matrix-options

This is an ongoing concern. The essential problem is, what happens when there is more than one option? Size, Color, Style An option matrix can get out of hand very quickly, and it is only through the options matrix that allows for stock levels of specific option combinations. For example, a "Black 12" is out of stock, but a "Black 10" and a "Red 12" is available. Neither "Black" nor "12", individually, can be indicated as unavailable. I have seen 1D and 2D tables created from the options matrix. Any dimension above that will require being very inventive. I did, however, make a Dynamic Stock Level Indicator that, once all required options were chosen, a query was sent to the store to determine if it was available.

Not as a part number. VARCHAR and TEXT and BLOB, etc, do not cause the database server to act on mathematical symbols. However, CubeCart does, but in a way that shouldn't cause any problem as hypothesized.

CubeCart destroys sessions when the customer or admin actually logs out. I would recommend against not being able to log out. The timeStart is when the session first logged in, and the timeLast is when the most recent page request was made. For every page request, CubeCart is supposed to send back the same cookie with a new expiration date/time that is for the customer according to that setting in admin, and for the admin, no expiration as the cookie is considered a "session" cookie (the browser keeps it alive until the browser is closed). Customer #255 has made their most recent page request 261 seconds.after logging in. When rows in the sessions table get deleted, CubeCart is clearing out obsolete entries. There is a function in cc_session.php, deleteOldSessions(), that takes the time duration set in admin, subtracts it from now to get some past date, then deletes all records where timeLast is less than that past date. Thus, having zero as that admin setting will cause quite a bit of confusing session behavior.