maxxd

You are absolutely correct - OK, thank you for clearing that up in my head. It made perfect sense until I started over-thinking it...

Hang on - wait, though. Question about that. At work, our development server is a BlueHost shared server; using '/' can't refer to the disk root in that case, can it? Because I don't have root access, and there are other hosted sites on the same server. The way we set it up is this - with every site, we create a subdomain of our main development domain, and using a slash within that subdomain to create an absolute reference to stylesheets, images, javascript files, etc. works. What's the difference between me setting up a virtual host on my local machine and a national hosting provider setting up a virtual host on their machine (other than the fact that they know what they're doing)? I actually never used to do the whole virtual server set-up at home, but I was running into issues where simply using http://myDevMachine/myNewSite/www/ was causing behavior that differed from my production server.

Got it - thank you much!

That makes perfect sense - thank you! So if I were to prepend a www. to the 'domain name' it'd work as expected? I'm using quotes because it's not a registered domain name, and I didn't prepend the www. to the server directory to begin with because it's all just on my local network - I'm using the .hosts file on my Windows boxes to trick the browser into connecting to the dev server as though the site was published on the Interwebs.

Hey y'all. I'll gladly admit that I'm not a server guy - I have the utmost respect for people comfortable enough with *nix to handle Apache setup and configuration in a production environment. I can noodle about in *nix typically without killing anything vitally important, but trust me when I say no-one wants me to be a server administrator. That having been said, I do have a development server behind my home network firewall running Ubuntu that I use to test and develop the sites that I create on my separate Windows box. So I try to keep up with the way a shared server would be set up in a real-world situation, to a degree. For instance, I haven't bothered setting up the mail server or FTP, but I do create virtual host files for each of my projects. So, I've got a virtual host set up on the directory /var/www/myAwesomeSite.com/ with the .conf file containing the following configuration: <VirtualHost *:80> ServerAdmin webmaster@localhost ServerName myAwesomeSite.com DocumentRoot /var/www/myAwesomeSite.com/www <Directory /var/www/myAwesomeSite.com/www> AllowOverride All </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost> Now, in my php scripts echoing out $_SERVER['DOCUMENT_ROOT'] gives me 'myAwesomeSite/www' as I would expect. And using $_SERVER['DOCUMENT_ROOT'] in any require() statements actually does include the requested file, so that part seems to be working fine. My question is this: when I use a leading slash ('/'), shouldn't that equate to the document root? I use it at work all the time and it works flawlessly, but on the dev server I have set up here, it's a no-go. Is there another config command that I need to issue to make it work, or am I crazy? Basically, am I missing a setting somewhere that will make this: require_once('/path/to/my/include.php'); work like this? require_once($_SERVER['DOCUMENT_ROOT'].'/to/my/include.php'); *edit* I just realized that I used the wrong slash in the title of this post, but I don't see a way to change the topic title. crap.

Constants and singletons are nothing like global variables. A singleton is a simple design pattern that attempts to ensure that your system has only one instance of the object at a time. You'll still need to pass the object to any classes or objects that need it through dependence injection. And constants are like readability shortcuts - instead of using $errors[404], you'd use $errors[PAGE_NOT_FOUND] where you've previously defined PAGE_NOT_FOUND as a constant that equates to '404'. Unless I'm mistaken, constants are still subject to scope, at least at the class level. This is why, when defining a PDO query return type for instance, you use PDO::FETCH_CLASS or PDO::FETCH_ASSOC instead of just FETCH_CLASS or FETCH_ASSOC. There are many issues with using globals in production code. First, there's the source identification issue you've already touched upon. Where exactly is $myGlobal assigned in a project with 15 directories, each consisting of two to seven classes? Is it even defined within the code you're looking at, or is it defined in third-party code that's been added as a plugin, for example? Beyond that, there's the very real possibility of inadvertently overwriting the value of the global and causing the system to fail in a very difficult to identify and debug manner (see the previous sentences about source definition). Those two alone keep me from using them - I spend enough time debugging random issues because I can't spell worth a darn to spend more poking into the global namespace looking for logic errors that lead to overwritten variables. Basically, you'll find it easier to read and maintain your code if you create the object you need and then pass that object (or the relevant portions of that object) to the classes that need it. If you're creating a helper class - let's say you've created a class that handles a specific type of calculation that your business logic demands you perform on a regular basis, or does table formatting, or whatever - you can instantiate that object and pass it to your controllers from the kickoff script. Or you can make the helper methods static and call them as 'Helper::formatMyTable($tableData);' - this makes it far easier when suddenly your table has 46 columns instead of the 2 you expect. You know to go to the Helper class and look for the formatMyTable() method, as opposed to simply 'fomatMyTable($tableData);' because, in this case, where the heck is the formatMyTable() function?

Replace the line $('#' + v).hide(); with $('#' + v + 'a, #' + v + 'd' ).hide();

It can take some time, but is well worth it. I don't know your level of experience, but if you're getting into PHP OOP, I highly recommend PHP Objects, Patterns, and Practice by Matt Zandstra. And, of course, you can always ask here if you run into any other issues!

