Issues after update to 3.6.0.3

[jfquestiaux]

I ran into a serie of issues when updating 2 sites to the latest Fabrik 3 version.
it took me a lot of testing to get a hold of what is happening and when because it is kind of strange! Basically, it looks like an inversion of data :

First some reference :
Here is the page of the site BEFORE update (unfortunately, I am not sure which version it is - the version number in the extension manager reads 3.0.6.2 but I am not sure this is correct) : http://duvaldepyrene.com/naissances-montagnes-des-pyrenees.html (see picture 1) - click on "Semaine 1" to get the second list (picture 2)

Here is the same page AFTER update to 3.0.6.3 - Git94 : http://realisation-joomla.be/pyrene2/naissances-montagnes-des-pyrenees.html (picture 3)
Notice that the link "Semaine 1" is now "1", which is the value of the label of this simple dropdown element. Also the link to the view detail is gone!

The link from "1" is still correct though but on the second list you see more of thess "inversions" (picture 4) : the "Port?e" column has now a different label and the "Sexe" column is replace again by the value of the element ("1" instead of "Male"). And on this one a checkbox to the detail view appeared out of nowhere (there should not be one!) and if you click on it, you get a blank page.

During my tests, I proceded by steps, so I first updated to 3.0.6.3 + Git0.
At this stage, I had the following issues :

• No inversion of the dropdowns and databasejoin elements values/label (link "Semaine 1" was still "Semaine 1")
• The "inline" button was replaced by the "floating" one on list 1
• In order to view the correct detail view, the SEF slug is used but now it does not seem to be picked up, so all records point to the same detail (the first record) since they all have the same URL - maybe it is an intended change of behavior of the sef slug. In that case, I'll have to make some changes on my sh404SEF sef plugin. But if it is a bug, let me know first.

Updating to Git94 made things worst as described above.


I wonder if this is not a problem for sites that were built using early versions of Fabrik 3 (like this one made in January) and updated regularly since then because I've worked on a new project begun at the end of July (probably with Fabrik 3.0.5) and I don't seem to have the same problem.


I hope you can provide some insight on what is happening.

 

[rob]

Semaine 1" is now "1", which is the value of the label of this simple dropdown element.....the "Port?e" column has now a different label

Yes I saw that yesterday - the fix for that should be in github

The "inline" button was replaced by the "floating" one on list 1

This might be resolved by saving the list? I'm really not sure why or how the default changed. (Possibly to do with better type casting required by jshint altering which option is used.)

In order to view the correct detail view, the SEF slug is used but now it does not seem to be picked up

I can't see this one. Is this with sef404? I've only tested with the native sef urls, and they seem to work ok

 

[jfquestiaux]

hello all,

Been away for some time, so I just resume testing on the issues I had on upgrading to recent fabrik 3 version.

Some of the issues described in the first post are cleared, but some remain.

Setting: I have two versions of the same site, on the same virtual server (the test one is in a subdirectory).
The live site is working fine with unfortunately a version dated on July 12th.
The test site has the latest GitHub version (227).

I have 2 main lists, all with issues.

Issues:
List 1 :

the correct one is at this address: http://duvaldepyrene.com/nos-chiens-montagne-des-pyrenees.html - In the column "Expositions", I have a custom link to another list with filtering options.
​

This link is

index.php?option=com_fabrik&view=list&listid=2&Itemid=189&expos___year={pedigre_chiens___exhibits_raw}&expos___id_dog_raw={pedigre_chiens___id}&resetfilters=1

This gives for instance the following URL : http://duvaldepyrene.com/nos-montag...id_dog_raw=1&expos___year=2009&resetfilters=1 which lead to the correct information.

After the upgrade, the same URL is now http://duvaldepyrene.com/update/nos...dans-les-expositions-canines.html?expos___id_dog_raw=&expos___year=2009 (the "1" is missing), so the filtering does not work obviously.

It is clearly a bug since it is specifically related to making a link to the "id" element. If I change {pedigre_chiens___id} by {pedigre_chiens___gender} for instance, the placeholder display the correct data.

The second issue on this list concerns the link to the detail view. In the original one, the link uses the list slug to diferanciate the items in the list.
In the upgraded one, all the links have the same "index.html" ending, so all the records have the same address.
I use sh404SEF to rewrite the URL, but I think it can be related to the "id" issue since the SEF plugin uses this data to build a correct url name.

​

List 2:

Original URL: http://duvaldepyrene.com/naissances-montagnes-des-pyrenees.html - The inline button to the detail view is replaced by the floating version.

Not a big deal in itself: you just have to select "inline" again and save the list.

But there is the same issue with the URL to the details: all the records have the same "index.html" URL instead of one using the list slug.

​

So, I may need to update the sh404SEF plugin, but first I would like to have this "id" issue fixed, because they may be related.

 

[cheesegrits]

Looking at this one now.

-- hugh

 

[cheesegrits]

Assuming that pedigre_chiens___id is the primary key on the table you are linking from, can your try {pedigre_chiens___id_raw}, and/or {rowid} instead?

-- hugh

 

[jfquestiaux]

I did try {pedigre_chiens___id_raw} but with the same result. I will test the other one.

 

[jfquestiaux]

OK, {rowid} works.
I guess I'll have to start working on the sh404SEF plugin now to figure out why it is not picking up the different rows now.
Thanks.

 

[cheesegrits]

I'm curious as to why neither {pedigre_chiens___id_raw} or {pedigre_chiens___id} work, as those really should be present as placeholder data at the time the row is built.

Do you have any access controls set on that id element, in the Access tab for it?

Do you have 'include in query' set to No under the List settings tab?

-- hugh

 

[jfquestiaux]

Yes there is a access level set : for "visible", it is set to "special" (I forgot about that). it is just so that the admin can view the row id on the list and the public can't.

So that is probably the source of the problem, but it used to work fine till July.

 

[cheesegrits]

Yup, that'd screw things up. I'm guessing it only worked before then due to us not properly enforcing individual element access controls.

Strongly suggest you set edit and view back to Public. Not really a security issue, especially as the ID has to be visible to everyone in the links and resulting URLs.

-- hugh

 

[cheesegrits]

The thing to bear in mind is that if an element is not viewable by someone, it won't get included in the row data available to anything else when building the List. In fact, it won't even get included in the main data query we build the row data from. The {rowid} paceholder only works because we always include the PK in the query, referenced as __pk_val (or some such), which gets used to stock the {rowid} placeholder. But the full element name just won't be there, if non-viewable.

So just set the 'id' not to show in the List, but leave access at Public.

-- hugh

 

[jfquestiaux]

I undersand but you do agree this is a relatively new behavior.