maxxd

Are you trying to pass values between forms on different pages? If so, submit the first form and use PHP to grab the value before building the other form on the second page. If you want to move the value into another form on the same page, just change the JQuery target.

Define "won't work". The most immediate thing that I see is that it doesn't look like you've matched brackets on your if/else statements. It's difficult to tell, as the indentation is completely out of whack, but that could be the board doing that.

When you say you're 'using Dreamweaver', are you using it as a code editor and coding manually, or are you using the wizards and automated code generator?

You're missing the semicolon to end the call to the function at line 729.

Things like database connections, configuration files, and ... well, honestly any functionality file, be it a class or function sheet, should be exactly where you put it. The idea of a database connection file being in one of two places is a bit scary - that means it could be within the webroot, where it's viewable under the right circumstances, or it could be above the webroot, where it's not. And - most importantly - your application doesn't know which it is. Needless to say, above the webroot is better. How it's accessed from there depends on your system - if you're using a front controller pattern with a routing system, for instance, everything is going through a single entry point - index.php in the main webroot. From there, you always know where your includes directory is ('../includes/'). If you're using separate files for each page and serving them from within separate directories, then you'll have to do a bit more calculation to get it. However, if you're still using this style, you're probably duplicating a bit of code and content already, so it shouldn't add too much to your current overhead.

The logic flow of your script is correct. However, right now it's wide-open to several different types of attack. You're using MySQLi, which is a good start - look into using prepared statements. I'm also questioning your logic on the connection script include - at what point would it not be where you expect it to be (one directory up), and if it's not, how do you know it's in the current directory?

