[Resolved] Displaying simple text from Types no longer working

[Author]

Posts

[jeffS-2]

I am trying to:
Display code from 5 years ago working fine. Simply pull Treasurer's contact info from CPT using Types shortcode and display.

Link to a page where the issue can be seen:
(Requires member login)

I expected to see:
℅ John Smith
1234 First St.
San Jose, CA 95051

Ph: (650) 123-4567

Instead, I got:
℅

Ph:

My code, which has been untouched for at least 4 years, is as follows:

<div class="contactTreasurerInfo">
  <span style="font-size:16px;">
     Treasurer IEEE-CNSV <br />
     ℅ [types field="treasurer-first-name"][/types] [types field="treasurer-last-name"][/types]<br />
     [types field="treasurer-street-address"][/types]<br />
     [types field="treasurer-city"][/types], [types field="treasurer-state"][/types] [types field="treasurer-zipcode"][/types]</span><br /><br /><span style="font-size:16px;">[types field="treasurer-email"][/types]<br />
     Ph: [types field="treasurer-phone"][/types]
  </span><br /></div>
</div><!-- contactTreasurerInfo -->

[jeffS-2]

Sorry, I forgot to mention that the same code using Types shortcode on a different page displays correctly! I am confused with this.

The correct page does not require member login and is at: hidden link

Sorry, I had some problems with Duplicator, so maybe we can solve without cloning the site.
Jeff

[Beda]

Please submit us Access details when you require us to log in. When you open a ticket with us, you can choose a private/secure form to fill out the required data.

I have now reactivated that form, as it seems I will need to log in to see this issue and try to solve it.

If the precise same code works on page A but not B, then the first I'd try to do is narrow down how many pages are affected.
If it's just one, delete it after copying its contents and recreate it. If it's solved, we can assume it was corrupt, if not, then I'd go on removing parts of page one by one to see if maybe some HTML is broken or some specific character provokes the issue.

It is also very possible that it is a certain value in the fields displayed here, so it will depend on what value is added to the Custom Fields of that specific Page.

