Announcement

Collapse
No announcement yet.

Warning: Declaration of vBForum_Item_SocialGroupMessage

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mark.B
    replied
    Originally posted by GrnEyedDvl View Post
    No, you could start adding it to 4.2.4

    Declaring it final would convince more people to use it.
    There isn't a 4.2.4 and nor is there likely to be. If we declare 4.2.3 to be final then unless there is a major issue and management decide it should be fixed, that will be it. Hence, there is benefit to leaving 4.2.3 as it is since additional minor fixes can just be dropped into another beta with minimal fuss.

    Customers who need it are directed to it, and supported. I appreciate you disagree with the strategy, but that's how it is and it is not likely to change.
    You're obviously unhappy and I'm sorry about that, but that is how things are. Sometimes businesses have to take decisions not every customer likes.

    Leave a comment:


  • GrnEyedDvl
    replied
    Originally posted by Mark.B View Post
    4.2.3 remains in beta but is fully supported. All declaring it final will do, is make it much more difficult to add fixes like the recent facebook changes. the answer would become "sorry, can't do that at the moment, there is no open release".
    No, you could start adding it to 4.2.4

    Declaring it final would convince more people to use it.



    This is a server configuration issue. I can count on one hand the number of customers who report that this fails for them.
    One of them is in this thread before I posted. And that one is someone that probably doesn't control their own server like I do.



    Most of the questions in that post are not support questions, they are developer questions, which is most likely the reason there was no response. I agree it should have received a response, but that response would mostly have consisted of "the support team do not write the code so we cannot answer that".
    Anything would have been better than nothing, and by not responding at all you seriously irritated one customer that has 4 licenses, another that has 3 (technical member of my site), and robbed anyone else that comes across this problem of the normal interaction back and forth that should have happened that might help them solve their own problem. As stated I could point out numerous examples of stuff like this, that is the one that came immediately to mind as it was one that I posted. I don't post here a lot so its not too hard to remember where I have been active at.

    So all of the solutions we implemented are completely unknown to vBulletin and any of the members of this site who might have a similar issue, and we have conversations on our site related to the forumcache and how it works going back 5 years or more.



    No, it isn't "fixed". Fixing would mean rewriting the code to be "notice clean".
    All 4.2.3 does is go back to suppressing warnings and notices by default.
    This is what I was getting at regarding the confusion in terminology.
    Perception again. If the problem goes away in the mind of your customer its "fixed" which is all they care about. Writing the code to be notice clean could be pushed out to the next release while "fixing" it for the people that are having problems now.

    For the record, one of the guys on my site who is far better with php than I am has done just that with the vBulletin code along with many other fixes. The only reason I am here now is because I changed the license for my site (I was still using the original owners license because your license change policies suck) and finally got around to installing my license that has the CMS features. When I did that obviously it wiped all our custom code so I started poking around this site seeing if there were better options than the ones we were using for some things and ran across this thread.


    They don't have to wait a year.
    As has been stated many times - it is perfectly fine to install 4.2.3 as a beta. I've even installed it on paid professional installs.
    So you really think the non-technical people we are mostly talking about here are going to tick the More Download Options in the members area and install a product marked by you guys as "Unstable"? Then you are seriously kidding yourself.

    Leave a comment:


  • Mark.B
    replied
    Originally posted by GrnEyedDvl View Post
    Which has been in beta for at least 9-10 months now. There are lots of little things like this in the 4.2.3 release that easily could have been pushed out sooner instead of waiting for a year because they do not really require any serious testing.
    4.2.3 remains in beta but is fully supported. All declaring it final will do, is make it much more difficult to add fixes like the recent facebook changes. the answer would become "sorry, can't do that at the moment, there is no open release".

    Originally posted by GrnEyedDvl View Post
    You will see that a few people posted this did not work for them. It did not work for me either. This fails on some lighttpd and nginx installs as does the disable_hooks true/false line. That one disables hooks whether its true or false, to enable them you have to comment the line out entirely.
    This is a server configuration issue. I can count on one hand the number of customers who report that this fails for them.

    Originally posted by GrnEyedDvl View Post
    I know, I am one of them. One of the sites I own is probably one of the more heavily customized ones out there, and was actually that way when I took it over from the guy who owned it previously. In fact we as a site have been reporting issues since 2004 though I have only been seriously involved since 2008 or so. And I could point out at least 2-3 off the top of my head that either got no response at all or got something so lame that it irritated the crap out of me. Here is a perfect example of that, no response at all from you guys.
    http://www.vbulletin.com/forum/forum...grade-problems
    Most of the questions in that post are not support questions, they are developer questions, which is most likely the reason there was no response. I agree it should have received a response, but that response would mostly have consisted of "the support team do not write the code so we cannot answer that".

    Originally posted by GrnEyedDvl View Post
    I mostly agree with that, which is why I posted. Where we disagree is the "there is nothing to fix" statement. There is something to fix, and it IS fixed in a future release that as of yet has no planned release date that I have seen.
    No, it isn't "fixed". Fixing would mean rewriting the code to be "notice clean".
    All 4.2.3 does is go back to suppressing warnings and notices by default.
    This is what I was getting at regarding the confusion in terminology.

    Originally posted by GrnEyedDvl View Post
    They do, and they also have an expectation that when you guys push out a change its an improvement, with "improvement" being a subjective term for each user. When they move from 4.2.1 to 4.2.2 and it breaks their site it doesn't matter what the reason is, its not an "improvement". All you had to do with this is explain why you thought making the change was a good idea, tell them the temporary fix is, and push out the real fix without having to install a beta platform or wait a year for it.
    They don't have to wait a year.
    As has been stated many times - it is perfectly fine to install 4.2.3 as a beta. I've even installed it on paid professional installs.

    Leave a comment:


  • GrnEyedDvl
    replied
    Originally posted by Mark.B View Post
    4.2.3 changes the behaviour back to how it was in 4.2.1 and right back to 3.0.0.
    It hides notices and warnings by default.
    Which has been in beta for at least 9-10 months now. There are lots of little things like this in the 4.2.3 release that easily could have been pushed out sooner instead of waiting for a year because they do not really require any serious testing.



    However, changing the bahviour in 4.2.2 is a simple matter of adding one line to the config.php file.
    You will see that a few people posted this did not work for them. It did not work for me either. This fails on some lighttpd and nginx installs as does the disable_hooks true/false line. That one disables hooks whether its true or false, to enable them you have to comment the line out entirely.


    Customers have been adding lines to the config.php file for many years for all sorts of reasons - disabling hooks, increasing memory, enabling and disabling debug mode, to name but a few.
    I know, I am one of them. One of the sites I own is probably one of the more heavily customized ones out there, and was actually that way when I took it over from the guy who owned it previously. In fact we as a site have been reporting issues since 2004 though I have only been seriously involved since 2008 or so. And I could point out at least 2-3 off the top of my head that either got no response at all or got something so lame that it irritated the crap out of me. Here is a perfect example of that, no response at all from you guys.
    http://www.vbulletin.com/forum/forum...grade-problems

    In fact the only reason that site is still on vBulletin is because its so heavily modified. If it was a mostly vanilla install I would have moved it to a different platform after the link posted above.

    As stated I do like vBulletin overall, but once you get into the realm of bigger sites it has some issues. By "bigger sites" I mean 1000+ people online and thousands of page views per minute, not to mention that we right now have 172 user groups and 1200 subforums which possibly is the most you have ever heard of on a vBulletin install. Its very complex. Actually more complex than most of the Windows Active Directory domains I manage.



    When I said "there's nothing to fix", I'm talking about the fact that many people don't understand that these are warnings and notices, not errors, (not knowing the difference is perfectly understandable since it LOOKS like an error to the untrained eye), and then when we give them the line to add to config.php they object, claiming we're "hiding errors" and demand we "fix them rather than hide them". All of this confusion is understandable, since we don't expect customers to have a working knowledge of php programming to be able to run the software, but the correct situation should always be explained in "layman's terms", in my view.
    I mostly agree with that, which is why I posted. Where we disagree is the "there is nothing to fix" statement. There is something to fix, and it IS fixed in a future release that as of yet has no planned release date that I have seen.



    Customers have a right to understand what we're asking them to do with their product, should they want to do so.
    They do, and they also have an expectation that when you guys push out a change its an improvement, with "improvement" being a subjective term for each user. When they move from 4.2.1 to 4.2.2 and it breaks their site it doesn't matter what the reason is, its not an "improvement". All you had to do with this is explain why you thought making the change was a good idea, tell them the temporary fix is, and push out the real fix without having to install a beta platform or wait a year for it.


















    Leave a comment:


  • Mark.B
    replied
    Originally posted by GrnEyedDvl View Post
    I don't generally get involved in these conversations but its getting a bit ridiculous around here.



    There is definitely something to fix, even if it is only the perception of your customers.

    Most of your customers have no idea how their servers are configured as they are on hosting provided by a third party, and they are not technical people to begin with. The fact that this is just a deprecation warning doesn't really mean anything to them, what DOES mean something to them is that they either do not know how to fix it or do not have the access to change how their webserver is setup and that on some installs it really does break the forum software. All they want is their forum to run smoothly.

    So yes, it needs to be "fixed" and it needs to be fixed now.

    But what really needs to be fixed around here is the attitude of some vBulletin employees. First off who are you to say what an "incorrectly configured" server is. The reason that is even an option in php is so that people can test things. So lets say that someone running a shared hosting server has a problem reported by one of his customers and he enables this to help troubleshoot. It doesn't "break" other software packages, but suddenly now anyone hosting vBulletin on this server has a broken site because the server owner tried to help another customer. This is unacceptable.

    But even worse is the way vBulletin employees respond to their customers. You deliberately changed it to display in 4.2.2 even though you know full well it breaks some installs of vBulletin, and then 3-4 of you respond spend more time responding in this thread than it would take to change it back. And then you tell your customer to go tell whoever operates his server that its their problem when they truly do not understand what is going on in the first place. All they know is that vBulletin does weird stuff.

    I have been in business for a very long time now, and I swear if someone working for me did that he would be fired. Either you do not know how this impacts the reputation of vBulletin or you do not care. Either is unacceptable. At some point every forum operator out there has one of his forum members ask him his opinion of whatever software package they are using, and you just gave them one hell of a good reason to give you a negative review. Shame on you.

    As one of the bigger vBulletin forums out there, along with several other smaller installs, I do as a general rule like the package. But you guys are notorious for not responding well to problems. I can point out numerous examples of this. Its probably not worth my time to do so but I had to comment this time because I am getting tired of seeing these kinds of replies on a premium platform.
    4.2.3 changes the behaviour back to how it was in 4.2.1 and right back to 3.0.0.
    It hides notices and warnings by default.

    However, changing the bahviour in 4.2.2 is a simple matter of adding one line to the config.php file.
    Customers have been adding lines to the config.php file for many years for all sorts of reasons - disabling hooks, increasing memory, enabling and disabling debug mode, to name but a few.

    When I said "there's nothing to fix", I'm talking about the fact that many people don't understand that these are warnings and notices, not errors, (not knowing the difference is perfectly understandable since it LOOKS like an error to the untrained eye), and then when we give them the line to add to config.php they object, claiming we're "hiding errors" and demand we "fix them rather than hide them". All of this confusion is understandable, since we don't expect customers to have a working knowledge of php programming to be able to run the software, but the correct situation should always be explained in "layman's terms", in my view. Customers have a right to understand what we're asking them to do with their product, should they want to do so.

    Leave a comment:


  • GrnEyedDvl
    replied
    I don't generally get involved in these conversations but its getting a bit ridiculous around here.


    Originally posted by Mark.B View Post

    There is nothing to fix.
    There is definitely something to fix, even if it is only the perception of your customers.

    Most of your customers have no idea how their servers are configured as they are on hosting provided by a third party, and they are not technical people to begin with. The fact that this is just a deprecation warning doesn't really mean anything to them, what DOES mean something to them is that they either do not know how to fix it or do not have the access to change how their webserver is setup and that on some installs it really does break the forum software. All they want is their forum to run smoothly.

    So yes, it needs to be "fixed" and it needs to be fixed now.

    But what really needs to be fixed around here is the attitude of some vBulletin employees. First off who are you to say what an "incorrectly configured" server is. The reason that is even an option in php is so that people can test things. So lets say that someone running a shared hosting server has a problem reported by one of his customers and he enables this to help troubleshoot. It doesn't "break" other software packages, but suddenly now anyone hosting vBulletin on this server has a broken site because the server owner tried to help another customer. This is unacceptable.

    But even worse is the way vBulletin employees respond to their customers. You deliberately changed it to display in 4.2.2 even though you know full well it breaks some installs of vBulletin, and then 3-4 of you respond spend more time responding in this thread than it would take to change it back. And then you tell your customer to go tell whoever operates his server that its their problem when they truly do not understand what is going on in the first place. All they know is that vBulletin does weird stuff.

    I have been in business for a very long time now, and I swear if someone working for me did that he would be fired. Either you do not know how this impacts the reputation of vBulletin or you do not care. Either is unacceptable. At some point every forum operator out there has one of his forum members ask him his opinion of whatever software package they are using, and you just gave them one hell of a good reason to give you a negative review. Shame on you.

    As one of the bigger vBulletin forums out there, along with several other smaller installs, I do as a general rule like the package. But you guys are notorious for not responding well to problems. I can point out numerous examples of this. Its probably not worth my time to do so but I had to comment this time because I am getting tired of seeing these kinds of replies on a premium platform.
























    Leave a comment:


  • Mark.B
    replied
    Originally posted by kourou View Post
    This is not a software we should be paying for.

    Upgraded to the latest "stable" release so that I have to google for a problem, the solution to which was to "hide the error/warning messages". It's a known bug for more than a year and still not fixed.

    Your next goal should be to release something really stable, worth our money, because, from what I can see, for the last 3 or 4 years any new version is much more buggy than the previous.
    There is nothing to fix.

    They are not error messages, they are php warning and notice messages. Every version of vBulletin prior to 4.2.2 used to hide them by default. They should not display on a production server anyway.

    In 4.2.2 we changed the behaviour of this, which has the result that on in correctly configured servers, the warnings and notices will show.

    Leave a comment:


  • donald1234
    replied
    Originally posted by kourou View Post
    This is not a software we should be paying for.

    Upgraded to the latest "stable" release so that I have to google for a problem, the solution to which was to "hide the error/warning messages". It's a known bug for more than a year and still not fixed.

    Your next goal should be to release something really stable, worth our money, because, from what I can see, for the last 3 or 4 years any new version is much more buggy than the previous.
    Vbulletin 4 is not being developed anymore. You will need to upgrade to vbulletin 5 for latest release. Also the issue you mentioned I believe has been fixed in 4.2.3, and although is beta that is only because it is not being developed and no point in having 4.2.4 etc so easier to add anything that crops up as the next beta.

    Leave a comment:


  • kourou
    replied
    This is not a software we should be paying for.

    Upgraded to the latest "stable" release so that I have to google for a problem, the solution to which was to "hide the error/warning messages". It's a known bug for more than a year and still not fixed.

    Your next goal should be to release something really stable, worth our money, because, from what I can see, for the last 3 or 4 years any new version is much more buggy than the previous.

    Leave a comment:


  • Picasopaya
    commented on 's reply
    Thanks for this hint!

  • Paul M
    replied
    Its not going to be fixed in 4.2.2 at all, its fixed as part of 4.2.3.

    Leave a comment:


  • 14DH01
    commented on 's reply
    you must integrate Team developer "vb" at the top

  • brandondrury
    commented on 's reply
    Worked for me! I'll take it. Thanks!

  • fayax
    replied
    Barcraft's post number 26 fixed the same issue on mine.

    Leave a comment:


  • Mark.B
    replied
    vBulletin has always suppressed php warnings by default, right up until 4.2.2. Most other software works exactly the same way. Php warnings should not really be displayed on a production server at all, so you may want to ask your host about that.. You need to understand what a php warning is. It simply means that that piece of code is, or will soon be, deprecated in php and may not work at all in a future version of php. It does NOT mean it won't work now. However, displaying the warnings themselves can break functionality in a php application such as vBulletin.

    Leave a comment:

Related Topics

Collapse

Working...
X