Use PDO. It's easier to handle, and you'll be less likely to mix and match with mysql_* as Barand pointed out. As benanamen stated, you're inserting user-supplied data directly into the query, which is not only a bad idea, it's completely missing the point of using either mysqli or PDO - use prepared statements. (Here's the PDO version of prepare()).

You're not passing any data other than 'action' to the php script right now. Gather whatever data you need and pass it along with action in the data parameter of the ajax object.

Start here. Basically, you write your php script that validates and sanitizes user-supplied data, runs an update on the database with that data, then prints a JSON-encoded result string - this script is a separate file on the web server from the file you're using to display the task list. On the task list display, you'll set up a .click() event on the completed button that will create the AJAX request, gather the record ID to be updated from the displayed page (usually a data-* attribute on the button), send the data to the php script, then read and parse the return string to see if the process was successful or not.

@greenace92 - that's just my own personal preference (and bias, quite honestly). One of the things I like about OOP is the ability to black-box functionality. A class's public property can be changed from anywhere, whereas a private property can only be modified from within it's own class. So, if I write this: /** * @var string|null description */ public $myInteger; /** * class constructor */ public function __construct(){ $this->myInteger = 2; } /** * yadda yadda */ public function multiplyIt($yourInteger){ return $yourInteger * $myInteger; } and call echo $myClass->multiplyIt(4); I get 8. If I do this, on the other hand $myClass->myInteger = 'This is a test'; echo $myClass->multiplyIt(4); I get an error. And if the reassignment of $myInteger happens in a section of code nowhere near the call to multiplyIt(), the actual source of that bug takes forever to track down. However, if $myInteger is private, any attempt to directly reassign it will throw an error at the reassignment attempt, and you know exactly where the bug is. Taking it a step further, if I create a setter method, I can then test the input value and reject or modify it if it's not an integer, thereby avoiding the whole issue.

@ginerjm - this is probably a bit off-topic, but do you typically write OOP or procedural code? I ask only because I find it interesting that you use a leading cap on functions, while I use leading caps for class names only. No big deal, just interested.

My tastes run to a combination of modern "best practices" and old-school practices that I got used to while learning to code php many, many, many years ago. namespace Example; /** * Description. * Further description * @param string $varName Description * @return void|boolean Description */ class ExampleClass{ /** * @var string|null description */ private $_myVar; /** * @var string|null description */ public $notAGoodIdea; /** * Description. * Further description * @param string $varName Description * @return void|boolean Description */ public function __construct(MyOtherClass $class){ $this->_myVar = $class; } /** * Description. * Further description * @param string $varName Description * @param MyOtherClass $varName * @return void|boolean Description */ public function exampleOutput(array $test, \StdClass $class){ $test['newInput'] = 'This is an input'; foreach($test as $t){ $loop = $this->doIt($t, $this->_myVar->aMethod($class)); } return $class; } } I indent using tabs and keep the opening brace of methods and classes on the same line as the definition statement, and use camel case for method and property definitions. I also still use an underscore on my private variables, a practice ingrained in me during php4 programming. Admittedly, it's gotten me into some trouble as I'm now working mainly with WordPress, and this isn't at all the style they recommend and code to. Also, I tend to think getters and setters are the way to go, so my name for the public variable - while showing the style I would use - might be a bit biased. In my experience, potential employers can and usually will overlook things like opening brace placement, white space within parentheses, and private property naming quirks as long as the code is readable, variable names make logical sense, indenting is logical (as ginerjm mentioned, anything within curly braces should be indented one additional level from the parent code) and consistent, and the code is documented. Unfortunately, this last one is not as important to some as I believe it should be...

Two options: $file = 'otoole.desmond.caferoyal.pdf'; $fileNameArray = explode('.',$file); $idx = count($fileNameArray) - 1; print("<p>Count:</p><p>".$fileNameArray[$idx]."</p>"); //a little wordier, but possibly easier to read print("<p>End:</p><p>".end($fileNameArray)."</p>"); //quicker, with less typing This will return the file extension, assuming no one adds another dot and characters after the .pdf in the file listing.

You're trying to grab the data-id attribute from a div that doesn't have that attribute. Try changing dataId: $('#myModal').attr('data-id') to dataId: $('#myButton').attr('data-id') I'd also recommend printing the dataId value to console in Javascript before you submit the AJAX request, then again in PHP to make sure the data you're getting is the data you're expecting. Beyond that, mysql_* is deprecated and removed from PHP 7, which should be released soon. You need to be using PDO or MySQLi as a DAL nowadays.

Your group by is still in the wrong spot. Move it to after the WHERE ... AND clauses. You should be getting an error when you run the query in PHPMyAdmin.

Looks good - glad you got it working!

Sorry - I've got nothing for Artisteer...

What theme are you using? Looks like it may be reading the class name to replace an input type. For instance, the classes you listed are 'ab-select'mobile' and 'ab-select-services'. Notice that both have '-select-' in them - maybe that's what the theme is reading? Without knowing the theme, that's only a theory. It may be a bad one, but it's a theory.

Give this a shot as a starting point - https://jsfiddle.net/guzfmfuw/

Ahhh... Well that explains why I was very confused just now when there were many more posts than I remembered!

Is there a reason you're doing it this way and not just JSON encoding the entire multi-dimensional array? Seems like it'd be easier on both the encode and decode phases if there's not a specific need for this format (I'm assuming you're going to explode the arrays later for use somewhere...).

If the project is still early in it's development, I'd highly recommend switching to PDO (my choice) or MySQLi, because (as already pointed out), the mysql_* functions are deprecated and removed in version 7, coming out sometime in the near-ish future. You'll find plenty of documentation on both classes in the manual, including come ideas about best practices.

The problem with that is that you said all the database connection details are in header.php, so you're not going to be able to run the query before you include the header, which is where you define the database connection. You're going to need to do some refactoring. What does the file header.php look like?

You're not actually querying the database in the code you've posted. You can create a new WP_Query object, or use the get_posts() function, like so: $posts = get_posts($args); // or $qry = new WP_Query($args); var_dump $qry and you should see your posts.

Try using flexbox layout. If you're using .less, this can help with any necessary backwards compatibility.