Narrowing this down will indicate how the issue can be replicated (or if not, it'll show it was just a corruption).
Once we know steps to replicate we can start the path of solving it.

Please let me know what you find, and as mentioned I activated the private reply form.

[jeffS-2]

THE PRIVATE REPLY IS NOT ENABLED!

[Beda]

The private reply was enabled, but it is valid only for one reply and can also be deactivated, if not needed.
I re-activated it.

Thanks

[Beda]

I see the address on one of the pages that is "not working":
hidden link
It says:

℅ Joel Kent
PO Box 7261
Fremont, CA 94537

The only PH I see on that page is the Ph: 650.521.7889
But that is also not empty.

However, I see it broken on hidden link:

Treasurer IEEE-CNSV 
℅  

,  


Ph: 

That page doesn't use a Content Template, it just incorporates the View in the Post Body:
hidden link
In that View, a CT is loaded as Loop Item: hidden link
That CT has a lot of content, inclusive Conditionals.
The Custom Fields to display the data are at its bottom.

However, this View displays one Item of Treasurer Contact Infos.
It will always display one Item only, and if there is no filter to determine what Post exactly to display, it will just display the first it finds by its vanilla query.
With the current setup, you get a One Post to display always the same post - for this you don't need a View, you can simply display this data in a Content Template and insert that in a Page.
Views would be used if you need several posts and eventually queried by some relation or similar.

However, there is also no technical reason as of why it should not display the data on some pages where you use this View and others not, even if it's not the ideal way to display this data.
It could be that the issue is related to this:
https://toolset.com/faq/why-do-types-shortcodes-have-to-be-closed/

I see in the CT that there are several non-closed ShortCodes, and when I very shortly testing only the Types ShortCodes, they worked.
So this means the issue is within any other content in the template than the closing Types ShortCodes
Eventually, this is due to the custom ShortCodes before the Types ones, can you try by removing those and test again?

If I can do those tests let me know, as of now I only tested very shortly (a few seconds) to see if the Types ShortCodes worked, but did not make any longer test.

[jeffS-2]

Hi Beda -

First, thanks for taking the time and giving me so much info.

These pages were originally written almost 5 years ago. At the time, I was not so savvy in understanding how exactly types/views works, and started by using examples from very limited documentation. So, that is why I have the Membership Renewal page using a View even though I only want to return one record for the treasurer info. I did not know any better at the time. And this website has grown immensely over the years and I rarely look at these old pages. That's why I don't understand why it stopped working suddenly, because I have not changed any code on these pages or views. So, I thought it is something that changed in WP or in Toolset. I can easily take the view out of the picture and just use the CT directly in the page.

Anyway, I do not understand exactly what you mean by shortcodes must all be closed. What about the views shortcodes (for example: [wpv-user...]) ?

In the CT, appearing before the [types][/types] shortcodes near the bottom, there are 3 sets of shortcodes: First there is a [wpv-conditional...] which inside contains a [wpv-user info=...] shortcode. So, do you mean that may cause a problem since the [wpv-user...] does not have a close shortcode like [/wpv-user] ?

There is also a second [wpv-conditional...] also testing with a [wpv-user...] shortcode inside. Does that cause a problem?

Third one, there is a [wp_paypal...] shortcode that is not closed.

I don't know what to do with those.
If I remove all 3 of those, the types fields display correctly.

Thanks if you can please explain more detail for closing shortcodes.

In the meantime, I will remove the use of the View and use the CT directly.
Jeff
-----------

[Beda]

==> If I remove all 3 of those, the types fields display correctly.
We need to narrow down which it is.

One by one, what does removing the ShortCodes produce?

I found it's the HTML condition only, actually. When you remove the [wpv-conditional if = "[wpv-current-user info='logged_in'] = true"] and the [/wpv-conditional], then it works.

So that means, something in that ShortCode is wrong.
One thing is - its syntax is corrupt.
It should be:

[wpv-conditional if="( '[wpv-current-user info='logged_in']' eq 'true' )"]

Note the difference in the apostrophes and parenthesis.
However it seems changing it to the correct syntax does not solve the issue, only removing the condition solves the problem

I have am not sure If I can do more tests, please mention whether I am allowed to work on that View (inclusive delete and move content) or not, otherwise I think I'll need a local copy (https://toolset.com/faq/provide-supporters-copy-site/)

I also notice the other views displaying that address ([wpv-view name="Join CNSV"]) do work because they seem to have no such condition in the loop.
Locally, such condition works just fine in the same scenario.

I think the best is I can have a copy of the site to deploy locally or I can try narrow it down online but will need to know if I can do major changes to those contents

[Beda]

BTW related to closing and not closing ShortCodes, this is related to Types ShortCodes in Toolset but also any other ShortCode - as follows below:

1. In Toolset Content Templates you cannot save TYPES ShortCodes if they are not closing. This happens only when you insert TYPES shortcodes without closing tag (views or forms shortcodes are not affected by this because none of them is closing with tag)
2. The principle in general is, when there are both single-ended and closed shortcodes, of the same kind on a page - so when for example 2 "types" shortcodes (one open, the other closed) where on the same page, then things will break. Or, there are 2 shortcodes "imaginary_shortcode_handle" and one isn't closing while the other one is, then issues happen.

This should hence not be an issue on your site.

[jeffS-2]

Beda -

Please stop debugging this issue. I believe we have both spent too much time on this. I will hard-code the treasurer's contact info, and revisit this issue at a later time. I am too busy with other things right now, and I'm sure you have better things to do as well.

Btw, I tried changing the apostrophies around and adding similar to what you did above, but I couldn't get it to work correctly. But, thanks for clarifying the correct way to format it. Now I know for the future.

Thanks for your efforts. When I return to debugging, I will use your info to continue the hunt.
We can close this ticket.

Cheers,
Jeff

[Beda]

Ultimately, this is your decision, however, given that just removing the HTML condition solves the issue, I'd like to confirm it's not something broken in Toolset.
As mentioned even with the right syntax I could also not see it working on your site, so it must be a deeper nested issue.

Could I try to grab a copy of this site for local analyses?
Or, you can simply provide me with a copy using this information https://toolset.com/faq/provide-supporters-copy-site/
If I take it myself I'll have to install some duplication plugin.

Please let me know - I added private replies.

[jeffS-2]

Hi Beda -

So, I did some digging and found that, if I shorten the paragraph beginning with, "Another benefit is our listserver..." then the types fields appear. I messed around with that for an hour and I have no clue what is going on at this point. I have now modified my staging code quite a bit so it no longer matches your exactly, but it appears to be related to the length of that paragraph - or maybe the length of something else.

Jeff
------------

[Beda]

Your last update points towards an issue with memory or execution limits on the server.
Usually that happens only when many conditionals are present, however here something maybe eats up all resources and the conditional simply is the last in line to fail.

Related to removing the conditionals, that is what I meant, the second one is causing. Hence why I want to analyse this more in depth.

I'm now downloading the duplicate and will see what this is caused by.
I will then update you with the findings.

[Beda]

On this Duplicate I see an error on the login screen:

Deprecated: define(): Declaration of case-insensitive constants is deprecated in .../plugins/wp-rss-keyword-filtering/wp-rss-keyword-filtering.php on line 34

That's not due to Toolset, but I thought to inform you about it.
It should be due to the Plugin "wp-rss-keyword-filtering".

The other thing is, as soon I installed the Duplicate, the page in question which is broken on your live site was working fine.
The conditional on your site - as you confirm - fails upon a certain length of contained characters within the condition's output.
I observed locally that on the exact same PHP version as you have (7.2.x), I can also not see the Types Fields outputs!
While on PHP versions (5.4) that page in question breaks completely due to other Plugins installed on the site, on PHP Versions 7.3.x it all works just great.
On PHP 5.4 the error BTW is related to wp-google-fonts Plugin:

Strict Standards: Redefining already defined constructor for class googlefonts in .../plugins/wp-google-fonts/google-fonts.php on line 140

On the breaking PHP Versions 7.2.x I see it stops working around 2706 characters in the condition.
On a fresh install however using the 7.2 PHP I cannot see this issue yet.

To solve this, on one end, clearly you should not use the View for a single display of a hardcoded address, so solving that, you will also get rid of the issue.
You can simply insert the Content Template in the page ([wpv-post-body view_template="Membership Renewal"] ), which will display this hardcoded information.
Even better, you could create a Content Template that applies to all posts where you want this address, and hardcode it in that Content Template.

On the other end, I will dig deeper into this Duplicate, for some reason it breaks on this specific PHP version, and I will let you know why and what we can do about it.

I apologise that, since this happens only with the PHP version as you use it but not the latest and maybe only with specific settings, I wasn't able to initially catch this issue.

For now, and in the future, I would not use the Views for single displays - but that doesn't remove the issue from my plate for now 🙂

----------------------------------------------------------------------------------------------------------------------------------------------------

When looking deeper I saw that this seems really due to the sheer amount of characters, as one can replicate it with thousands of "Latin letters" in the Content Template, however, it needs more characters than if you use HTML.
But still, this only happens on the Duplicate.

I also tried thereby disabling other software and changing the theme, which both did not solve the issue.
Strangely no error whatsoever is thrown, but the debug for Conditions also doesn't work, which means at some point there is a technical error.

I'll update you when I know the precise source.

[jeffS-2]

Beta -

I guess you really enjoy deep debugging as I do also.
Thanks for all the digging!

1. Interesting about the PHP error. I did not see that appear on my screen, and I always have WP_DEBUG enabled in staging. I will check on that.
1a. The keyword-filtering plugin cannot be updated in staging because I have only a single site license for the live site.

2. I can likely upgrade to PHP 7.3.x, but I have to check my theme first, since it is a five-years-old views_base theme from Toolset, and has not been updated in a few years and no longer supported. Unfortunately, I have way too much custom code invested to even think of changing to a new theme.

3. I will soon be removing the Google Fonts plugin and simply load them manually, since I am using only 3 fonts on the site. I have occasionally run into other errors with this plugin and it takes to long for a fix.

4. Regarding the use of a CT shortcode directly from the Page, I understand the reason and makes sense. However, I seem to have a problem with that. When I try to do that, the shortcode itself displays on-screen as text instead of the data. My client changes their treasurer every year, so that's why I created a CPT for it, which allows their admin to make the change easily from the backend. But, I don't know why the shortcode is not being deciphered by WordPress/Views.

I hope you have a good weekend and take a break from code!
Jeff
-----------