Creating wrong URL in related data links

actionwave34F

actionwave34F

Member
Think I found a bug.
models/list.php row 1767:
$linkWhere[] = 'link LIKE "index.php?option=com_' . $package . '&view=list&listid=' . (int) $element->list_id . '%"';
At the end there is a "%" for the LIKE. I have to remove it coz it gives any hit with listid 3 , 31, 39 , 303 in random order connecting the list to wrong itemID. Remove %!
The resulting URL has wrong concepts but correct list data.
 
I assume you are not running a recent GitHub version.
The function getTableLinks() is not longer used (there are additional issues).
 
I was afraid of what u say in ur answer.
Generally speaking it is very difficult to have a stable and verified system/application solution when I have to "upgrade" a lot. Generally speaking I have to retest everything as soon as I put an "upgrade" from GitHub. It can solve some problems but is the application working? We have a pretty big one.
So the github "version" is what ? 3.3.3? Or 3.3.2.x ? Or? Or running nightly builds? Are they tested?
If I am forced to "upgrade" where is the changelog for the "versions"? I need to know what has changed and how.
Please advise.
 
GitHub is some sort of "nightly (or hourly) build, not especially tested 3.2.2.x version", it's not accessible via Joomla updater and you can't install the GitHub zip (you must copy the files).
So you shouldn't use it untested on a productive site.

But it contains bug fixes and enhancements.

Usually you shouldn't do cherry picking (there may be dependencies) but in your case have a look at
https://github.com/Fabrik/fabrik/commit/f239ced6040b0106c57a4bcd3fb38747447d902c
 
Ya , thanks.
Cloned the current respositories and I see what is going on concerning commits.
Well, I think to pick cherries are a risky thing. No , we are going for a a total upgrade and retest. Only way.

Thanks for info
 
Today we gave it another try to track down the problem that related data link URL's in lists are sometime wrong. It turns out that the ItemId used to create the URL route is wrong. That ItemID is NOT poining to the related data link list but instead using originating ItemId. On top of this giving the "listid" to find the real ItemId the method FabrikWorker::itemId($listid) is not responding with correct data. Giving the argument, the search in table menu for the "listid" has 3 flaws. "LIKE" with % at the end , possibly returning more than one row and component name ("fabrik" instead of "com_fabrik"). Fixed that and still not working. Oh language. There are several rows in our menu table with same "fabrik link". Added that to SQL predicate and its working. Good for our need as we always run the application with a certain logged in user. We add the code here and maybe you can look into a more general solution for public use and multilanguage ( selected from language switcher).

