News:

Wondering if this will always be free?  See why free is better.

Main Menu

"Undefined variable: parse_tags" listed in Error Log

Started by MtnDon, November 26, 2012, 09:59:35 PM

Previous topic - Next topic

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

Quote from: MtnDon on November 28, 2012, 12:51:48 AM
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:
// 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:
// 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

Quote from: MrPhil on November 28, 2012, 09:48:13 PM
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  8)

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.

Shambles

Tt ships its own copies of the following, which seem to get loaded during a tapatalk connection via their servers (which is how Tt works)



Begs a big question...

MrPhil

Um, what happens if you've already modded one of those files, or want to install a mod after Tt? I'm assuming it's a one-time download (replace), and not at every connection -- that would be horrendous just in terms of bandwidth used, not to mention loss of mods.

Shambles

Those files are held under a Mobiquo folder in the forum root so they seem to stay private to the Tt connection. Dunno how it all fits together but if any SMF mods are applied which affect the real equivalents, they don't show up when using Tt on your mobile device.

MtnDon

Interesting stuff.

I'm going to propose here at our forum, that we remove various mods, one at a time beginning with either Tapatalk or Simple Portal. Then let things run and see what happens. Then also look at the subs.php to see if it has changed.

There are a few mods we've used that are "pretty" and some that are useful, but we got along fine before we used them. Simple Portal was selected for a couple reasons, none of which are really needed. Maybe that will be second to be uninstalled in my proposal to the head man / owner.

If I wanted to get all the SMF files back to their purest form what would be the simplest method, understanding that nobody on our site is a technical wizard?

Also is there an easy way to view the files like subs.php, with line numbers included. Do we/I need some extra software? I seem to recall some way I used a few years ago but it's all very foggy now in my 66 yr old brain.

Thanks again for the support.

Shambles

To be quite honest, I'd follow the consensus on this and simply add the missing parameter to the parseBBC function.

If you need help doing this, let us know and we can attach a new copy of your Subs.php file for you to try.

To answer your final request above, download a copy of Notepad++ and use that as your viewer/editor.

MtnDon

Shambles™ , thank you for the offer to help on the subs.php file. Also thanks for the referral to Notepad++. I downloaded it and it looks very useful.

Would you, as you can, attach an adjusted copy of subs.php. I can them compare, follow and understand the changes.  And we'll replace the existing file the new adjusted file and see what happens (keeping a backup copy of course).




Shambles

Sure thing.

Notepad++ has a "compare" function (Plugins > Compare > Compare) which you can use to see the small addition I made.

MtnDon

#27
Wow!  I downloaded that file, saved the one in use and then placed the newly adjusted file on the server. Next I emptied the error log. Been watching it stay empty for several minutes. Ya'll did it!!  Thanks to Shambles™ for the copy and MrPhil for the idea!!!  And    Labradoodle-360 too!!!  Thanks to all; we're golden!!!


Skaty

i have 111000 pages full of this error  8: Undefined variable: parse_tags

what was the solution :/

Arantor

What file is that error in, exactly? Also, what version of SMF?

Don't use the file linked above, it's unlikely to solve the problem.

Skaty

8: Undefined variable: parse_tagsDosya: --> Subs.php

and a lot of from this

8: Undefined index: list_additional_groupsDosya: --> Load.php


smf 2.0.3

Arantor

Do you have the line numbers where these have occurred? Those files are enormous, containing literally thousands of lines of code each.

Skaty

sorry, yes there is numbers: for load.php is 1474 and for subs.php is 1703.

i have tapatalk and simpleportal both.

Arantor

The Load.php error is related to a mod you've installed, possibly not completely, for displaying multiple badges - but since I don't know the mod in question (and can only see traces of it here), I can't tell you right now how to fix it. You may be better off removing it.




The Subs.php error is much easier to fix. For some reason your Subs.php file looks like how SMF 1.1.x had it.

Find this line:
function parse_bbc($message, $smileys = true, $cache_id = '')

and replace with how it has been in SMF 2.0 for years:

function parse_bbc($message, $smileys = true, $cache_id = '', $parse_tags = array())

That will fix the parse_tags errors.

Skaty

Thank you, i did it. i will look at the load.php later.

how about this error, can you help me with these ?

this is database error log for similar post mod the error is just this    );    in line  67  sould i just delete it ?

and

messageindex line 69




Arantor

Quotethis is database error log for similar post mod the error is just this    );    in line  67  sould i just delete it ?

Definitely not!

You should refer it to the mod's author - each mod has a dedicated support thread, which you can find from the mod's page under 'Support and comments for this mod'

I can't see anything obviously wrong with MessageIndex line 69, what error do you get?

Skaty

i sad that because the log is under database section.


messageindex is says 8: Undefined offset: 5-6-7-8-9 ...

i didn't look forum's these area (error logs) a while, and i saw now (omg face) there is so much and various errors. is this errors serious problems or just like some notify.

Arantor

The error in the similar topics one is a database error. The line you reference is the last line of a multi-line command to the database that's failing. Talk to the mod author, only he can really help you out.

As far as the message index error, that's the result of some badly (very badly) written mod that isn't doing its job properly. Talk to whoever wrote it.

Skaty


Arantor

:) Glad that I've been able to make some improvements.

Skaty

Hi again. i learn a little more after this thread.

i have this error:

8: Undefined offset: .... languages/Post.turkish-utf8.php (main sub template - eval?)
Line: 197

i know in this language file is missing something, so i copy the same codes from post.english and add them to this file but still giving me this error. can you look at this one.

_____

and what do i have to do when the line is isn't there. for example in this error for this file. there is no line 376 ?

Dosya: .....languages/SearchFocus.turkish-utf8.php (main sub template - eval?)
Satır: 376

MrPhil

First of all, go into Admin and "turn off template evaluation". That will get rid of the "eval?" and make sure you have the correct file name and line number listed in the error message.

Skaty

Quote from: MrPhil on January 15, 2013, 08:48:29 AM
First of all, go into Admin and "turn off template evaluation". That will get rid of the "eval?" and make sure you have the correct file name and line number listed in the error message.

Fixed, thank you :)


Advertisement: