KevinM1

Great, thanks! I just need to double-check that the hosting plan is using PHP5 by default.

I have a script that allows members to post upcoming events. The only problem is that, since the script is hosted on one of GoDaddy's shared host servers, the timezone isn't correct. The site shows events on the Eastern side of the US, so the correct timezone should be EST. GoDaddy's server is in MST, so all events are shown taking place an hour earlier than they should, with the wrong timezone abbreviation as well. This has caused people to show up too early for some events, as they're confused about when things are actually taking place. Here's the rub: this script is primarily a 3rd party CMS that I didn't create myself. I have tweaked some of the event registration portion, but not the method with which it saves event dates and times. These events' times are saved in a European format in the database: yyyy-mm-dd hh:mm:ss. When other members register for these events, emails are sent to both the person registering and the site admin. To transform the date into something we Americans are used to, I retrieve the event time from the database and run it through date("m-d-Y h:i:s T", $eventTimestamp). The problem, like I said before, is that since GoDaddy's server is in MST, that's what the 'T' flag in the date() function displays. Is there a simple way for me to set the timezone as +2 for it to display EST rather than MST? I know I could always just remove the 'T' flag and append 'EST' to the string, but I'm curious to see if there's a way to do it within the function itself.

I can't seem to get a complete download of Code Ignitor. WinRAR keeps telling me the .zip has been damaged. Is there another method of obtaining the framework?

The problem isn't syntax, it's that PHP is basically stateless. That is, your separate scripts won't automatically know what happening in the other files. You need to manually pass your objects from script to script. In your case, try using sessions: <?php //Functions.php class nav() { private nav_array = array(); function add($item) { array_push($this->nav_array,$item); } function remove() { array_pop($this->nav_array); } function get() { return $this->nav_array[0]; } } /*---------------------------- The scripts that makes it: ----------------------------*/ session_start(); include('Functions.php'); $nav = new Nav(); //do nav things $_SESSION['nav'] = serialize($nav); /*--------------------------- The script that takes it ---------------------------*/ session_start(); include('Functions.php'); $nav = unserialize($_SESSION['nav']); echo $nav->get(); ?> There may be other ways to do this, but I've used this method before and it works.

