Jump to content

[Resolved] Database Has (Sort Of) Lost Previously Collected Mandatory Data - BUG in v5 Skin


Daamon

Recommended Posts

I've had a reply to my issue raised in GitHub, now closed: " This is due to a bug in an old/3rd party skin" - no other information was given, prompting questions:

- How do I check what skin is currently in use?

- Is it easily changed / how?

- And any recommendations on a skin which isn't old or 3rd party / will work OK?

Link to comment
Share on other sites

  • Replies 79
  • Created
  • Last Reply

Top Posters In This Topic

Your best result would come with Foundation. I made a lot of cosmetic changes to my Foundation, so I copied it, renamed it to suit myself, and use that on our sites. That way my tweaks don't get over-written with each upgrade. Of course if there IS a change in the Foundation files in an upgrade, I make those edits to my version.

Sometimes I can tell what skin someone here on the forum is using by looking at the Source Code. There's usually something with the skin name in it. Bsmither would probably be the one who can spot your skin easily.

Please provide your store url.

Link to comment
Share on other sites

I very much doubt if it's heavily modified - as we invariably don't tinker unless we're trying to fix something. I've had a look at the files in the skins\mican\templates directory and all are 19 August 2014 except two dated 26 October 2015: content.profile.php and content.register.php. I can't recall if these were updated for a reason - I'd have to dig through other threads I've started here...

Other folders contain files dated 19 August 2014 or even a date in 2012.

Link to comment
Share on other sites

You could use a file difference program like BeyondCompare to compare the stock Mican skin with yours. Then it would be a matter of backing up your skin file and trying the stock Foundation skin, adding any edits that were required - based on what was not stock in yours. I'd be willing to bet that most, if not all, the Mican changes you have are now part of stock Foundation.

Of course there would be cosmetic changes you needed to make, but the site should work properly - you are on 6.0.12 now, aren't you? (There was a flurry of GitHub activity today - that's often an indication that a new upgrade is coming fairly soon.)

You don't have to delete your Mican skin - just add in the choice of Foundation while you kick the tires.

 

Link to comment
Share on other sites

Where do I get a copy of the stock Mican file from? I can't see anywhere in the File Manager structure where it might be.

Yes, we're now on CC6012.

Does Mican come with CC? If so, what I don't understand is if we're on the latest version, why is this skin still available if it causes issues?

Link to comment
Share on other sites

Anything that comes in the Mican download is suspect and should be compared. According to the Announcement thread on here 6.0.4 came out in April of 2015. So I guess any v6 past that could "potentially" have v5 skin issues that needed addressing. I've reached the end of any help I can be for you on this.

Link to comment
Share on other sites

We need to steer away from bringing a storefront skin into this conversation.

Losing data from an order summary while the admin is managing these orders in the backend (admin functions) involves the backend skin found at /admin/skins/default/.

Even though an identical bug was (supposedly) fixed with a code change in an admin skin template, the response to this current issue about a bug in a third-party skin is non-sensical.

We are still waiting for a report on the analysis of the POST seen in the waterfall from the admin saving the order summary.

Also, instruct your staff that when viewing the waterfall, take a screen capture of the entire waterfall window. We will now have a record of most of the activity that we can refer to when additional questions come up.

Link to comment
Share on other sites

@bsmither Thanks for that and, on reflection, it makes sense.

All but 3 of the files in the admin/skins/default/templates folder are dated 16 June 2016. The three older ones all dated 19 August 2014 are licence.error.php, modules.index.php and upgrade.index.php. Elsewhere, ie7.css is dated 19 August 2014. All other files are 16 June 2016.

It'll be me doing the analysis on the POST and I'll get the waterfall screen capture too. Thanks!

Link to comment
Share on other sites

On 8/2/2016 at 9:14 AM, bsmither said:

To view the POSTing, you will need to view the "waterfall". I prefer Firefox with the Firebug addon, but Firefox has its own internal "Network" tab and other browsers have their own set of developer tools.

