php-general Digest 17 Mar 2012 22:57:20 -0000 Issue 7731
Topics (messages 317075 through 317086):
Re: Got HTML5 History API + caching LICKED, I think, <grin>
317075 by: rene7705
317076 by: rene7705
317077 by: rene7705
317078 by: rene7705
317079 by: Stuart Dallas
317080 by: rene7705
317081 by: Jay Blanchard
317082 by: Stuart Dallas
Re: $POST and $_SESSION
317083 by: Al
317084 by: Ashley Sheridan
317085 by: Al
317086 by: sono-io.fannullone.us
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Fri, Mar 16, 2012 at 10:17 PM, Govinda <govinda.webdnat...@gmail.com>wrote:
> Everyone makes valid points.. and depending on ones perspective, certain
> of those points are more important than others... but, because of my nature
> anyway, I want to just say thanks to rene7705 for bothering. He is not
> trying to take anything.. but just share his creative process, in case it
> is fun for anyone, or useful for anyone. He undoubtedly wants to improve
> too.. but there is the middle step where positive reinforcement is the most
> pertinent thing. Rene, don't mind the tones here.. we all get paid to
> scrutinize, so it can be hard to snap out of that critical mindset
> sometimes.
>
> -Govinda
Thanks..
--- End Message ---
--- Begin Message ---
On Fri, Mar 16, 2012 at 11:13 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 16 Mar 2012, at 20:53, rene7705 wrote:
> > On Fri, Mar 16, 2012 at 9:45 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> >> On 16 Mar 2012, at 20:36, rene7705 wrote:
> >>
> >> > On Fri, Mar 16, 2012 at 9:29 PM, Stuart Dallas <stu...@3ft9.com>
> wrote:
> >> >> On 16 Mar 2012, at 18:57, rene7705 wrote:
> >> >>
> >> >> > Hi Folks..
> >> >> >
> >> >> > I could waste a lot of text on what I've accomplished during the
> last
> >> >> > months, but the easiest thing is if you have a (another) look at
> (the
> >> >> > source of) http://mediabeez.ws
> >> >> >
> >> >> > I think you'll like my opensourced work :)
> >> >> >
> >> >> > Feedback is appreciated.
> >> >>
> >> >> I'm also having trouble downloading the ZIP file (Chrome 17.0.963.79
> on OSX - not that the browser will have anything to do with this problem at
> all). The download starts, gets to a few MB and doesn't get any further.
> >> >>
> >> >> And 52MB? Since I can't actually see what it contains it's hard to
> judge, but right off the bat... is your artwork necessary for the thing to
> work? What external libraries are you using?
> >> >>
> >> >> Just from looking around the site there are a few things that jump
> out...
> >> >>
> >> >> * The dropdown menus are incredible jittery, certainly nowhere near
> production-ready.
> >> >>
> >> >> * The background image gets squished according to the dimensions of
> the browser window.
> >> >>
> >> >> * Your homepage weighs in at massive 2.6MB. Nuff sed!
> >> >>
> >> >> I suggest you take the focus off the way it looks and concentrate on
> what it does. Tabs with animated backgrounds remind me of websites from the
> late 90s. You may have developed an incredible framework here, but I don't
> know because it's buried under >50MB of other stuff that I almost certainly
> don't care about, and that's before I've even been able to download it.
> >> >
> >> > ok..
> >> >
> >> > That being unable to download the zip file correctly is something
> I'll take up with my hosting provider tomorrow.
> >> > I've downloaded it in full and opened it OK in winrar just now, btw.
> >> >
> >> > The zip-file is created with winrar on windows 7, and according to
> Floyd Resler has to get it's extension changed to .rar, then decompressed
> with Stuffit Expander. Also something to look into soon, btw.
> >>
> >> That would explain why every zip decompression utility I've tried
> thinks it's corrupt.
> >>
> >> > As for my menu being jittery, it's not jittery on any of the windows
> browsers I tested.
> >> > And I have no mac-book available to me, not even from friends and
> family who are all on windows (on my recommendation btw ;)
> >>
> >> Are you ready for the shocking truth... not every computer in the world
> runs Windows, so unless you've developed this purely for the friends and
> family you've convinced to do so you may want to rethink your approach to
> testing.
> >>
> >> > As for my files and homepage being Huge, yep, it's made for the
> future or current fast internet connections.
> >> > Frankly, size reduction is not on my agenda. I'll wait for the nets
> to become faster still.
> >> > And the server should spit it out at 2MB/s at least..
> >>
> >> That may be so, but when my 100Mbit/s connection finally managed to
> download the file it took about 4 minutes, which is nowhere near 2MB/s.
> Your homepage takes 7 seconds to load - that's unacceptable in the real
> world, especially when you're talking about a server that's (and I'm only
> guessing here) not under heavy load.
> >>
> >> Anyway, your comment about waiting for the nets (sic) to catch up so it
> can cope with your bloat has convinced me to not bother looking any further
> into your project, but I wish you the best of luck with it (you're gonna
> need it).
> >
> > Okay, I don't wanna get into an argument here..
>
> Shame, because I'd love to see you try to defend a position that promotes
> wasting resources "just because they're there." This is not a new thing -
> ever-increasing computing resources have always led to this short-sighted
> view in the inexperienced, but trust me when I say you'll regret it when
> you're paying for the bandwidth being used by thousands of people
> simultaneously using a site that's using your framework. Why do you think
> other libraries such as jquery recommend minifying their code before
> deployment, and then serving it via gzip? Every bit and byte counts,
> especially as you scale up.
>
The javascripts are currenlty being served unminified via gzip, because
minifying them all the time creates too much overhead for me. If you want
them minified you can easily do that yourself.
>
> Anyway, I'm not trying to get into an argument (it's rare that I do), but
> I do recommend that you take in what I've said on this issue. The size of
> the data you're sending down the pipe matters if you want your library to
> be used for anything serious, and no amount of artwork or pretty pictures
> will distract anyone for long.
>
The download size will hardly be an issue for site operators, whom i
seriously suspect will be on faster links.
And the usage size doesn't have to be large, as mentioned earlier.
>
> > Rest assured, all the javascript for my animated widgets combined is
> about 25kb.
>
> Good for you. You might want to produce a download that doesn't include
> the optional stuff so you can show how small it is, and provide examples
> that show off what it can do using just that code.
>
Sorry, no, too much overhead for me.
>
> Incidentally, a little over 2MB of your homepage is the logo. 2MB for the
> logo? Seriously??
>
Yes, I don't expect my site to get 100's of NEW hits every second, and I
don't have to pay for bandwidth.
>
> > The artwork for simple animations is about 100kb per button/menu-item
> theme.
>
> 100kB is not a simple animation, that's a mini-movie.
>
Exactly. _animated_JavascriptWidgets it's called.
>
> > The fact that I demo how to put video on a button and thus end up with
> nearly a dozen button themes that are about 2MB each, is just taking
> advantage of the fast links that are available in much of the world.
>
> Make them a separate download. Not everyone is using a "fast link" and
> even those of us who are may not care about those themes, so give us a
> choice as to whether we download them. I certainly don't care about
> scenejs, yet it has decompressed to 19MB!
>
I might get rid of scenejs, I've fiddled with it and it's very immature atm.
And I'll consider putting my own larger artwork in a seperate download
(might be difficult and not worth my time to me).
>
> > About me testing only on windows, you're right about that and I'll see
> if I can do something to improve my testing regime. For now i'm dependent
> on your patience and bugreports tho.
>
> That's not what you said, you basically said that you've tested it on
> Windows and don't care about anything else. Please don't take this as harsh
> criticism, but if you're developing a library for other people to use, you
> need to consider the environments in which they're likely to use it. If you
> don't have the capability to develop/test your library on different systems
> you need to foster a community around your library that can test for you
> and ideally provide patches to fix bugs. I know testing on OSX can be an
> issue due to prohibitive cost, but there's unlikely to be a good reason why
> you can't test on Linux.
>
I do care about making my software work on other platforms besides windows.
Please provide accurate detailed bugreports, if you want to see a bug
fixed. For all the crying for proffesionality here, I haven't seen a single
one of the critics post actual error messages.
>
> > And I had no idea winrar made such crappy zip files, I'll look into a
> replacement very soon.
>
> Winrar did its job and made a rar file. Did you change the extension to
> zip? The best compression utility I've found for Windows is 7-zip, but I
> haven't used that OS for a while so I dunno if it's still the best.
>
I'll look into 7-zip.
>
> I took a quick look around your code and I saw some scary stuff in there.
> Taking lib_fileSystem.php as an example brings up the following issues...
>
lib_fileSystem.php is older code, and I appreciate your bugreports.
I'd appreciate bug fixes even more! :)
>
> * In the fgetsr function you open the file for reading and writing despite
> only needing to read from the file.
>
> * In zipExtractUnix you pass arguments onto the command line without
> escaping them. You also assume that there is a command named "unzip" on all
> platforms, where such a utility does not natively exist on any platform
> that I'm aware of (possibly some Linux distributions I'll grant you, but
> they're the exception rather than the rule).
>
> * Not entirely sure what evalDate is supposed to do (function-level
> comments would be useful) but it's passing variables into eval without any
> checks on what they contain. Rule of thumb: if you think eval is the answer
> you're asking the wrong question.
>
> * In getFilePathList you're using evalDate, so now I know what it's for,
> and you're definitely asking the wrong question.
>
getFilePathList will only use evalDate if you ask it to filter on date,
which none of my app code currently does.
>
> * Your readIniFile function appears to be doing the same thing as PHP's
> parse_ini_file function.
>
Ok, cool.
>
> * There's a PHP function for renaming files, which will let you make your
> renameFile function safe (it's not currently safe because it's another
> example of not escaping arguments on a command line).
>
Ok
>
> * Strangely you then use PHP's rename function to rename a file in
> moveDirectoryStructure, so you're clearly aware of it.
>
It's been a long time since I looked at lib_fileSystem.php
But hey, if you want to improve it and send the results back to me I'll
include them, give you credit, and make all of us very happy.
> I've probably missed stuff because this was a quick skim, and I've ignored
> stylistic preferences that bug the hell out of me, but despite those
> caveats there are some very serious, and pretty basic, security issues here.
>
Not if you realize that the code you found those bugs in is not actually
being used.
>
> I hope you find my feedback useful once you get past my sarcastic tone. I
> tried to control it once, but it wasn't pretty and it didn't end well! :)
>
I did :)
Just remember one thing: If you see something obviously wrong, why not send
me the fix?
--- End Message ---
--- Begin Message ---
On Sat, Mar 17, 2012 at 10:55 AM, Ashley Sheridan
<a...@ashleysheridan.co.uk>wrote:
> **
> On Fri, 2012-03-16 at 22:11 +0100, rene7705 wrote:
>
> On Fri, Mar 16, 2012 at 10:08 PM, Tommy Pham <tommy...@gmail.com> wrote:
>
> > On Fri, Mar 16, 2012 at 1:45 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> > >
> > >> As for my files and homepage being Huge, yep, it's made for the future
> > or current fast internet connections.
> > >> Frankly, size reduction is not on my agenda. I'll wait for the nets to
> > become faster still.
> > >> And the server should spit it out at 2MB/s at least..
> > >
> > > That may be so, but when my 100Mbit/s connection finally managed to
> > download the file it took about 4 minutes, which is nowhere near 2MB/s.
> > Your homepage takes 7 seconds to load - that's unacceptable in the real
> > world, especially when you're talking about a server that's (and I'm only
> > guessing here) not under heavy load.
> > >
> > > Anyway, your comment about waiting for the nets (sic) to catch up so it
> > can cope with your bloat has convinced me to not bother looking any further
> > into your project, but I wish you the best of luck with it (you're gonna
> > need it).
> > >
> > > -Stuart
> > >
> > > --
> > > Stuart Dallas
> > > 3ft9 Ltd
> > > http://3ft9.com/
> > >
> >
> > Yup... I think rene forgot the fact is if each client requests pull
> > 1MB/s , his upload has to be at least 120MB/s for 100 simultaneous
> > clients' connections. Last time I check in ISP services, that
> > bandwidth falls within OC-12+ category....
> >
>
> If ya'll would take a closer look at my site, you'd see that most of the
> size is in artwork.
> If you want a simple site, use simple artwork.
> It's _not_ my code's size that's any problem, as I mentioned earlier.
>
> Enough for now, I'll look at this list tomorrow again.
> Time for partying with the live mix at frequence3.fr now..
>
>
> Just adding my own two pennies to this lot.
>
> It does seem a little irresponsible to create such a large (in size)
> website, especially when you consider that in many countries people don't
> have high-speed or unlimited access. Even the UK has lots of areas with
> only basic Internet access via dial-up lines, and plenty of people rely on
> mobile dongles to connect, which are most often metered and slow.
>
> On to the technicals of what you wanted us to look at, because I think
> this thread has become slightly derailed from the original question.
>
The original comment was that I had licked HTML5 History API + caching.
No-one has even commented on that part.
>
>
> - The 'Home: Downloads, Blog' link at the top doesn't work for me at
> all. I'm using Fx 3.6 on Fedora 14
>
> True, coz that link should point to the homepage. I decided not to spread
my content out over tons of pages, or to create redundant content.
>
> -
> - The drop-down menu appears odd, with some items appearing over the
> others
>
> That's by design but can be changed in the source quite easily
(animatedJavascriptMenu-1.0.0.source.js)
>
> -
> - The products menu at the top does nothing when clicked on
>
> Same as the Home:Downloads,Blog link.
>
> -
> - Other 'pages' take a long time to load in
>
> Strange, they don't here, and it should drop to 0 once the cache is filled
up.
>
> -
>
>
> Sorry, but it really doesn't look very professional when basic things
> (like links) don't work at all. I'd hate to have any kind of disability
> because I doubt any screen readers would work, and using your site with
> only a keyboard would probably be just as impossible.
>
You can probably use the links in the content to get around the site.
Sorry the menu isn't accessible with keyboard, but that's something I don't
feel like making my problem right now.
I want to create content sites with these components, not get stuck in code
issue after code issue.
But hey, if you want to improve the components, and send me the result
back, I'll surely credit you where appropriate.
>
> That might seem like harsh feedback, but I do have quite a strong view on
> accessibility.
>
Ok. As I said, the content links can be used to browse around. Not ideal,
but it will do imo.
--- End Message ---
--- Begin Message ---
In response to critiques about my download size, I've removed scenejs and
the artwork for my own site-logos from the zip. The size is now 38mb, down
from 54mb.
I'm also using 7-zip now, I hope it opens better on non-windows OSes.
--- End Message ---
--- Begin Message ---
On 17 Mar 2012, at 10:54, rene7705 wrote:
> On Fri, Mar 16, 2012 at 11:13 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> Why do you think other libraries such as jquery recommend minifying their
> code before deployment, and then serving it via gzip? Every bit and byte
> counts, especially as you scale up.
>
> The javascripts are currenlty being served unminified via gzip, because
> minifying them all the time creates too much overhead for me. If you want
> them minified you can easily do that yourself.
Write a script that does the minifying, and everything else necessary to create
a distribution file. Do you really think someone manually runs jquery through
the minifier whenever they create a new release? As it happens, they use make:
https://github.com/jquery/jquery/blob/master/Makefile
It seems you're pretty new to all this, and I appreciate that, but you show
little to no willingness to learn from the people on this mailing list, despite
asking for feedback.
> Anyway, I'm not trying to get into an argument (it's rare that I do), but I
> do recommend that you take in what I've said on this issue. The size of the
> data you're sending down the pipe matters if you want your library to be used
> for anything serious, and no amount of artwork or pretty pictures will
> distract anyone for long.
>
> The download size will hardly be an issue for site operators, whom i
> seriously suspect will be on faster links.
> And the usage size doesn't have to be large, as mentioned earlier.
This comment shows how little you understand about the world from your haven of
high-speed internet. Part of the beauty of the internet is that it allows
people to disseminate information on a shoestring. I guarantee that 90+% of the
people behind the billions of websites in the world access the internet through
what you would probably consider a stone age connection.
It may surprise you to know that two thirds of the people on the planet do not
have any access to the internet at all:
http://www.internetworldstats.com/stats.htm
> Just remember one thing: If you see something obviously wrong, why not send
> me the fix?
I will, if you pay me. Open source developers don't do what they do "just
because it's there," at least not for the most part. They do it because their
goals align with those of the project, or because the project presents a
particular challenge.
What are your goals for this project? Why did you develop it instead of using
an existing library/framework?
Here's why I won't be sending you any fixes…
* There doesn't appear to be anything your library does that makes it stand out
from the thousands of similar libraries that already exist, many of which are
far more mature and have large numbers of contributors.
* It's a very, very long way off being suitable for usage as a black box.
* I see absolutely no value in using your library, either personally or
professionally, never mind contributing to it.
* Your attitude to the most basic and important advice you've been given
practically guarantees that getting involved would be incredibly frustrating
and fruitless.
Oh, and in case it wasn't clear, you'd need to pay me *a lot*!
I don't mean any offence, and I really do applaud your efforts, but in my
opinion you need a sharp dose of reality. I encourage you to continue to work
on your library because this sort of thing is usually a great learning
experience, but don't expect people to help you out when your response to the
most basic advice is "that's too much overhead for me." Add the fact that you
didn't even respond to the very serious security issues I raised and you can't
possibly be surprised if nobody wants anything to do with it. Oh, and it
doesn't matter if that particular code is not actually used because it's likely
indicative of the overall quality of the rest of the library.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Sat, Mar 17, 2012 at 2:07 PM, Stuart Dallas <stu...@3ft9.com> wrote:
> On 17 Mar 2012, at 10:54, rene7705 wrote:
>
> On Fri, Mar 16, 2012 at 11:13 PM, Stuart Dallas <stu...@3ft9.com> wrote:
>
>> Why do you think other libraries such as jquery recommend minifying their
>> code before deployment, and then serving it via gzip? Every bit and byte
>> counts, especially as you scale up.
>>
>
> The javascripts are currenlty being served unminified via gzip, because
> minifying them all the time creates too much overhead for me. If you want
> them minified you can easily do that yourself.
>
>
> Write a script that does the minifying, and everything else necessary to
> create a distribution file. Do you really think someone manually runs
> jquery through the minifier whenever they create a new release? As it
> happens, they use make:
> https://github.com/jquery/jquery/blob/master/Makefile
>
> It seems you're pretty new to all this, and I appreciate that, but you
> show little to no willingness to learn from the people on this mailing
> list, despite asking for feedback.
>
>
> Anyway, I'm not trying to get into an argument (it's rare that I do), but
>> I do recommend that you take in what I've said on this issue. The size of
>> the data you're sending down the pipe matters if you want your library to
>> be used for anything serious, and no amount of artwork or pretty pictures
>> will distract anyone for long.
>>
>
> The download size will hardly be an issue for site operators, whom i
> seriously suspect will be on faster links.
> And the usage size doesn't have to be large, as mentioned earlier.
>
>
> This comment shows how little you understand about the world from your
> haven of high-speed internet. Part of the beauty of the internet is that it
> allows people to disseminate information on a shoestring. I guarantee that
> 90+% of the people behind the billions of websites in the world access the
> internet through what you would probably consider a stone age connection.
>
> It may surprise you to know that two thirds of the people on the planet do
> not have any access to the internet at all:
> http://www.internetworldstats.com/stats.htm
>
> Just remember one thing: If you see something obviously wrong, why not
> send me the fix?
>
>
> I will, if you pay me. Open source developers don't do what they do "just
> because it's there," at least not for the most part. They do it because
> their goals align with those of the project, or because the project
> presents a particular challenge.
>
> What are your goals for this project? Why did you develop it instead of
> using an existing library/framework?
>
> Here's why I won't be sending you any fixes…
>
> * There doesn't appear to be anything your library does that makes it
> stand out from the thousands of similar libraries that already exist, many
> of which are far more mature and have large numbers of contributors.
>
> * It's a very, very long way off being suitable for usage as a black box.
>
> * I see absolutely no value in using your library, either personally or
> professionally, never mind contributing to it.
>
> * Your attitude to the most basic and important advice you've been given
> practically guarantees that getting involved would be incredibly
> frustrating and fruitless.
>
> Oh, and in case it wasn't clear, you'd need to pay me *a lot*!
>
> I don't mean any offence, and I really do applaud your efforts, but in my
> opinion you need a sharp dose of reality. I encourage you to continue to
> work on your library because this sort of thing is usually a great learning
> experience, but don't expect people to help you out when your response to
> the most basic advice is "that's too much overhead for me." Add the fact
> that you didn't even respond to the very serious security issues I raised
> and you can't possibly be surprised if nobody wants anything to do with it.
> Oh, and it doesn't matter if that particular code is not actually used
> because it's likely indicative of the overall quality of the rest of the
> library.
>
> -Stuart
>
>
Thanks for taking the time to explain your critiques.
It's just that I don't put out my software completely free to next be
overflowed with more work based on relatively vague descriptions of what
would be wrong with it.
I put it out there so more experienced programmers can send me improved
versions.
If you don't feel like doing that for free, that's your right of course.
The relatively crappy code in /code/sitewide_rv/lib_fileSystem.php is
certainly not indicative of the quality of the rest of the library, I'll
guarantee you. Just take a look at the output of
get_animatedJavascriptWidgets_javascript.php in the source of my
http://mediabeez.ws, and you'll see that that code is indeed of higher
quality.
As for minifying the javascripts, it would take me another day, maybe 2, to
build a script for that.
And I don't think it would matter much, all the animatedJavascriptWidgets
JS is gzipped 25kb and if I shave 5kb off that (upper estimate) then I
don't consider that worth the effort, at this particular time. I have other
things (content creation and compatibility) I want to get done atm.
I wrote this library because I have been unable to find anything like it on
the interwebs.
I put it out for free because I think it's cool to give something back to
the opensource community.
But, again, I'm not interested in having my priority list hijacked by
experts who won't bother just to give me back the fix.
Have a nice day.
--- End Message ---
--- Begin Message ---
[snip]
> As for minifying the javascripts, it would take me another day, maybe 2, to
> build a script for that.
> And I don't think it would matter much, all the animatedJavascriptWidgets
> JS is gzipped 25kb and if I shave 5kb off that (upper estimate) then I
> don't consider that worth the effort, at this particular time. I have other
> things (content creation and compatibility) I want to get done atm.
[/snip]
Really? A day or two? Minifiying also tends to reduce code size by 50% or more
depending on the author. If you only get a 25% reduction it is time to take a
look at your coding practices.
[snip]
> I wrote this library because I have been unable to find anything like it on
> the interwebs.
> I put it out for free because I think it's cool to give something back to
> the opensource community.
> But, again, I'm not interested in having my priority list hijacked by
> experts who won't bother just to give me back the fix.
[/snip]
Put it on Github and see how many free labor….uh, er…code fixers you can
attract.
Giving back to the community is a great thing, it is why many expert PHP coders
are on this list. They are already providing you with fixes that you aren't
listening to regardless of the language that these fixes are couched in.
Community is about give and take and you have started your foray into the
community by disallowing take.
Good luck!
--- End Message ---
--- Begin Message ---
On 17 Mar 2012, at 15:02, rene7705 wrote:
> The relatively crappy code in /code/sitewide_rv/lib_fileSystem.php is
> certainly not indicative of the quality of the rest of the library, I'll
> guarantee you. Just take a look at the output of
> get_animatedJavascriptWidgets_javascript.php in the source of my
> http://mediabeez.ws, and you'll see that that code is indeed of higher
> quality.
Curious example you've decided to highlight there. A few thoughts...
* It appears to be serving static javascript content. Why is PHP involved at
all here?!?
* It's using a hell of a lot more memory than it needs to by loading said
static content into a variable rather than simply including the files directly.
* The animatedThemes function appears to be loading and decoding json only to
re-encode it again before output. Err, why?
> I wrote this library because I have been unable to find anything like it on
> the interwebs.
I'm somewhat unclear on exactly what problem this library is attempting to
solve. The site says "video-enabled [stuff]" which sounds like nothing more
complicated than animated images. Am I missing something?
> I put it out for free because I think it's cool to give something back to the
> opensource community.
Which is fantastic and should definitely be encouraged, but if you're not
interested in feedback don't ask for it.
> But, again, I'm not interested in having my priority list hijacked by experts
> who won't bother just to give me back the fix.
I couldn't care less about your priority list if my life depended on it. You
asked for feedback; I gave you feedback. Everything I do I do for at least one
of the following three reasons, in descending order of importance...
* It interests me.
* It benefits me in some way, now or in the future.
* I'm being paid for it.
Sorting out the issues with your code doesn't meet any of these motivations.
Giving you feedback met two out of the three, which Mr Loaf asserts as !bad.
One of those fell away when you responded to said feedback by defending your
code as if it were intimately attached to your body. The last remaining
motivation is hanging by a thread.
> Have a nice day.
Thanks, I will. You have a nice day too.
Snap.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On 3/15/2012 11:04 AM, Tedd Sperling wrote:
$first_name = $_SESSION['first_name'] ? $_SESSION['first_name'] : null;
$first_name = isset($_POST['first_name']) ? $_POST['first_name'] : $first_name;
$_SESSION['first_name'] = $first_name;
$_SESSION['first_name'] = (isset($_POST['first_name']))?
$_POST['first_name']:(isset($_SESSION['first_name']))? $_SESSION['first_name']:null;
--- End Message ---
--- Begin Message ---
On Sat, 2012-03-17 at 12:52 -0400, Al wrote:
>
> On 3/15/2012 11:04 AM, Tedd Sperling wrote:
> > $first_name = $_SESSION['first_name'] ? $_SESSION['first_name'] : null;
> > $first_name = isset($_POST['first_name']) ? $_POST['first_name'] :
> > $first_name;
> > $_SESSION['first_name'] = $first_name;
>
>
> $_SESSION['first_name'] = (isset($_POST['first_name']))?
> $_POST['first_name']:(isset($_SESSION['first_name']))?
> $_SESSION['first_name']:null;
>
Isn't that basically the same as what I wrote?
$first_name =
(isset($_POST['first_name']))?$_POST['first_name']:(
isset($_SESSION['first_name'])?$_SESSION['firstname']:null);
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On 3/17/2012 12:52 PM, Al wrote:
On 3/15/2012 11:04 AM, Tedd Sperling wrote:
$first_name = $_SESSION['first_name'] ? $_SESSION['first_name'] : null;
$first_name = isset($_POST['first_name']) ? $_POST['first_name'] : $first_name;
$_SESSION['first_name'] = $first_name;
$_SESSION['first_name'] = (isset($_POST['first_name']))?
$_POST['first_name']:(isset($_SESSION['first_name']))?
$_SESSION['first_name']:null;
Another benefit is that the variable, $_SESSION['first_name'], doesn't need to
be assigned before hand.
--- End Message ---
--- Begin Message ---
On Mar 15, 2012, at 11:52 AM, Stuart Dallas wrote:
> Change your php.ini settings to log to a file and set display_errors to off.
Sometimes when you ask a stupid question you end up getting a brilliant
answer. I had no idea about any of this until I received your response, which
got me digging. I found out that I could create a custom php.ini file for my
site, and within hours of doing this, I had errors logged that I didn't even
know I had and was able to fix them. I've since created a cron triggered
script which e-mails me any errors on my site.
So thanks, Stuart, for posting your response. So far it's caught a
coding mistake (by me) and a "no product found in MySQL" error (because of a
discontinued item). I don't mean to sound dramatic, but this changes
everything for me. It's great to know that I'll be notified of any little (or
big!) problem without having to manually hunt it down.
Thanks again,
Marc
--- End Message ---
