My tables broke and I didn't touch them, honest

There is a repeater in the website that I have been working on with each element containing a table. The columns have field names Time, ct1 and ct2. In the editor, those are still shown as their names and everything still works fine in preview mode. Here is the relevant part of the event handler for the table …

export function tblTimes_cellSelect(event) {

 let $item = $w.at(event.context);
    console.log(event);
 
 // Court number and time (row in table) give record ID
 let numRow = event.cellRowIndex; // 0 - 12
    strCourt = event.cellColumnId.substr(-1); // 1 or 2
    bookingInfo.record = ( "0" + (numRow + 8).toString()).substr(-2); // "08" - "20"
    bookingInfo.record += "-0" + strCourt; // "08-02", "19-01" etc.

Testing on the live site on Edge, Firefox and Chrome finished last week, and from then until today it has not been edited. And yet somehow, it broke. The console.log shown above was inserted today. The site events panel shows that event.cellColumnId now returns the following depending on the column selected:

columnId_7f600ee7-c616-4484-8121-c931f34f0c99
column_komrrb1l

Needless to say, the site is not working as well as it did when tested. What on earth? Can anyone cast light on what is going on please?

UPDATE - there is a similar problem with a plain table, not in a repeater, elsewhere on the site.

I think I had a similar issue a while back. You are better off setting the table column headers on your page load using:


$w(“#myTable”).columns = [
{
“id”: “col1”,
“dataPath”: “field1”,
“label”: “Field 1”,
“width”: 100,
“visible”: true,
“type”: “string”,
“linkPath”: “link-field-or-property”
},


I suspect the gibberish id you see is being set by WIX, and it should not in theory overwrite your id.
columnId_7f600ee7-c616-4484-8121-c931f34f0c99

Hope this helps

Thanks, Prasanth

Let’s start with the bad news: as far as I’m concerned, this incident blows the credibility of Wix as a web host - and that was my real point (though initially more politely made).

Now the good news: it’s a low traffic, non-commercial site and it was only broken for a few hours while I worked out the problem and coded round it. As it happens, I went the other way from what you have suggested and read the column IDs into arrays on page load. The cellSelect event now checks whether the correct ID has been returned, and if it has not it resorts to searching the relevant array.

First reason for doubting the credibility of Wix: the site was working, no changes were made, and then it stopped working.

Second reason for doubting the credibility of Wix: the live site now behaves differently from the site in preview mode. In preview mode the correct column IDs are returned. On the live site, the “gibberish” values are returned.

Case 1: the web site, without any changes from me, became corrupt.

Case 2: the behaviour of the cellSelect event was suddenly changed.

Case 3: I’m to blame in some way - and I don’t count not knowing that Wix randomly break things as a reason to blame myself.

Do you know of any other things that randomly break on Wix sites so I can code round them before they get me?

Oh where do I start? According to my experience wix as a platform is not stable to put it mildly. At best it is good to host stunning static pages.
Here is my rant about it a week back :-
https://www.wix.com/velo/forum/coding-with-velo/nasty-surprises-from-wix-almost-every-other-day
Except for a few good souls in this community, their technical support is clueless or helpless or both in all my earlier interactions with them.

@mike13529 Please post the URL of your site and explain where and how to see the problem.

@yisrael-wix Morning Yisrael, and thank you very much for taking an interest. It’s the site that I run for my local village tennis club. One of the affected pages is here: HUTC - Court 1 (wixsite.com) . It’s a members-only page, but either you can sign up or you can probably use the power of Wix to get in. The problem comes when you click on one of the tables, though I’ve coded round it so the site is not broken.

The relevant bit of the cellSelect event “as was” is shown in the original post. Now the code is modified as follows:

/********** before page load **********/

let Wk1colIDs = [];
let Wk2colIDs = [];

let txtWeekDays = "xxxMonTueWedThuFriSatSun"; //used to convert day names to numbers (Sunday is 7, not zero)

/******* in page load *******/

 // Store away column IDs in case they turn out to be screwed

 for (let i = 1; i < 8; i++) {
 Wk1colIDs[i] = $w("#tabWk1").columns[i].id; 
 Wk2colIDs[i] = $w("#tabWk2").columns[i].id;
 }
 
/******** in event handlers *********/
 
// Handle click on Week 1 calendar

export function tabWk1_cellSelect(event) {

 let recordID = $w('#tabWk1').rows[event.cellRowIndex]._id; // record ID: hour-court (08-01)
 
    console.log(event.cellColumnId);

 // Check that a valid day is selected rather than Time
 // Check whether we get "Mon" etc. for column name or random strangeness

 let txtBkDay = event.cellColumnId.substr(0,3);
 let numBkDay;

 if (txtWeekDays.search(txtBkDay) == -1 ) { // first check if a weekday was returned
        numBkDay = Wk1colIDs.indexOf(event.cellColumnId); // if not, decode colID from values stored at page load
        txtBkDay = txtWeekDays.substr(3 * numBkDay,3);
 } else {
        numBkDay = 1; // any value other than zero will do at this point
 }

// .........

The console.log will show you that when you select Monday this week the cellColumnId returned is columnId_720c5dc1-511e-47b7-98d4-e0cdce02880b. If you are able to get into preview, you will see that clicking the same day returns Mon.

As I mentioned in the original post, this behaviour started a week or so ago after the web site had been tested (not sure exactly when). I had made no edits for several days at the time. Previously the ColumnId was Mon both in preview and on the live site.

Mercifully I’m not in a position similar to that of prasanth where a commercial customer is screaming at me. But even so, there is a certain amount of egg on my face here.

It’s not so much the specific problem that troubles me as the blow to my confidence that a site on Wix can be expected to continue to behave as it did when it was developed and tested. I’d like to know what happened! Is the site corrupt, and if so, how to recover it? Did something at the Wix end change, and if so how to know when and what will change to be prepared?

And my question to prasanth, which he has now answered, was not a joke - it was absolutely key: what other gotchas do I need to watch out for? For example, if it was documented that cellColumnId is subject to “spontaneous change” then that’s not exactly cool, but it’s survivable.

Ahh … there’s another thread that has some relevant information if it is still current:

Wix not properly rendering computed values? | Velo by Wix

Here, on May 27th, Yisrael mentioned that …

Preview and Live are currently rendered with different engines. Preview will eventually be rendered using the same engine as Live.

Hi Mike,
We will be reverting the change shortly and then introducing a new solution. I’ll keep you posted as soon as I have an update.

@marlowe-shaeffer Thanks, Marlowe