"Undefined variable: parse_tags" listed in Error Log

[MtnDon]

I don't monitor the error logs on a regular schedule. A few days ago I noticed thousands of pages of basically the same recurring error. There's a screen shot below, plus a shot of the sub.php line all the errors refer to. They occur to members and guests. All refer to line 1687 in subs.php They come from all pages it seems.

Any ideas if this is a concern and what to do will be appreciated. I can supply any other info as asked. (may need some guidance on techy details)

[MrPhil]

Should it be a concern? Yes... you should never have an undefined variable, and your error log should never fill up rapidly. It appears your Subs.php file has been substantially modified. I can see a few lines above that a test has been commented out. Line 1687 and down are not vanilla SMF, at least, in 2.0.2. I have never seen a test like that: $parse_tags !== array() and I'm not sure it's legal PHP. Anyone besides yourself do any editing in this forum? What mods do you have installed? Maybe someone will recognize this thing.

If it just suddenly started spewing out errors, without any recent changes, perhaps your host just upgraded to PHP 5.3, and it's stricter about malformed statements? I've seen that kind of thing before. Maybe this odd code used to be legal, or at least, was tolerated by earlier versions of PHP.

[Matthew K.]

Well...an undefined variable simply means a variable is being called that isn't defined. It's not a security risk by any means.

Yeah, any mods installed recently? Quite an easy fix, but it may be better to remove it.

[MtnDon]

The owner of the site recently installed a mod from   Tapatalk.     Maybe that had something to do with this?  I don't know when this started as we have the logs set to auto prune more or less weekly.

Questions...
If the lines in subs.php were changed by a mod, would uninstalling the mod change the lines in subs.php?

If the lines in subs.php were changed by a mod, would the file "subs.php" be listed in the "browse packages" list of files?

Thanks

[Matthew K.]

Theoretically, you could fix the problem by modifying the line. But it's possible then that another error could crop up.

1) Yes.
2) Most likely.

[MtnDon]

Is there a place to view an unmodified 2.0.2  subs.php file?

[Matthew K.]

There should be a file: ./Sources/Subs.php~ in your directory which is a backup.

[MtnDon]

It looks like the  tapatalk  thing may have made the changes.   subs.php was modified on Oct 31 and that was when  tapatalk  was installed by the owner. The installed files lists a file   subs.php as having a whole mess of additional stuff.   Have to have a look into that.

Thanks

[Matthew K.]

Sounds good, let us know if you need any more help. We can leave this topic unsolved for a while

[MtnDon]

After looking at things I'm quite certain that the error generation is caused by changes tapatalk made to the subs.php file. There is a very long list of changes.

Tapatalks response is not at all helpful.... short and terse....

"We will not modify this file, please try to check other possibilities.
Thank you."

I read that as them saying they know there are issues, but they don't care. They just want to sell our app to the smartphone forum users. I'm thinking we should do an uninstall and see what that does. It's not just for me to decide, but that's my vote.

Thanks.

[Matthew K.]

Not a problem, I'm sure someone around here would be willing to help you guys uninstall it properly?

[Shambles]

After looking at things I'm quite certain that the error generation is caused by changes tapatalk made to the subs.php file. There is a very long list of changes

It doesn't touch Subs.php - it has its own included copy

[MtnDon]

Ah!  So tapatalk totally replaces the subs.php. That why the file I saw was so big. I did not know that. Thank you.


Other than the fact that the error log grows so quickly is there any other downside to what is happening. I know enough to get myself into trouble if I'm not cautious.   To me it seems that the creating of a error log for every page view places a slight extra load on the server. It is also probably not good from my view because the huge amount of errpr entries makes it darn near impossible to see if there are any other things going on that are making error reports. Plus it just seems "wrong" and wrong things irk me personally.

So any other concerns about this? If it was just me I'd pull the plug on tapatalk. But there are others involved in the decision and forum operation.

Thanks again.

[Shambles]

I'm not promising anything, but it might be useful to dump a copy of your Subs.php here as an attachment, so someone can have a ganders at it. I'd be looking at the parse_BBC() function declaration, though this smells of faulty parameter passing from elsewhere...

[MtnDon]

FWIW, the subs.php  file that is being used is attached.

Any answers to my previous post questions as to what the excess error log activity will be to the system, host server?

Thanks again.

[MrPhil]

Vanilla Subs.php:

Code Select Expand