In Firefox, click the menu icon at the upper-right (looks like a hamburger). Select "Developer" (looks like a wrench). Select Network. A new window pops up.

View an order that has NOT had the text option values disappear. Visit the Inventory tab. Take notes on the values of textual options -- just in case they disappear.

Make some small edit -- perhaps adding a Note that the customer will not see. Save.

In the Developer Netork window, you will see the waterfall populate. The first line is the POST. Click once on that line. A new panel opens with the details of that POST. Click the PARAMS tab. In the Request Payload, scroll to where you see:

You should be able to find the text-based options. If you don't find what you took notes of earlier, then there is a problem with the HTML page and the variables that the form is POSTing back.

@bsmither Above instructions followed. Two files uploaded:

1) Waterfall screenshot, as requested...

2) PARAMS in a .txt file (personal information removed)

Next steps?

order_params.txt

waterfall.png

Link to comment
Share on other sites

I find this in the text capture of the PARAMS tab:

Lines 132-155:

-----------------------------236551371019030
Content-Disposition: form-data; name="inv[2602][product_id]"

55
-----------------------------236551371019030
Content-Disposition: form-data; name="inv[2602][productOptions][18][102]"


-----------------------------236551371019030
Content-Disposition: form-data; name="inv[2602][productOptions][17][103]"


-----------------------------236551371019030
Content-Disposition: form-data; name="inv[2602][productOptions][16][104]"


-----------------------------236551371019030
Content-Disposition: form-data; name="inv[2602][productOptions][15][105]"


-----------------------------236551371019030
Content-Disposition: form-data; name="inv[2602][price]"

35.00

The variables (actually called 'keys') that start with inv[2602][productOptions] have as part of the keys a pair of numbers, such as [18][102] and [17][103].

These keys with number-pairs are the text entry boxes.

There are no corresponding values (as seen like the product_id and price).

So, working on the theory that the HTML of the form is not coded correctly, let's review:

/admin/skins/default/templates/element.product_options.php, near line 27:

<div class="dymanic_options">
   <label for="option_{$option.option_id}" class="return">{$option.option_name}{if $option.required}  ({$LANG.common.required}){/if}</label><br>
   <span rel="{$product.id}">
   {if $option.type == '1'}
   <input type="text" class="text_calc" placeholder="{if $option.price}({$option.symbol}{$option.price}){/if}" name="inv[{$product.id}][productOptions][{$option.option_id}][{$option.assign_id}]" id="option_{$option.option_id}" value="{$option.value}" rel="{$option.symbol}{$option.decimal_price}">
   {elseif $option.type == '2'}
   <textarea  class="text_calc" name="inv[{$product.id}][productOptions][{$option.option_id}][{$option.assign_id}]" rel="{$option.symbol}{$option.decimal_price}" placeholder="{if $option.price}({$option.symbol}{$option.price}){/if}" id="option_{$option.option_id}">{$option.value}</textarea>
   {/if}
   </span>
</div>

In the <input type="text"> and the <textarea> lines, each uses {$option.value} (seen near the end of the statement).

Please confirm that the code in your copy of this file has {$option.value}.

Also:

/admin/skins/default/templates/orders.index.php, near line 339:

<td>
  <span class="editable" name="inv[{$product.id}][name]">{$product.name}</span>
  {include file='templates/element.product_options.php'}
</td>

Make sure that your copy of this file uses the {includes} statement, and does not have actual code to show the options.

Lastly, I have seen evidence of an alternate admin skin available for CubeCart. So, in admin, Store Settings, Layout tab, make sure "Default Admin skin" is set to 'default'.

 

Link to comment
Share on other sites

8 hours ago, bsmither said:

I find this in the text capture of the PARAMS tab:

@bsmither Hi. I think I searched for "product options" (with the space), hence not finding anything - sorry for the confusion.

8 hours ago, bsmither said:

/admin/skins/default/templates/element.product_options.php, near line 27:

Please confirm that the code in your copy of this file has {$option.value}.