So, how would this main controller actually work? For, instance, in Jenk's hypothetical of having a forum administrator access and perhaps modify another user's account (perhaps to temporarily ban them from the forum for some infraction), how would something like that actually function? I'm assuming that you'd have the main controller, but how would the sub-controllers be invoked? Would they be in separate files and include()-ed based on what Request was sent to the controller (I'm thinking of the Command pattern from the Zandstra book, specifically the CommandContext class, which had an array, in part, constructed from $_REQUEST)? I dunno...I'm just having a hard time seeing how it would all fall into place. I keep feeling that I'm overthinking this whole thing as I haven't been exposed to anything like this in PHP. Most of the admittedly horrible largescale PHP code I've been exposed to has been in the form of a ton of files, each one actually visited by the user. So, if a site administrator wanted to ban a user, they'd be sent to something like a /admin/manageusers.php file. This file, like the rest, would have its own HTML embedded within. I keep thinking there has to be more, some trick to the OOP way of doing things.

Okay, so...what does a "main controller" look like? That's the conceptual hurdle I'm having trouble with -- the main thing that generates and/or contains the rest of the site's architecture. Is there typically just one main controller for an entire site?

Why oh why would you want to use anything remotely like Page Controller? It seems, to my limited experience, to be the most obvious way to go about things in a general sense. I know you're one of the OOP gurus on here (when I have time, I always try to find your posts in the layout/design subforum), so what would you suggest?

Thanks, both of you. I'm happy to see I'm somewhat on the right track. It looks like a hybrid approach would work best: a POE script for each large subsection of a site (user area, admin, forums, etc) which basically go the Page Controller route. Awesome! I was wondering if you could elaborate a bit. I'm not currently using any framework (stupid? probably, but I want to get the basics down first before adding another layer of complexity). I was wondering if you could further describe the "low-level prefetch data" caching you mentioned. I'm not exactly sure what you mean by that. Also, is there any way to see if PHP is acting as an HTTP module? Would this be visible in a phpinfo() call? Thanks again!

I figure that I haven't received any replies for one of two reasons: 1. This thread should be in the application layout/design subforum. If that's the case, then please feel free to move it there. 2. I didn't describe my problem well. I'll try to remedy that here. I think the best way to describe my confusion is to talk about PHP web app overhead -- how much setup work is required for each page. Obviously, this depends on the project at hand, and what it entails, but I can't think of a real elegant way to deal with this. Instead, two methods of dealing with this overhead come to mind: 1: In the point-of-entry (POE) script (index.php, or whatever the first page the user should access), do all of the setup -- initialize objects, setup their relationships, etc. For each page/script the user could potentially access after that, forward the objects to those pages via sessions. If the user hasn't visited the POE script, redirect them there. This obviously has several flaws. First, forcing the user to visit the POE script is a bit barbaric, especially if they come wandering into another portion of the site from a Google search or forum message link. Second, there's a lot of code repetition -- every script has to see if anything was set in the session, unpack and handle that info, then put it back into a session before the user navigates away. There are probably other weaknesses as well, but those are the two most obvious ones. 2: Have one main script run and decide what view to show. Every link and form submit would return to the main script, whose logic is to display the right view based on what was passed to it. I believe this is more or less what a Page Controller and/or Front Controller does, but don't quote me on that. This seems like it could get messy upfront, and could perhaps be dangerous if the $_GET values aren't scrubbed properly. Again, there's code repetition. Sessions would once agan have to be used. Upon each main script reload, the session variables would have to be checked, unpacked and handled, and packed back up again. The benefit, though, is that this code appears only once. Now, are either of these approaches realistic? If given a choice, I'd go with the second option, as it seems more logical and appeals to my amateur C++ coding side. Am I on the right track, or am I missing something fundamental?

Try: document.forms["entry_form"].elements["cat_id[]"]

I get the basics. I know what a Singleton is. I know what Composition is, in comparison to Inheritance. I understand the basics of PHP's flavor of polymorphism. But I still can't envision how everything ties together, how these classes and objects are tied into a true web application. I believe my biggest stumbling block is how to structure a PHP web app. Most of my (limited) OOP experience comes from C++ land, where the program is still running in the background, awaiting user input, while the user is served a new view based on that input. For example, in C++ I can create a simple program that acts like a shopping cart. I can add products, view what's in the cart, and check out of the store. Doing any of these things changes the view I receive -- the same executable is running in the background, waiting for me to do one of those three things. In PHP, it doesn't seem to be that easy. If I want to view my shopping cart, I create a link or form button which brings me to another page. How is this done, while keeping the app 'in place,' so to speak? Are all objects serialized and passed to the new pages via sessions? Or is there one main script which merely displays different views based on what's been passed to it (links w/$_GET values and $_POSTed form values)? If both approaches are used, then when would they be used? What are the tradeoffs? Most importantly, and if it isn't too much trouble, are there any examples one of you can give? Thanks a bunch! I think I'll finally get it if I can see some examples of this sort of thing.

If you're having suicidal thoughts, you should see a mental health professional immediately. It's best to find the cause of those thoughts, and attempt to find a healthy remedy, rather than maintain the status quo and deal with the thoughts on a day-to-day basis. You're right in that the world is unfair in many ways. Instead on dwelling on the negativity, try to help. Are there any charities in your area of the world that you can get involved with? You won't change the world, but you'll help some people, which is better than not doing anything at all.

I'm a fan of video game music. I own the soundtracks to Chrono Trigger, Chrono Cross, and Xenogears (I'm a big Yasunori Mitsuda fan). I sometimes put music from the Guilty Gear fighting games on my MySpace. The Black Mages -- Nobuo Uematsu's (the guy that's done most of the Final Fantasy music) own heavy metal band -- is awesome. I used to be into pen & paper roll-playing games. My first was one from TSR (the company behind Dungeons and Dragons in the 80's and 90's) called Star Frontiers. I used to play it a lot with my brothers when I was a small kid. The Blackwater debacle in Iraq sounds like a Shadowrun mission. I'm 27, and I still enjoy some anime. Not that Naruto-esque crap, but the good stuff. Evangelion, Ghost in the Shell, Cowboy Beebop, etc. I watch more Anime Network than 'normal' network television. I obsess a bit when it comes to smoking/smokers. I hate smoking. I get kind of like roopurt above when it comes to smokers -- don't touch things that I might eat/drink. And just because you can't smell it on you, it doesn't mean that I can't. I'm a bit weird when it comes to efficiency. I hate it when people (most notably my co-workers) half-ass it through projects. Either do it right, the first time, or don't do it at all. None of this "It's good enough" crap. I'm a perfectionist by nature. When I set about doing something, I work my tail off to see it done to the best of my ability, even if that means taking a bit of extra time. I'd rather use extra time upfront than waste it later when things inevitably go wrong because the project was rushed. So, yeah...there you go.

