Errors and warnings - a question and a rant.

[phpdevster]

Yes, I know about turning off errors and warnings in error_reporting. And that's where I'll begin my rant.

A developer, under no circumstance, should be releasing production code if they were doing development in an environment with warnings/notices disabled. It's sloppy, lazy, unprofessional, and potentially very dangerous to your end users. This goes for Joomla's developers, Virtuemart's developers, and third party developers making sites for clients.

So that said, I have two questions:

1. Why am I seeing a screen full of warnings and notices like this?:

Code Select Expand

- Warning: flock() expects parameter 1 to be resource
- Warning: fopen(/var/www/project/cache/com_virtuemart_cats/fc4a21a6c5b54590b98da1095d94191e-cache-com_virtuemart_cats-5c1597e29454c2fb76e20dfa4a6a893a.php) ...

2. Is there a way to fix it without just sweeping the problem under the rug by disabling warnings / notices?

3. (rhetorical) if warnings / notices this glaring weren't noticed during development, what else is potentially wrong with Virtuemart? ( "So don't use Virtuemart " - yeah yeah I know. I have no choice, it's part of my client's existing project)

[Milbo]

The best way to introduce yourself to a community, show your half knowledge.

First: we develop with "E_ALL & ~E_STRICT"
Second: it is still correct to disable all errors in a production environment
Third: You see this warnings due a misconfigured server (file perms, ownership,...)
4th: You should indeed solve the problem asap
5th: The warning is not done by us, the warning is generated by the joomla cache!

6th: No reason to rant us and directly tell us how todo it better, if you do not know yourself whats going on. It maybe quite helpful to learn a bit about yourself http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[AH]

LMAO   

[phpdevster]

First: we develop with "E_ALL & ~E_STRICT"

Then Im guessing you're not using a debugger like Xdebug, which doesn't get fooled by @ suppression operators and other lazy workarounds.

I can't fault you for that I suppose. Not many devs debug PHP.

Third: You see this warnings due a misconfigured server (file perms, ownership,...)

Nope. All relevant folders (project root, cache, com_virtuemart_cats) are www-data:www-data 755.

The ACTUAL problem does indeed lie with Joomla core: line 272 of the JCacheStorageFile class

Code Select Expand

$_fileopen = @fopen($path, "r+b")

Inspecting that $path var in the debugger (or dumping it) reveals it's empty - it isn't even set yet. It has NOTHING to do with server configurations. Joomla devs decided that instead of doing:

Code Select Expand


if (!file_exists($path)) {
    return;
}

They would just suppress the warning and pretend it didn't happen. Laziness.

4th: You should indeed solve the problem asap

As pointed out above, I didn't cause it.

5th: The warning is not done by us, the warning is generated by the joomla cache!

Fair enough. But if you had been using a debugger that ignores error suppressions, you would have caught the problem. The work around is easy enough: create the file ahead of time before calling:

Code Select Expand

self::$categoryTree = $cache->call (array('ShopFunctions', 'categoryListTreeLoop'), $selectedCategories     , $cid, $level, $disabledFields);
On line 778 of ShopFunctions.

6th: No reason to rant us and directly tell us how todo it better, if you do not know yourself whats going on. It maybe quite helpful to learn a bit about yourself http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