// Parse bulletin board code in a string, as well as smileys optionally.
function parse_bbc($message, $smileys = true, $cache_id = '', $parse_tags = array())
{
Your Subs.php:

Code Select Expand

// Parse bulletin board code in a string, as well as smileys optionally.
function parse_bbc($message, $smileys = true, $cache_id = '')
{
You can see that parse_bbc() can be called with an optional fourth parameter $parse_tags, with a default value of an empty array. Unless tapatalk has changed all calls to parse_bbc(), what happens when your version is called with a fourth argument?

Every use of $parse_tags before line 1687 has been commented out, as though the intent is to not use $parse_tags in the routine. However, from 1687 on, there is new code (using $parse_tags) as well as a couple more existing uses of $parse_tags. Did you install any mods that added code to the (changed) Subs.php? If not, tapatalk really screwed up in their code changes -- eliminating the passing in of $parse_tags, but failing to remove all uses in the code. Did you modify this Subs.php in any way, or is it pure tapatalk? I'm still not sure line 1687 would be valid PHP code, even if $parse_tags was defined. I would have written it to check if $parse_tags is not empty (and exists), and then maybe check the length. The existing code simply depends on $parse_tags existing, and being an array. I suppose, if tapatalk has changed all calls to parse_bbc() not to have the fourth parameter, that you could simply restore the fourth parameter to the function line. At least, $parse_tags would then exist everywhere it's used, and would be harmless.

BTW, how does tapatalk legally ship a heavily modified version of SMF code? Are they complying with SMF's license?

[MtnDon]

Tapatalk was the last mod done (Oct 31 this year)

There are some other mods that have been in place for over a year, up to two years. I checked their listings in the SMF mods list where I got them from and viewed the manual install info to check what was supposed to be changed. Some did have chsanges to the subs.php  file.

Am I correct in believing that lines that begin with   //  are those that are "commented out"?


From what I see I don't understand the statement that was made above with reference to tapatalk,   "It doesn't touch Subs.php - it has its own included copy"  as I see that the current and newest  subs.php file includes the changes that other mods previously had made. So it's like a new copy came along but was "melded" with the previous copy. 

Which raises the question... If a mod in uninstalled using the package manager uninstall, does the system properly look after removing or reverting the changed or new lines?  It would seem that must be the case at least in theory.



Anyhow the mods that have been in place for quite a time are...
Simple Portal ...  this mod did some changes such as add the  ??  to this
"// if (empty($parse_tags) || in_array($code['tag'], $parse_tags))"

Simple Audio Video Embedder ...  added a few lines with specific reference to itself. no parse reference at all

6 Custom buttons ...   added a few lines with specific reference to itself. no parse reference at all

Embed BBCode ...  added many lines with specific reference to itself. no parse reference at all

Google Analytics Code
Ad Managment
Google Member Map
.... I did not check these, they've been there since we upgraded from  ver 1 to ver 2.0 gold and everything ran fine with them...


So with the exception of Simple Prtal none of the mods made any changes with any parse_tags   code. And after Simple Portal was installed  more than a year ago our forum ran like it always did. About the only errors being reported were mistaken passwords, spammers, ... that sort of thing.    Too bad I never checked the error logs right after tapatalk was installed. I'd likely have seen the error reports go wild right then.


My thoughts on the question "BTW, how does tapatalk legally ship a heavily modified version of SMF code? Are they complying with SMF's license?"  is that they are in Hong Kong and simply don't give a damn. And they have a development office in Shanghai, CN. 


There is a copy of the  subs.php   labeled   subs.php~  on the server, so I guess if we remove tapatalk the uninstall should be sucessful.   I haven't heard from the site owner if we will do that.  he wants to know what pitfalls we may run into if the tapatalk install is left in place. I know some members of the forum use and like the mod. But that doesn't bother me a lot.

Thanks again. You've been very understanding and educating.

[Shambles]

The SimplePortal 2.3.4 installation has commented out the validation of the $parse_tags array (as noted above by Phil), substituting it's own "controversial" version.

You can see that in the install2.xml file in SP 2.3.4 (and SP 2.3.5).

What I cannot find, after a couple of hours looking, is what removed the $parse_tags parameter definer from the parse_bbc() function.

It's certainly nothing to do with Tapatalk, I can assure you of that.

My next stab at this would be to return the $parse_tags array to the function parameter definition, and take it from there.

[Shambles]

BTW, how does tapatalk legally ship a heavily modified version of SMF code? Are they complying with SMF's license?

When I get time I'll pose that question to them 

[MrPhil]

So SimplePortal is the one that messed it up? My apologies to TT, in that case. I would certainly try adding the optional $parse_tags parameter back into the function definition. It shouldn't hurt, even if no calls use it. At least it will define $parse_tags (as an empty array), which should get rid of the immediate error.

Regarding TT shipping a modified version of an SMF routine, is it confirmed that they are actually doing that (rather than using the package mod installation update)? I'm hearing two different stories now.