Treeview in french culture not loading

[r.ruti...@docuteam.ch]

Hi,

I have a strange behavior here. The treeview loads for all languages (german, english, italian) but not in french. 

I found out the URL that is actually loaded:

https://example.com/index.php/digital-inbox-gd/informationobject/fullWidthTreeView?nodeLimit=10000&sf_culture=de

(works)

https://example.com/index.php/digital-inbox-gd/informationobject/fullWidthTreeView?nodeLimit=10000&sf_culture=fr

(blank page, and most important: no error message in any of the log files)

Do you have an idea what the cause is?

Cheers, Roger

[Dan Gillean]

Hi Roger, 

I will see if I can reproduce this issue locally. What is the default installation culture of this site? What is the full version number listed in Admin > Settings? And, do you have French added via the language settings (and have you reindexed since adding it)?

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/087aa50f-58a6-4bb5-9c63-6b466d8401a7n%40googlegroups.com.

[r.ruti...@docuteam.ch]

Hi Dan,

The default is "de" (german). 

Full version: 2.6.3 - 184

And yes, french is added via the language settings, and reindexing ran several times since.

Thank you for looking into this!

Cheers, Roger

[Dan Gillean]

Hi Roger, 

I've done a bit of testing, and so far have been unable to reproduce this issue in my local qa/2.x environment. So, either the issue is addressed in our development branch, or (perhaps more likely) there is some local issue occurring. Can you provide me with a bit more information?

First, how exactly are you arriving at these example URLs? Typically the treeview is displayed on the information object view page (which just uses the slug of the description) - there's not normally a /fullWidthTreeView?nodeLimit=10000 part of the URI that I recall. The hierarchy browser (for browsing all information objects) uses /browse/hierarchy. 

Is this happening to all descriptions or just some? Were the descriptions in question created in the UI, or via import such as a CSV? If via UI, were they created first in the German interface, or the French one? If imported, what was the culture column value used?

Does your site include any custom code (including a custom theme)? Anything else that might help us narrow down the issue?

Thanks,

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/26cf30b5-859d-4803-8251-6d5447f469bfn%40googlegroups.com.

[r.ruti...@docuteam.ch]

Hi Dan,

These URLs that I mentioned are those that are being loaded in the background for the treeview box, when I view a description (i have set to "full width" in the treeview settings). I don't know how I found out, either by using Chrome's developer tools or by looking into the treeview.js file.

Anyway - the complete treeview at /browse/hierarchy does work for all cultures except french, too. I only see the loading icon.

index.php/browse/hierarchy?sf_culture=fr   NOT OK

index.php/browse/hierarchy   OK

So it seems like it does not work for all the descriptions. 

The descriptions were created by EAD.xml import via GUI. A culture was not set (see my other recent conversation, you probably remember, https://groups.google.com/g/ica-atom-users/c/diZzGdQoj-U) , the default culture "de" was used. I don't think that's a problem in general, as for the same procedure, in italian,  the treeview works.

The site uses a custom theme, for more than a year now, without problems. It's based on the default theme and only has different css stylings.

I can't think of anything different now

[Dan Gillean]

Hi Roger, 

Thanks for the additional information. 

I spoke with one of our developers who had the following suggestions: 

First, based on that internal URL with the nodeLimit=10000 parameter, it's possible that the issue is that an out of memory (OOM) error is occurring silently when trying to load the treeview. Do you have the following setting configured?

• https://www.accesstomemory.org/docs/latest/user-manual/administer/settings/#items-per-page
  

Try setting it to a lower value, and see if it helps. You might want to clear the application cache and restart PHP-FPM first, just in case. I have no idea why this would only affect French, but it's worth seeing what we can find out. 

Additionally, you could try enabling Debug mode to see if the qubit_dev.php front-end can provide any additional debugging information. You may first need to make some config changes to enable this - see: 

• https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/debug/
  

Between that, your webserver error logs, and the browser developer tools, it would be good to check for any related errors. On this, our developer says: 

He should be getting some HTTP response to the request, and it would be good to know if it's a 200 OK, or a 500 Internal server error, or something else. If it's a 200 response, then it's just returning an empty page. If it's a 500 error, something is broken. And if it's a 403 error, it's a permissions thing.

Let me know what you find! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/a9accabc-ec14-4144-9b41-142a851b8ef7n%40googlegroups.com.

[r.ruti...@docuteam.ch]

Hi Dan,

In fact, I have a JS error

The Firefox network analytics (part of developer tools) show all loaded resources with 200 status code, except for 2 image resources from gravatar.com which yield a 403.

The GET request for fullWidthTreeView?nodeLimit=10000&firstLoad=true returns 200, so that should be fine.

It is really the JS error that causes the problem.

Cheers, Roger

[José Raddaoui]

Hi Roger,

Thanks for looking at the JS error. It seems to be happening when that 200 response is being parsed. Maybe a French character is breaking that JSON blob, could you check that response directly? The URL should be ".../browse/hierarchyData?nodeLimit=10000&sf_culture=fr" and you should see a response like this example, with a list of nodes and a total count.

Also, from the error in the browser console, it looks like the response is parsed in line 112 (qa/2.x) instead of line 110 (stable/2.6.x). Hopefully we find the issue by looking at that response, but I wonder if it could be related to that too.

Best,

Radda.

[r.ruti...@docuteam.ch]

Hi Radda,

Thank you. I tried the direct response, but the page is white, no data.

In fact I am using the latest version of the fullWidthTreeView.js. It is line 112 instead of line 110 because I had some js output added in the process of finding the error

111: //         console.log(response);
112:                  var data = JSON.parse(response);

Cheers, Roger

[José Raddaoui]

Hi again Roger,

Hard to tell then without looking at the actual data. I see you're facing the error on the full hierarchy browse page, is it the same on all archival description pages? Maybe by checking some top-level descriptions we can narrow down the issue.

Best,

Radda.

[r.ruti...@docuteam.ch]

Hi Radda

The error appears on every treeview by the culture of "fr", no matter if on full hierarchy browse page, or in an archival description on top level or low level.

I would troubleshoot more If I knew where to start. Maybe you know some other place in the code that i could var_dump() or so?

Cheers, Roger

[José Raddaoui]

Hi Roger,

Hard to know without looking at the actual data then. Most of the PHP code involved in that request is in ...

https://github.com/artefactual/atom/blob/stable/2.6.x/apps/qubit/modules/default/actions/fullTreeViewAction.class.php

For example, you could check the $results variable to see if the records were fetched from the database, or the $data variable to check the final records before JSON conversion, or in between to check the data transformation.

I hope that helps,

Radda.

[r.ruti...@docuteam.ch]

Thank you Radda. I found out why it did not work.

The customer asked met to do some changes, namely to show "(d)" instad of "(Draft)".

So I did the following changes in fullTreeViewAction.class.php on line 209, 

$status_short = " <span style=\"font-size:9px;font-style:italic;\">(".substr($status,0,1)).")</span>";
$result['text'] = "{$result['text']}{$status_short}";
/* $result['text'] = "({$status}) {$result['text']}"; */

In french, "Draft" is "Ébauche", so the first letter "É" was the reason the data could not be computed as it does not output "É" but something weird (encoding problem)
So I hardcoded the letter for all languages

$status_short = " <span style=\"font-size:9px;font-style:italic;\">("."D".")</span>";

Thank you

Roger

[José Raddaoui]

Thanks for reporting back Roger, glad you found the issue!