Upgraded to 4.2.2 problem with stylevar
 

Hey, i upgraded my board to 4.2.2 but i am not able to edit variables in style var.

Also i get this error.

Warning: Declaration of vB_DataManager_StyleVarDefn::delete() should be compatible with that of vB_DataManager::delete() in ..../includes/class_dm_stylevar.php on line 233

Warning: Declaration of vB_DataManager_StyleVar::save() should be compatible with that of vB_DataManager::save() in ..../includes/functions_log_error.php on line 615

Fatal error: Call to undefined method vB_DataManager_StyleVarSize::() in
/includes/class_dm.php on line 495

Read this ;

http://www.vbulletin.com/forum/forum...66#post4000466

The first two are warnings that flash up, but wont do any harm. Please log them in Jira though.

The fatal error is a mystery.
I cannot replicate that, and that class does exist - it is defined in class_dm_stylevar.php

Hi there,

I have the same 2 warning and realized my download (exported) style even default style the <stylevar> </stylevar> is completely empty.

am i the only facing this?

Yes I have to exact same issue, did you find a fix?

Add define('SKIP_ALL_ERRORS', true); to your config.php file

I got the same problem, so If I skip these errors, and after changing my settings will follow?

because on my case even if I change my doc_width and doc_margin to my set up these errors will flash and no effect at all on my desired width

https://vborg.vbsupport.ru/external/2013/12/14.jpg

thanks

This cured my issue as well. Thank you all very much.

Glad you got it sorted. :)

I just upgraded a clients site to vb 4 and we're upgrading the vb3 style with vbulletin's built in upgrade tool. I went to go change out the logo and I get the Declaration errors mentioned a year ago in the OP... The advice is to hide PHP errors?

It seems it would be better for the company to fix the problem, not hide it.. :down:


actually it seems when I edit any stylevar.. well this will be an annoying job.. I'm sure the client will be asking me what the hell is wrong with vb4 when they see them too.. Thanks vBulletin :mad:

Those are not errors, but warnings. They have always been suppressed it was just recently with PHP newer versions, they started showing again.

Regardless of your predictable rant, if you want to fix it, use the advice given.
You should however use SKIP_DS_ERRORS rather than SKIP_ALL_ERRORS, that restores the warning reporting to the same as used by vb2, vb3 and vb4 versions other than 4.2.2.

I have to throw my two cents in here:

I run my own software business and have over 30 years experience developing software. I develop systems for telecoms, railroads and manufacturers and I can tell you that if I started suppressing errors instead of addressing and correcting them I would be out of business tomorrow.

Suppressing errors (hiding, covering up problems) is about the worst thing you can do as a developer. If customers find out you're doing that then they will never trust you again. This type of approach shows a complete lack of desire or ability to fix the underlying problems.

Would you want your plumber or auto mechanic to hide problems from you? Of courses not.

Ask yourself this: When you were first thinking about purchasing vBulletin and you found out that error messages were being suppressed would you still be willing to purchase it?

The answer to that is, no.....

Well then there is not much web based software you would purchase then, as it has been a common practice for ever. If it was so bad, then the blame should fall on the people who created PHP, as they made it so the warnings could be suppressed. :)

Most software development environments have the ability to suppress error messages. They also provide the ability to write completely illogical spaghetti code too but that doesn't mean it's good practice to use either option.

Leave my spaghetti code out of this. :p :)

I do not believe that anyone was promoting masking constructional errors. The discussion (as I interpreted) was about interpretive/compiler warnings. Maybe I just misread. :)

Well it was common knowledge when vBulletin 3 was released. Nobody seemed to mind then.

I totally agree with what you have said this is why I put a link in my sig so any can find the fixes for the problems in 4.2.2

Thanks. Between the constant security issues for each release and things like the suppression of warning/error messages I have to say I'm very disappointing in the quality of this software.

Why is it that no sooner is a new version released then hackers find security holes? Don't the developers test their work? Why don't they see these holes before the release? You would think that after the first few times it happened the folks writing this stuff would get a clue and start doing more rigorous testing.

My clients would NEVER put up with this lack of quality control. My software is used in very large scale environments and the slightest errors can balloon into major problems in no time at all.

It's my understanding that vBulletin is used on over 100K sites which makes me wonder why more effort is not put into QA. Perhaps a rush to release a new (and expense) release to drive sales is the reason.

I've beaten this dead horse enough

Again, you do understand that these error messages have been suppressed since 2004?

I have never been hacked because I make my forum secure its not hard to do

So you're saying that with all the releases in the last 10 years no one bothered to find and address the source of the problem???

Why would you want to address the warnings if they are just depreciated PHP warnings. They are addressed if they become errors AFAIK.

For a long time, no one actually had touched the code that did all of this, and the code base goes back to 2002~ or so when vBulletin 3 development started. Every developer from that time period is gone. We don't have that knowledge laying around anymore.

So, to fix them, in 4.2.2 we DISABLED it, and then found a large chunk of them and actually fixed the code.

A few of them escaped, and went unfixed in the final 4.2.2 release. But we patched it with the skip errors lines if customers were running into it.

We urged them to log bugs where they were occurring.

In 4.2.3 I believe they've all been addressed, and we're working on 5.5 issues now.