I was right -- my main problem was that FF didn't like the space (Glow Buttons) in the path of the background images' url. So, now the images appear, even though the layout looks like crap in FF thanks to the tag soup. But, whatever...fixing that is my co-worker's responsibility.

Ah, good point re: doctype. However, the buy it page is XHTML strict (https://www.tmsource.com/Buy It/buyit.php). The problem is there, as well. Again, like I said above, this CAN work in Firefox. My company's site -- which I also coded -- is proof of that. I'm going to try one more thing, in addition to adding a doctype to the other pages. FF's error console is giving me an error in the background properties for the rollovers, which is odd, as I don't get any errors from thinkingmachineonline.com, which uses almost the same exact CSS.

You don't need anything between the opening and ending anchor tags if you tell those anchors to be block elements rather than inline elements, which is what I've done. The CSS basically says this: For each <a>, make it a box with certain dimensions (in my example above, a 99 x 37 box). Give the background of that box an image (the url supplied in the background property) This image, in the same example, is 99 x 74. When the mouse hovers over the image, shift the background up 37 pixels. This method of creating rollovers does work. I've done it myself in other websites, including my company's site (http://www.thinkingmachineonline.com), which works perfectly in FF. That's why I'm at a loss as to why it's not working now. - really? I think so. I was able to explain it in a mere four sentences above. Once you figure out you're just creating a mask for a background image, it's not hard to visualize what's going on. EDIT: To see what my problem is, visit http://www.tmsource.com using Firefox. The navigation menu on the left will show several blank spots, which is where the rollover images are supposed to be. Like I said in my first post, those images are on the server. IE7 shows them just fine.

This is another one of those "It works in IE but not FF" problems. I have a series of rollover images for my navigation and some other things. I've had code similar to what I've written work in both browsers, so it's a mystery as to why it's not working across platforms in this case. The HTML in question is a bit messy. It was constructed by a co-worker purely out of Photoshop slices, so it's a pretty messy table layout. The page that I was responsible for was done tableless. For the table-based pages, the links in question are inside of table cells. For my tableless page, they're in unordered list elements. I doubt that makes a difference, as my page has been having issues with FF as well. So, a basic link would look something like: . . . <td colspan="3" id="home"> <a href="index.html"></a> </td> . . . The CSS to control the rollover is: td#home a{ background: url(images/Glow Buttons/homeglow.jpg) no-repeat 0 0; height: 37px; width: 99px; display: block; } td#home a:hover{ background-position: 0 -37px; } Pretty straight forward. Unfortunately, the images aren't actually being displayed. The images are there as they show up in IE7. Is it a matter of the image url's having a space in their paths (Glow Buttons)? Or is there something else going on?

Quick question: why are you using sprintf() with your query?

May I ask what corp you're in? It's an extremely new corporation me and a few friends put together about a week ago. We're all new players, don't worry you're not missing out on anything. Actually, I wasn't looking to join. I'm in a pretty decent corp right now -- Merch Industrial. Was just curious to see if you were a BoB member or ally. If so, there would be a chance of us meeting in battle.

May I ask what corp you're in?

Just like I thought -- form issues. Question: do you only want one of these values (captain, vice captain, wicketkeeper) to be selected? Or should someone be able to select two or more of the options?

See the solution offered here: http://www.phpfreaks.com/forums/index.php/topic,166977.0.html It's exactly what I recommend.

Hmm...I only see one post here. Regarding your problem, I'm thinking it has to do with your foreach-loop. The loop won't end if you find the right username:password data -- it'll keep iterating until it runs to the end of the file. Try putting a break in your if-conditional, after you handle a successful login. That may fix the problem.

We'll need to see your code. I have a feeling it's a simple matter of form validation, but it's hard suggesting a remedy without seeing how and why the problem occurs.

You know you want to. All the cool kids are doing it. Just a simple <?php phpinfo(); ?> Will suffice.....