This appears to be the case. The file "Last Modified Date" is 16 June 2016. Code lines copied below:

<input type="text" class="text_calc" placeholder="{if $option.price}({$option.symbol}{$option.price}){/if}" name="inv[{$product.id}][productOptions][{$option.option_id}][{$option.assign_id}]" id="option_{$option.option_id}" value="{$option.value}" rel="{$option.symbol}{$option.decimal_price}">

<textarea  class="text_calc" name="inv[{$product.id}][productOptions][{$option.option_id}][{$option.assign_id}]" rel="{$option.symbol}{$option.decimal_price}" placeholder="{if $option.price}({$option.symbol}{$option.price}){/if}" id="option_{$option.option_id}">{$option.value}</textarea>

8 hours ago, bsmither said:

/admin/skins/default/templates/orders.index.php, near line 339:

Make sure that your copy of this file uses the {includes} statement, and does not have actual code to show the options.

This appears to be the case - note it's "include" not "includes", no "s", in the code. The file "Last Modified Date" is 16 June 2016. Code line copied below:

{include file='templates/element.product_options.php'}

8 hours ago, bsmither said:

Lastly, I have seen evidence of an alternate admin skin available for CubeCart. So, in admin, Store Settings, Layout tab, make sure "Default Admin skin" is set to 'default'.

Confirmed, Admin skin is set as "default" (see screen shot) and this is the only option.

Thanks.

 

Admin_Skin.PNG

Link to comment
Share on other sites

The next step, and possibly the last without getting into some really serious troubleshooting, is to examine the source HTML as received by the browser.

You will be able to use the Developer screen, Inspector tab to scroll through the HTML and find the form elements.

In the template source, where it has {$option.value}, this placeholder gets populated with the text string -- the text that is missing when getting POSTed.

Is there a value for the input (or textarea if that is the type of text entry) in the HTML as seen by the browser?

Link to comment
Share on other sites

Hi @bsmither. I "think" I've got what you're asking for - I've attached two screenshots: 1) of an order which hasn't been changed and saved, and where the text entries are showing (rego removed, but was present); and 2) an order which has been changed and where the text is no longer appearing. Screenshots are taken with the Inspector showing the HTML.

Is this what you were asking for?

 

Inspector_with.png

Inspector_without.png

Link to comment
Share on other sites

Almost...

On the order that still has text options showing, we need to see the HTML source of the Inventory tab. So, look for this:

      <div id="order_inventory" class="tab_content">
         <h3>Order Inventory</h3>
         <div style="display: none;">
            <span class="actions">
            <i class="fa fa-trash" title="Delete"></i>

After locating the above, scroll further down a few lines to find:

                     <span class="editable" name="inv[###][name]">name_of_product</span>

where ### is a number. Then, just after that, you will find the input of type="text". Be sure to scroll horizontally so we can see the value="???" attribute of the input tag.

Link to comment
Share on other sites

Hi @bsmither. Two screenshots attached: 1) Order summary showing details (rego removed); 2) Inventory tab (as requested) showing relevant fields - blank, and HTML code.

Please note that these Inventory fields have never contained any data ever since I intoroduced them.This is covered in a separate thread:

...but not pursued because having the data in the Order Summary was good enough.

OrderSummary_with.PNG

Inventory_with_fail.PNG

Link to comment
Share on other sites

Is what I am looking at above, an order that has never been edited? Are you saying that even for orders that have not been changed, you have never seen the text-based options displayed on the Inventory tab?

The General tab uses {$product.options_text} (which is a simple text string), where the Inventory tab uses {$product.options} (which is an array). (Note: in both cases, {$product} is an array element from {$PRODUCTS}.)

If this is the case, and we now know that the template code is valid, and that an unedited order will have the necessary data in the database table CubeCart_order_inventory "product_options" and "options_array" columns, then the thing left to discern is where in the controller code the $product's $options array is not getting built.

But, before we proceed, please verify that the order shown above has not been administratively edited/saved in any way.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...