Let me get this straight. You're saying that you're selling a large software package containing code that no one on the current staff has any knowledge about?? What????? Are you kidding me??? You're joking right??? You must be!!

I don't think he is, it is a surprise to me that no coder can fix the coding after all any coder should know how to code even if another coder first done the coding

If what he''s saying is true then I am shocked ! How in the world could a company actually sell software containing code that they have no knowledge about? How can you possibly test a new release when it contains code that you have no knowledge about? How do you support it? How do you know how it will interact with the new code for the new release? How do you know that some angry developer didn't plant something nasty in it?

But you are correct in that any good coder can figure out another programmers code. That brings into question the capabilities of the current staff. Why can't they understand the code?

As I said - I am shocked!

I have lost some trust with the devs after finding this out if they went in and fixed all that needs doing I am sure things would run a lot better. But going by what has been said they don't seem to have a clue

When did you *start* trusting them? I stopped trusting the vb development team when most of them left in 2009, and nothing released since has gained it back.

First- no matter what- even when staff accidentally say we have been suppressing errors since 2002, they mean warnings. PHP warnings. We have been suppressing warnings only. Warnings don't stop execution of the code, warnings don't hurt anything. Most are in fact deprecation warnings that just say "Hey, this code still works but one day you will need to change it."

All forums used in production environments should be setup to suppress warnings and errors to begin with for security reasons- that is good practice. Only development environments should be showing warnings and errors.

Our competitors also suppress warnings in their software in normal modes. It is common practice is all PHP software.

4.2.2 was the first time in a long time many of the long-standing issues were addressed. Everyone who is saying "how come you didn't fix it instead of hide it" well 4.2.2 (and 4.2.3 now in beta) are the result of actually fixing the issues rather than hiding them.

I have been running vb3 on my big board since 2005 and have not suppressed error reporting. So stating that errors were hidden since 2002 is complete nonsense.

You can spin it however you like, but warnings are intended so that the developers pick up on it and do something about it. It is not good practice at all to hide warnings.

Deprecated errors are a big sign on the wall that the software you run is getting outdated and should be either fixed or replaced by modern software. Because sooner or later your server software like php version will be EOL and you risk all. PHP 5.3 is already EOL. PHP 5.4 will be.
Just like YUI2 has been EOL since 2009 and YUI is abandoned now. But we see no rewrite going on replacing YUI with jquery. Its just waiting for the hammer to fall.
Hiding the warnings is like fixing the security vulnerability by completely removing the install folder. It sort of works, but it evidently shows that quick hacks are provided instead of quality development.

In the case of vb4 you can wait until it stops working, hope that Internet Brands actually fixes up vb4, releases a quality vb6 or draw your conclusions based upon the current situation.

So you are saying, you went in the core files, and removed the suppressed warning code that was in there?

Note, we are talking warnings, not errors, they are two totally different things. :)

You people have got to be kidding me. What software company would actually tell it's customers that they are actually suppressing error and/or warning messages? Clearly you need to learn how to run a business.

Under no circumstances is it justifiable in my book to suppress these warnings and errors. The whole purpose of a warning message is to alert you that a condition exists that is not correct. Why then would you want to ignore it and not correct the condition that caused the message to be displayed?

Can you provide any reasonable explanation as to why these conditions are not addressed ? As a customer who paid a lot of money for this software package I expect it to work WITHOUT errors and warnings.

If warnings were not suppressed, every time your server had a php update, it would probably throw up a bunch of warnings, due to the new php coding. Then everyone would be crying that there is warnings all over their sites.

Sure the vB code should try and accommodate for all of this, but sometimes it is not feasible.

When I write my mods, I try to make sure everything is correct, but sometimes I even overlook stuff. :)

Mods are not what I am talking about. Mods are free and when you accept free software you accept it as is for FREE with no expectation of bug free software.

When you PURCHASE software then you should be at the very least be told BEFORE THE PURCHASE that warnings and/or errors exist and are being hidden. Not telling a potential buyer that these conditions exist is tantamount to deceptive selling practices.

Also, how do you explain the comments from Zachery a vBulletin Support Staff member that, and I quote:

"For a long time, no one actually had touched the code that did all of this, and the code base goes back to 2002~ or so when vBulletin 3 development started. Every developer from that time period is gone. We don't have that knowledge laying around anymore. "

He is actually saying that they are selling software containing code that they know nothing about. Unbelievable!!! Not only is he saying they are marketing a product they do not fully understand but that they apparently do not have the skills necessary to understand it.

How do you rationalize that?

I don't comment on what he has said, as it is something he said, I will leave it to him to to explain that one. :)

Which is exactly why its great to have error reporting turned on. If I upgrade one of the 110 addons that I run and it causes a warning or error, then its good to have that clearly in sight. Because if I do not encounter the warning then one of my 3.5 million readers will instantly notify me. This allows me to quickly report the bug to the developer and have it fixed.

Getting it fixed is what the error reporting thingy is (or should) be all about.

Or is it more about getting the error report and ignoring it?

What is the point of including the error report mechanism if nothing is going to be done about it?

I mean, from the nobs that included the error report, I am guessing that there was a reason for it to be included.