So, I have a view that displays values from [expression] and [views_conditional] tokens. The problem is that BackdropCMS displays the values of those tokens while viewing in Views UI as an Administrator; however, the view does not display the token values when viewing the page (also as an administrator). Screen shots attached, show the rendered page without values (in columns where the zero's are) and one with the values from within the Views UI.
Info:
Backdrop CMS 1.20.2
MySQL, MariaDB, or equivalent version 5.7.33-0ubuntu0.16.04.1
Version: 7.0.33-0ubuntu0.16.04.16 (PHP information)
Apache/2.4.18 (Ubuntu)
I'm out of ideas, so any help would be appreciated!
Comments
abqgman, it may be helpful to see a screenshot of the Views UI (not the preview, but the actual settings area) and also an export of the view?
Sorry it's a long one . . . export to follow
I had to create a link to a public share on my server for the views export code as the code is over 25K lines in length and is much to big post here:
Views Export
Please let me know if you have any problem accessing the link. The file is saved in .txt format.
Wow, that's a huge and complex view. It's hard for me to know what's going on given the sheer size of the export. From what I'm seeing in the export you are using several modules: Views Field View, Views Aggregator Plus and Views Conditional Field all combined. Is this right? In the settings snapshot, are the "Exposes XX Display" Views Field View (VFV) fields referring to a different view? What I'm thinking is that perhaps, for some reason, the admin preview is running these computations in correct order (first running the aggregated referred view and making the Views Field View replacement, then performing the conditional that looks at that VFV field). BUT when opening the URL of the view, this order is incorrect, meaning that the conditional is performed before the Views Field View field has a value, resulting in that empty display. This is just a wild guess.
First try clearing all caches and visiting the URL again.
Then...
I'm not sure the type of testing you have done so far. If it was me, I would create a separate, new test view that only contains the absolute minimum number of Displays and test one individual field conditional at a time. And test both the admin preview and the actual view.
Feel free to post your findings, and I can try to help further
Hi argiepiano - and thanks for helping out.
Yeah, we do some pretty crazy things with BD (and Drupal 7 prior) and specifically Views & Webform. I bet my team that your first response would be something like "Woah!" - I guess I win!
I believe your theory may be correct as to the "order of operations", I never considered that Views Preview might process a complex view in a different order than page rendering, which likely would result in miscalculations. That makes perfect sense and seems like the simpliest answer.
I've been doing some testing and what I've found is that by exposing some of the hidden fields in the process and monitoring both rendered view and Views admin, my results seem to mirror exactly what you've theorized.
Specifically the Views Fields: when the Views fields bring the resultant value over, it displays correctly as a number (integer); however, the Views Conditional field which performs the next step (in Views admin), does not see the result as a value in page rendering and instead sees it null - could it be the order of operations, or could that module be converting the value to a string and PHP for some reason is not picking up on that?
I am going to play around with the order of fields in the View to the extent that I am able, to see if I can get differing rendering results in the page. At least that may give evidence as to root cause. I will post my results here.
Again - thanks for your help and yes, despite the complexity of the View, you have correctly picked-up on what we are doing with it.
Ok - I have had time to do a little more testing:
I added a test global text field under the Views field (the target) and before the conditional fields that reference the target.
If I enter the [view] token in the test global text field and change references from the conditonal fields to the test global text field, the rendered result is as orignally reported - null or zero.
The Views field however, will still display the proper value.
If I then change the test global text field from a [view] token to a static numeric value (12), then the rendered page displays conditionals correctly and subsequent calculations also display correctly. I can repeat this behavior simply by removing the static value and replacing with a token in the test field I created.
This tells me - as orginally suggested - that the order of rendering operations is different (and therfore, incorrect) between BD's rendering of the page via the URL and Views Admin preview.
Hopefully this helps, but let me know if you need clarification. I sense this may be ta 'core' problem rather than a Views or Modules issue.
Hi @abqgman. One more thought - a bit of spitballing here.
Sometimes people do processing inside template files (though they shouldn't). Views uses different template files depending on the theme of the page being displayed (Seven for admin stuff, and the front end theme for others). So, go to your view and click on Theme: Information. Compare the template files that are used in your front end to those in the admin theme (Seven). If they are different, look for those template files in your theme folders and compare their content.
The above may be farfetched.
So, I would suggest that you create an issue in the issue queue for both Backdrop, and the two or three modules you use. But before doing that, do your best to create a series of steps to reproduce the problem outside your existing view (for example, start a simple view from scratch, adding fields one at a time until you find the issue). Take detailed notes, and share those in the issue, as well as a description of what modules you are using for the view. People are more likely to look into problems when they can reproduce them in their own installation. Since this is such an esoteric use of views and the maintainers don't have access to your site admin, it's the only way in which they'll be able to help.
One last note: views tokens are handled internally by views and are different from other "regular" text replacement tokens provided in core, so most likely the issue is with views (which is part of core in Backdrop), or in one of the helper modules.
Thank you again argiepiano, your help and insight is appreciated. I did check the templates and they are the same, so I created a step-by-step how-to and posted a bug report at BD Git as suggested.
Views Admin rendering a different result than rendered page when using contrib modules · Issue #5388 · backdrop/backdrop-issues (github.com)
That's great abqgman. I hope someone will pick it up and take a look. I will try to follow your steps tonight to check it, also. I'll let you know.
abqgman: one more question. If you change the path of the view by adding admin at the beginning, thus forcing it to display using SEven instead of your front end theme, does that make a difference?
Cool trick - I never thought of doing that, but I did try changing the active theme to Seven and it did not make a difference.
I did try this, and no change.
Okay - after a few days I have a workaround for this issue. All the dirty details are at the original BD Git and Views Conditional Fields contrib module:
Views Admin rendering a different result than rendered page when using contrib modules · Issue #5388 · backdrop/backdrop-issues (github.com)
Glad you found a workaround! Sorry I could not continue investigating today - busy day. Thanks for posting the explanation in the issue queue. In sure they'll be helpful to others
Thank you for all your help and insight - learned some cool tips! Just having someone to bounce ideas off of helps more than you know.