I do know better what's going on. What's going on is sloppy programming. I was asking if there was a known solution to this problem aside from either hacking joomla core, or hacking virtuemart core (or compromising my personal development environment's error checking integrity).

[Milbo]

First: we develop with "E_ALL & ~E_STRICT"

Then Im guessing you're not using a debugger like Xdebug, which doesn't get fooled by @ suppression operators and other lazy workarounds.

I can't fault you for that I suppose. Not many devs debug PHP.

Almost all of us use XDebug or similar. I mean with that almost any PHP programmer/developer/coder. It is really silly to think this, shows your arrogance. IF you would have ever read a joomla tutorial you would have read that setting up xdebug is part of the basic manual. http://docs.joomla.org/Setting_up_your_workstation_for_Joomla!_development

Code Select Expand

$_fileopen = @fopen($path, "r+b")

Inspecting that $path var in the debugger (or dumping it) reveals it's empty - it isn't even set yet. It has NOTHING to do with server configurations. Joomla devs decided that instead of doing:

Then it seems you have some other serious issue. You should go to a joomla forum and ask there. In fact, I never heard about this error. So there is something other wrong and I still think it is your server configuration or hoster.

Code Select Expand


if (!file_exists($path)) {
    return;
}

They would just suppress the warning and pretend it didn't happen. Laziness.

Yepp, that is true. But it is joomla code, not ours. In our guidelines the use of @ is forbidden, but even we have some cases we use it (3-4 times).

5th: The warning is not done by us, the warning is generated by the joomla cache!

Fair enough. But if you had been using a debugger that ignores error suppressions, you would have caught the problem.

OMG, why the heck you tell this shit? Do you know it? Did you ever asked me, or was in my office? I doubt. You just guess it due your arrogance and missing knowledge. Proven in the next sentence.

The work around is easy enough: create the file ahead of time before calling:

Code Select Expand

self::$categoryTree = $cache->call (array('ShopFunctions', 'categoryListTreeLoop'), $selectedCategories     , $cid, $level, $disabledFields);
On line 778 of ShopFunctions.

Hahah, disqualified. The joomla cache (known as good working horse on million of pages, btw) creates some error, the answer is for you to create the file before the cache does it. Very good, lol.

The reason that you get this error is some problem in your joomla setup, server config, whatever. The reason that we do not see the error is just that we do not have it.

Still no reason to rant us. Period.

[phpdevster]

The reason that you get this error is some problem in your joomla setup, server config, whatever. The reason that we do not see the error is just that we do not have it.

No. I showed you the exact line where the problem exists. Joomla is assuming the file exists before opening it, but it does not actually attempt to create the file at any time before line 272 of JCacheStorageFile. It doesn't actually create the file until later in the request cycle.

That means one of two things:
1. The order in which they process a cache request is illogical.

or

2. You are required to touch() the path before JCacheStorageFile writes content to it.

Either way, it is a code-level problem, not a server configuration problem.

Something is wrong with YOUR Xdebug/server configuration if it is respecting the @ operator.

Code Select Expand

<?php @fopen('invalid_path', "r+b"); ?>

If you run that and don't see an Xdebug warning, then something is wrong with your Xdebug configuration.

EDIT
Just confirmed: JCacheStorageFile::lock() gets called BEFORE JCacheStorageFile::store(). It's attempting to lock a file that hasn't been created yet. So yeah, not your fault obviously, but still a code problem. Not my server configuration.

[Milbo]

No, because no one else has this error. That means your setup is creating the problem.

and again no, because the purpose of the @ IS to suppress a warning. It is a quite academic discussion what is faster,... the @, which makes anything 10 times slower, or to test first if there is a file and then to lock if in case there is almost always a file, because it is cache. Theoretically the right thing is often pragmatically NOT the right thing. So you are the guy who uses a wrong setup. http://de3.php.net/manual/en/language.operators.errorcontrol.php

The world is a lot more complex than you think.

[phpdevster]

No, because no one else has this error. That means your setup is creating the problem.

Argumentum ad populum

10,000 wrong people are still wrong.

Here are the facts:

1. The code is not correctly structured; lock() is being called before store() (illogical programming)
2. lock() is not testing to see if the file it's supposed to be locking even exists (sloppy programming)
3. An error is being thrown by PHP, but is being suppressed by the @ operator (lazy programming)
4. My machine has brought this bug to my attention. (strict code checking - sees all problems)
5. Your environment(s) are not alerting you to the bug. (loose code checking - sees only some problems)
6. Therefore my setup is correct, yours is not.

http://www.leftjoin.net/2011/03/disabling-suppress-error-operator/

In your php.ini file, you should have the following line:

Code Select Expand

xdebug.scream = 1;

That will disable the @ operator and alert you to ALL issues.

[Milbo]

No because it is intended. You can write it different but it will be slower. And warnings and notices are not errors, nor bugs, else we would not call them "warning" and "notice".

[phpdevster]

No because it is intended.

Can you clarify what is intended here? Is it the illogical code structure, or the sloppy lack of variable validation?

You can write it different but it will be slower.

What will be slower?

0.36 seconds
for ($i=0; $i < 10000; $i++) {
   if (file_exists('not_a_file')) {
      $file = fopen('not_a_file', 'r+w');
   }
}

1.03 seconds
for ($i=0; $i < 10000; $i++) {
   $file = @fopen('not_a_file', 'r+w');
}

Turns out doing it the correct way (the way that doesn't produce a shit ton of warnings) is 3x faster.

I hate to break it to you, but Joomla is already extremely slow. The difference in performance of file_exists() vs @ is like a fart in a hurricane. But as it turns out, the file existence check is actually faster anyway...

And warnings and notices are not errors, nor bugs, else we would not call them "warning" and "notice"

They are errors. Else the function that triggers them wouldn't be called error_reporting(). Do you really want to play a game of semantics?

[Milbo]

I critise often enough the joomla code, everyone in the scene knows that the vm guys are constantly upset about joomla. So it is completly silly to carry owls to Athen.

But still it is a note, if you want to change this, go the JOOMLA Forum and dont bother us with that. If you do not understand then you should first learn the principles of sharing and distributing work. We are doing virtuemart, so ask here for virtuemart, if you have problems with the joomla code, okey, good, you can tell us, but no reason to rant us.

If you still do not understand that, you should really learn how human societies work.

Why you just did not come in here saying "look what the joomla guys did for a nonsense, they use an @ here to supress the notice instead of just doing it correctly." You would have get big applause and we would talk about if we should change in in our "joomla-vm-distribution".

But still the whole thing is academic. A cache set to 15 minutes mins means that the notice is suppressed any 15 minutes, and your test is working with 10000 of files. So we talk about a speed difference of less a second in 15 minutes for 10000 pages? come on. We talk here longer then you can spare.

Still it has "nothing" todo with us. If the engine in your car has Problem, you wont go to the guys who created the stereo, right? Do you really expect that sony changes the engine of the car? NO, you never would think that, same here. We do not write joomla, we just use it.

And warnings and notices are not errors, nor bugs, else we would not call them "warning" and "notice"

They are errors. Else the function that triggers them wouldn't be called error_reporting(). Do you really want to play a game of semantics?

Of course. Programming is MAINLY understanding Semantics and it is still a notice and a warning and not an error. Period. Lern to use language! If there are different words for the "same" thing, promised it is NOT the same thing. If you think it is the same thing, it is an indicator that you do not understand it correctly.
We call that definitions. A note and a warning is defined as not being an error. The configuration is in the error_reporting, yes. But that is like the light in your kitchen, even it is in your kitchen, you cannot eat it, right? same here. Not everything done by the error_reporting is an error, not everything in your kitchen is eatable, not everything in your icebox is food.

lol really OMG. We could have a nice talk, if you would just stop to attack people with your half knowledge. Would be interesting to know your age. You remember me to myself around 5 years ago.

And you should really learn how opensource works. When you think the cache can be optimised, then go to joomla and change it. We cannot change it. Wrong address.

You are writing all the time to the wrong Address. It is like going to Obama and being annoyed that the Krim is taken by russia. Go to Putin if you have a problem with that, okey?

[Milbo]

We have now the new Virtuemart/joomla full installer package to exactly address problems like this.

So lets burry the hatchet and concentrate to develop a nice joomla distribution, removing exactly sloppy programming like that. Atm we are working on the sql of joomla. More keys, some fields change from char to int already and similar.

We also plan to sell a product "Joomla2.5.x + Virtuemart + security maintaince for two years". So in fact your hint is welcome, but without rant.

[AH]

A very illuminating post, with a confusing end.

Why is the VM "team" aiming to manage joomla maintenance and security for 2 years!

Have you suddenly a big amount of resource with nothing to work on to develop and improve VM, have we a tested "bug free" version to put into Joomla 3 already? 

Joomla team release and support Joomla, or are they so inept that the VM team will aim to support and "fix" that as well??



http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[Milbo]

No, what we discuss internally is to support joomla2.5 with security patches a longer time than joomla plans.

Atm we are in a really strange situation. A lot people think that joomla 2.5 will be EOL in autumn 2014, because that was the old plan. So they want to use joomla 3.5, but there isnt any. It is not unusual that it takes some months until you are ready with your store. People dont want to start with j2.5 and be forced to directly update. I am quite sure they will support joomla 2.5 at least a year from now. So there are a lot people ( around 30 people asked me this last month) who would like to see that someone supports joomla2.5 for the next 4-5 years and of course we just talk about security related stuff. The security fixes in vm2.5.19 was a thing of 1-2 hours maybe. Btw it does NOT effect people using only the virtuemart account maintaince.
Atm we created the fullinstaller, too many people stumble over simple joomla stuff. If you take the fullinstaller, you directly have the menues and all that configured. So why not making a joomla version prepared for ecommerce? We can change what we want as long the API is the same.
So we could for example enhance the cache. Atm we are playing with MyIsam and InnoDb for the tables. Thinking about where to add keys and similar. It should be non-invasive and not a new joomla distribution or something like that. All is offered of course to the joomla community. Just some optimisation we stumble over, like this @thing loading files.

No because it is intended. You can write it different but it will be slower. And warnings and notices are not errors, nor bugs, else we would not call them "warning" and "notice".

So this seems to wrong, thanks for clearing this phpdevster. But to lock the file before it is stored is in fact correct. Greets

[AH]

Milbo

You Sir are a star.

Great and informative response.

Keep up the fantastic work!!