4

I'm running Drupal 7 on Ubuntu 14.04 server, core and all modules up to date as of today (7th May). We have noticed today that zeros (0) are not displaying correctly in blocks that have a custom token. They are being substituted for the word 'custom'.

For example, "7,500" displays as "7,5customcustom".

I'm not sure how long it has been doing this, as we have only just noticed it today. In blocks without Custom Tokens, the zeros display correctly. This is a relatively recent issue, as it was not a problem a couple of months ago when our site was reviewed by our solicitors.

The source for the content is correct - so it appears to be a display issue. Any ideas?

As an aside, the zeros being replaced need not be in the Custom Token to be replaced (it happens whether they are part of the Custom Token, and when they are just plain text on the page).

Improve this question
4
  • Wondering if this could be a Regex issue, perhaps due to an update in PHP? Or another component on which Drupal relies, as it not just limited to blocks with Custom Tokens....it also happens in emails submitted from a webform, with different substitutions (0 becomes "submission" and 1 becomes "date")? Am running on PHP 5.5.9-1ubuntu4.9, MySQL 5.5.43-0ubuntu0.14.04.1, and Apache/2.4.7 (Ubuntu)
    – strin
    Commented May 7, 2015 at 16:37
  • I am having the same problem with Webforms, also for me any 1's in a pages title are getting changed to 'node' if I auto-generate an alias.
    – diego
    Commented May 8, 2015 at 15:08
  • I have managed to get around the issue by removing any reference to Custom Tokens - this seems to stop any erroneous text substitutions. Interestingly, we are using the Revisions module, and when one of the Moderators went to approve the revision, we had the same problem with a '0' in the node URL being substituted for 'custom' - by manually changing the URL we were able to approve the revision. Even more confused now...!
    – strin
    Commented May 8, 2015 at 15:28
  • 1
    Still no further forward - have raised on the Drupal site also as a bug report in the Custom Tokens project.
    – strin
    Commented May 11, 2015 at 12:13

1 Answer 1

Reset to default
2
+50

It appears to me that the explanation for your issue might be because of any of the following reasons

Reason 1:

It could be related to what is described in https://www.drupal.org/node/390482, which states:

The tokens available depends on what modules you have enabled on your Drupal site.

So could it be that you (accidently) disabled a module recently, which was actually the module related to the token that you now have an issue with?

Also, some more related considerations, based on what I read at comment #3 in the issue queue on D.O:

  • What does that "00" in the "7,500" actually refer to? I want to better understand which module(s) are related to it.

  • What result do you get if you (temporary) enable all of your currently disabled modules? FYI: if you only enabled the module that is causing this issue, and not uninstalled it, the problem might be resolved, at least for now. And then you can think of how to best resolved it permanently.

Reason 2:

When you define a custom token, for "Text format" (under the "Content" box): verify what the text format is you use there. And also verify what the text format is of where you are trying to USE that custom token (as in the original question: in the block), or in your Webform, Email etc.

Because maybe something is wrong in the way you're using/mixing text formats. Refer to How to use the Custom Tokens module, especially to this part of it (bold markup added here):

note that "Custom Token" sends what you put in the "Content" box to the page. It doesn't evaluate it first and then send it. Therefore, if your custom tokens include other tokens and/or PHP code, then the "Body" box in which you place your tokens must use the same text format that you used to define them, so that the other tokens and/or PHP get evaluated.

The question here might be a minor variation of the scenario described in that community page ...

Other reasons worth verifying:

  • Maybe the field "type" got changed somehow, and that is what's causing it?

  • Something similar within the content type settings?

  • Could it be related to something about some missing "permissions" (for those cases where there is this issue)?

Curious to hear if either of these 2 reasons are actually also a solution for what this question is about.

Improve this answer
14
  • I don't think it is an issue with fields or content types (though I'm not 100% sure) since it is saving the info to the DB correctly. If I create a view of the information submitted, or get it through the Results section of the Webform tab it works just fine. It only seems to be if I access the info through tokens, like sending the automated email when a user submits the form that it replaces certain numbers with parts of tokens (in addition to replacing the tokens correctly other than that extra substitution)
    – diego
    Commented May 14, 2015 at 14:24
  • extra question / attempt: when you define a custom token, for "Text format" (under the "Content" box): what is the text format you use there? Related: what is the text format of where you are trying to USE that custom token (as in the original question: in the block), or in your Webform, Email etc? I think I'm getting close to the real issue now. After you answer, I might have the solution ready ...
    – Pierre.Vriens
    Commented May 14, 2015 at 15:13
  • I am having this issue without Custom Tokens, I am just using ones defined by Core or modules like Webform. Where I am using the tokens is mostly in the emails Webform sends out where currently the only text in the email is "[submission:values]" and there all "0"s are replaced with "submission". It also happens with URL aliases and page titles, using [node:title] or [current-page:title] it replaces any "1"s in the title with "node". So far those are the only places I've noticed it happen.
    – diego
    Commented May 14, 2015 at 16:51
  • From all the different variations of this problem, I cannot remember I've seen any scenario different from "0" or "1". so I start to wonder if there is any relationship with something "boolean". Do you have any other cases where there is no 0 and no 1 involved?
    – Pierre.Vriens
    Commented May 21, 2015 at 12:14
  • I haven't noticed any times that it hasn't been a '0' or a '1'
    – diego
    Commented May 21, 2015 at 12:15

Not the answer you're looking for? Browse other questions tagged or ask your own question.