<script> $('.button').click(function(){ var v = $(this).attr('id'); $.post('../action/frienddecision.php',{id:v},function(d){ $('#' + v).hide(); }); }); </script> This is untested, but it should work. You'd put another .click() handler within your success function for the AJAX call. So the function will run, but it won't do anything until the button is clicked after the target script is run. You'll also want to check the contents of d to make sure that the function actually processed correctly - the success function in the AJAX object will run as long as the function didn't throw an error, regardless whether or not the process within frienddecision.php actually succeeded or not. So, when the php processes, output a JSON encoded array with an index of 'success' and a boolean indicating whether or not the php did it's job correctly, then you can check that in the success function with something like if(d.success == true){ //hide the button }else{ //pop-up an alert or something }

Personally, I'd take this one step further and make it easier on yourself. Create child classes that extend or implement the class listing above and contain only the code specific to the connection type. For instance, create a class called PDOConnection.php that includes the open(), close(), and mysqlSelectToClass() methods using only PDO-specific functionality. Create another class called MysqliConnection.php that includes mysqli-specific implementations of the open(), close(), and mysqlSelectToClass() methods. Then, the connection class above can do something like this: class Connection{ private $_dbConn; public function __construct(){ if(!class_exists('PDO')){ $DB = 'MysqliConnection'; }else{ $DB = 'PDOConnection'; } $this->_dbConn = new $DB(); $this->_dbConn->open(); } public function close(){ $this->_dbConn->close(); } public function mysqlSelectToClass($query, $className, $args = null){ return $this->_dbConn->mysqlSelectToClass($query, $className, $args); } } That way, if you need to add yet another database choice in the future you can do it without disturbing the current (working) code. Also, you avoid the repeated if-else clauses.

Happens to the best of us - glad you got it sorted!

<td><a href="<?php echo $row_Invoices['download']; ?>" target="_blank">Download Invoice</a></td>

I have to agree with LeJack on this one - taking some time to learn a little HTML, CSS, php, and WordPress is going to help a lot in this situation. The thing about WordPress is that it's great for end-users, but once you start digging into and modifying the code, it's kind of a nightmare from that perspective. The reliance on global functions and variables can make things difficult to follow and really isn't good modern coding, so you should have a decent grounding in php to know when and how to break both php's and WordPress's rules. And no offense, but if you don't know how to assign a class to a DOM element, you're going to be in over your head quickly. The nice thing is, it doesn't take a whole lot of time to learn the basics that you need to know. That being said, you do need to know those basics.

You just add "class='alignleft'" to the <img /> line. The only reason that the class is 'called' for the thumbnail is that the_post_thumbnail() is a template tag and by default outputs the source code, so the theme developer is passing the class name into the function call as one of the optional parameters.

In WordPress, you include style sheets with the wp_enqueue_style() function that you can call using the wp_enqueue_scripts hook. function queueMyStyles(){ wp_enqueue_style('subbranding',get_stylesheet_directory_uri()."/myStyle.css",'site-style'); } add_action('wp_enqueue_scripts','queueMyStyles');

You may have to tweak the height values for the .category-news div to get things placed correctly. Play with different values (or removing the values completely) and see how it looks. CSS is as much - if not more - an art as it is a science.

Don't tie the click to the actual DOM element directly. <button id='button_1' class='button'>1</button> <button id='button_1' class='button'>1</button> <button id='button_1' class='button'>1</button> <script> $('.button').click(function(){ var whichClicked = $(this).attr('id'); alert('Button ' + whichClicked + ' was clicked!'); }); </script> You could also skip the class and use the element selector directly if either there are no other buttons on the page or you want all the buttons to react the same.

Try 'background-size:100% auto;' in the #header-wrap definition.

Wow - just re-read the php manual page and you're right. nl2br() doesn't actually remove the newline characters. I must be remembering incorrectly, or only thought it worked at the time. Hunh...

Ch0cu3r, while I agree that nl2br() is for display, I've had issues in the past with str_replace() not actually replacing line breaks. I don't know if the input was from a Windows machine using just '\n' and I was looking for '\r\n' or if I was searching for '\n' and the input was from a Mac or *nix system that uses '\r\n', or if I was searching for '\n\r' (it was a while ago) but in that situation converting to <br /> and then replacing that with the empty string was the way around it. It did at least give me a consistent string to search for in the string as a whole... Also, asanti - cyberRobot's correct. The data shouldn't be massaged too much beyond validating and sanitizing before storing in the database. You can manipulate the raw data before you output to a variety of media.

You can run nl2br() on $trimmed['description'], then do a str_replace() to replace the '<br />' tags with blank strings.

Check to make sure that the table mccombpo_data exists in the database, and that the file /models/mccombpo_data.php is on the server.

And, allow me to thank everyone. Apparently all I needed to do was shame WordPress into working. Cookie sets and is read now. I didn't change the code.

I did mention it at the end of my original post, but I can imagine skimming by it and I probably should have called it out more. I didn't post in the CMS forum or make more of a deal about the WP usage because I kinda figured it was just me having not used cookies in years and forgetting things as opposed to something WP is injecting or doing behind the scenes. If it's in the wrong forum and a moderator happens to be reading this, any chance you could move it over to the proper location? The first is commented out and won't be run in this scenario. (It is being run in dev because it actually works.) I just left it there because it's identical and does work... I gotta Google it, but am I wrong in my recollection that session variables can't be set after output goes to the browser, same as cookies?

I've only been working with WordPress for about two months, so I'm not sure what it's running in addition to the admin_ajax_* hook, but the output in the console shows only the expected JSON, which is output after the cookies are meant to be set. And wouldn't the session version also fail if there was output prior to the setting of the variables? I hadn't thought about checking the error log (duh) so thank you for the reminder!