Actively using listid model::list.php line 2072
PHP: 
    protected function releatedDataURL($key, $val, $listid)
    {
        $app = JFactory::getApplication();
        $Itemid = FabrikWorker::itemId($listid);
The ItemId is returned from itemId() in file helpers::parent.php line 1805 - 1825
PHP: 
        if (!$app->isAdmin())
        {
            // Attempt to get Itemid from possible list menu item.
            if (!is_null($listId))
            {
              $euser = JFactory::getUser();
              $mylanguage = $euser->getParam('language', 'sv-SE');
              /*Here we at actionwave propose to get site language if no user logged in. $mylanguage must have a valid language code*/
                $db = JFactory::getDbo();
                $query = $db->getQuery(true);
                $query->select('m.id AS itemId')->from('#__extensions AS e')
                ->leftJoin('#__menu AS m ON m.component_id = e.extension_id')
                ->where('e.name = "com_fabrik" and e.type = "component" and m.link LIKE "%listid=' . $listId.'"'
                .' AND '.$db->quote($mylanguage) .' = '.$db->quoteName('m.language'));
                $db->setQuery($query);

                if ($itemId = $db->loadResult())
                {
                    return $itemId;
                }
            }

            $itemId = (int) $app->input->getInt('itemId');

            if ($itemId !== 0)
            {
                return $itemId;
            }

Regards from Sweden
 
Hi
I'm not convinced for the language filter - reading the code I don't see how it will find menu items which have language="*" ?
I think you would need to add that into the query somehow and then order the results so that any link matching the current lang is returned before a langauge = * link.

Otherwise removing the last % from the query makes sense to me. I'll commit that change now.
 
Well , you are probably right. I am not convinced we have a robust solution. We know from history that ItemId and language are "problematic". Well if no language can be detected then of course you cant look for this in menu table. Some tweaking needed. Let me know if you have some more thoughts on this coz we have to have a solution soon that works. We dont need a general solution for now.
 
Some additional info and adopted solution. It is crucial to detect the currently selected language from browser, site, user or language swt?cher. The language switcher plugin must be correctly set. By doing that u can detect the language. Tested in swedish and english environments but there could be more cases I can't think of. I have not tested if u do not have any defined lanuage or general purpose site without user login. Somewhere in the menu table u need to have a record pointing to your list with related data. One for each language.


public static function itemId($listId = null)
{
$app = JFactory::getApplication();

if (!$app->isAdmin())
{
// Attempt to get Itemid from possible list menu item.
if (!is_null($listId))
{
$db = JFactory::getDbo();
$mylanguage = JFactory::getLanguage();
$mytag = $mylanguage->getTag();
$qlanguage = '';
if (!empty($mytag) ) $qlanguage = ' AND '.$db->quote($mytag) .' = '.$db->quoteName('m.language');
$query = $db->getQuery(true);
$query->select('m.id AS itemId')->from('#__extensions AS e')
->leftJoin('#__menu AS m ON m.component_id = e.extension_id')
->where('e.name = "com_fabrik" and e.type = "component" and m.link LIKE "%listid=' . $listId.'"'.$qlanguage);
$db->setQuery($query);
if ($itemId = $db->loadResult())
{
return $itemId;
}
}

$itemId = (int) $app->input->getInt('itemId');

if ($itemId !== 0)
{
return $itemId;
}

$menus = $app->getMenu();
$menu = $menus->getActive();

if (is_object($menu))
{
return $menu->id;
}
}

return null;
}
 
Well , I'm afraid there is a problem here again in version 3.3.3 ( github 2015-10-27) but partly related to previous change.
We discovered that the related data links generally are working but always going to origin list.
There is a bug in /components/com_fabrik/models/list.php row 2085 . Should be if (is_null($listId)) . Somebody changed from $listid to $listId and missed one.

To be able to view field data in the viewed list we have to give the listId fo the call in row 2139.
$itemId = FabrikWorker::itemId($listId);

In /helpers/parent.php you have to address the compenent right as , line 1783:
->where('e.name = "com_fabrik" and e.type = "component" and m.link LIKE "%listid=' . $listId . '"' . $qLanguage);

Patching this it is working fine. So far.
 
Yes we are testing . Every day. A couple of systems in the pipe. One in production so we don't dare to upgrade that until this is "stable".
Well , I don't fully understand the logic with listId and ItemId and the implications to change as we proposed. Anyway it's working for us .
 
I don't fully understand the logic either, lol, which is why I'm not going to make that change just yet.

Well, I understand the logic, which is that if we don't provide a list ID, the itemId() helper will only look for the itemId in the query string. If a list ID is given, it will first look to see if it can find a Fabrik list menu item which uses that list ID.

What I'm not sure about is, if there is more than one menu item which uses the same list ID ... the fetchResult() in the database query is just going to grab the first occurrence, so you could wind up with the wrong itemId, even though the right one is in the query string.

-- hugh
 
My thinking is we will probably have to add a new option allowing the user to either use the default guestimate behavior or specifically state which menu item contains the list.... Does that make sense?
 
Yes.

BTW, this kinda semi-relates to @troester's long running issue with menu pre-filters, i.e. being able to bypass them by just removing the itemId form the URL, and/or the wrong filters being applied to other lists loaded under the same itemId. I tried fixing that, but of course immediately ran in to a similar issue of there being no way to reliably map a list ID to an itemId internally, if the itemId is not in the query string / posted data. And I don't think there is an "easy" fix for that, without basically defeating the entire purpose of menu based pre-filters, which is to allow different filtering on a list without having to copy it. I occasionally come back and mull this over, but really can't see a way of making menu pre-filters "secure".

Anyway ... just another listid / itemId issue to bear in mind.

-- hugh
 
helpers/parent.php row 1767...
the extension name is still 'fabrik' . Must be "com_fabrik".
For a non multi-language site, I had to set qLanguage to '' in the source. I have not run debug to check the value of $myTag.
 
You must log in or register to reply here.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    No members online now.
    Total: 198 (members: 1, guests: 197)
    Back
    Top