requinix

How can you be testing it while it's offline? The problem is while you're accessing it externally... To be sure, because something's not adding up here, Apache's access log shows your (external) request and that it returns a 404?

Are you looking at the HTML source of the page? Or just what your browser shows you?

If it's definitely in the URL (confirm with $_SERVER["REQUEST_URI"] or $_SERVER["QUERY_STRING"]) then it should also be in $_GET. Knowing about the web server would be very useful for this.

You made it a requirement that there be an entry in archive_expiration for the user/project pair with WHERE `t5`.`userid` = '599zxj'I'm not even sure why you need that table in the first place? It only seems to be used to limit the data returned, and it limits in a way you don't want.

What URL are you using that gets the index page? Does it have the same domain name as one of those two hosts you have configured?

No more good can come from this thread.

I'm a little lost in your second reply but it looks like what I suspected: you have a third virtualhost which offers www/ (or whatever it actually is) as the default host. You should either 404 everything, or better redirect to another site. Then the indexing problem is moot.

Without reloading the page, you mean? That's AJAX, which is simple to implement... except for doing file uploads. Which isn't actually AJAX but whatever. Find yourself a Javascript library that can do file uploads and implement that in your site. Your PHP doesn't have to change much except it shouldn't output HTML (not when it's handling the file upload).

My strategy with imports is to import data into a table dedicated to importing. Nothing else but a database copy of the (in this case) CSV file. When that's done you can run whatever queries you need to get the imported data into its rightful place. I think you should have a TRUNCATE TABLE followed by an INSERT...SELECT.

If you're going to overwrite the IDs then it sounds like you shouldn't be using auto_increment in the first place... Truncating is removing all the data in the table. It doesn't make sense to truncate a table and leave a column behind. Do you mean to fill all the other columns with NULL? Why bother keeping the IDs when you overwrite them (in some other code, I assume) later?

Mind sharing?

Do you get an index of www or of the two directories individually?

Good question.

Taking "procedural code" to mean the typical file-as-a-functional-unit approach to PHP, People who write horrible procedural code will write horrible object-oriented code too. Makes no difference. Meanwhile SQL injection is completely unrelated so that argument means nothing. Procedural code teaches (hopefully) good coding practices that will bleed into object-oriented code too. So it's worth it. For example, separation of logic and presentation is particularly important in procedural code, drilling in the concept so it will be familiar when they eventually come to object-oriented code (notably MVC).

$admin is an array. It doesn't make sense to compare a string to an array. You want in_array.

You're using simplexml_load_file on a string. There's a similar function that you should be using instead.

Then I misunderstood. Nevermind. Yeah, that's what I'm getting at: having to add a new method every time suggests using a different coding strategy. Then vice versa: the parent can't possibly have a "yiddish" method because jQuery doesn't, but a subclass could. Either the parent will have the method and the children shouldn't, or a child will and the parent shouldn't, but both won't have it. That would be a third method to add to the interface: a way of serializing the requirements or behavior or whatever. Preferably you'd stuff some information into an object and then code can serialize (via the JsonSerializable interface and json_encode(), for instance) the class's data into the Javascript. It's describing what I did in the first bit of code: one class (PhonenumberValidator) per type (a phone number) that implements an interface (IJqValidator). You could have another class (EmailValidator) per type (an email address) that implements the same interface. class PhonenumberValidator implements IJqValidator { // lowercase 'n' public function validate($value) { // US number: 3+3+4 = 10 digits // as a courtesy, strip common separators transparently. sanitize() will remove them again later $value = preg_replace('/[-(). ]/', '', $value); return ctype_digit($value) && strlen($value) == 10; } public function sanitize($value) { // strip everything but numbers return preg_replace('/\D/', '', $value); } } class EmailValidator implements IJqValidator { public function validate($value) { return $this->sanitize($value) === $value; } public function sanitize($value) { return filter_var($value, FILTER_VALIDATE_EMAIL); } }

Okay, but why are you using the subclasses to add methods? Overriding makes sense, sort of, with a validation class giving one implementation to a method and the sanitize class giving another, but they shouldn't be adding new methods into the mix. Your strategy is to model jQuery so as long as you do that then there shouldn't be any problems: the parent class will use methods with the same name, and the extending classes can't be adding new methods with the same names because that then wouldn't match the jQuery interface anymore. If you really do need to add methods, meaning that (for example) the base class can't validate phone numbers and you want to add that in with another class, then you have two options: 1. Add actual methods using traits. You'll define the functionality in one place, "add" it to the base class, and it will actually be executed as a real member of the base class. This is pretty much only about code reuse. 2. Make the code look like there are methods by using... I don't know the proper name but my boss calls it the "driver pattern". The base class transparently uses specific classes to provide the functionality that it seems to offer. More on the latter because that's what I think you're trying to get: Validation and sanitization (and whatever else you may want to do) is provided by one class per type. One class covers phone numbers, one class covers integers, etc. It then implements a "validator" interface which declares methods for validation and sanitization (and whatever). interface IJqValidator { public function validate($value); public function sanitize($value); } class PhonenumberValidator implements IJqValidator { // lowercase 'n' public function validate($value) { // validate the phone number } public function sanitize($value) { // sanitize the phone number } }Your base class then goes hunting for that class when needed. class JqValidator { private static $validators = array(); private static function getValidator($type) { if (!isset(self::$validators[$type])) { // $type="phonenumber", $class="PhonenumberValidator" $class = ucfirst(strtolower($type)) . "Validator"; self::$validators[$type] = new $class(); } return self::$validators[$type]; } // the implementation here could go a few ways // 1. ->validate(type, value) public function validate($type, $value) { return self::getValidator($type)->validate($value); } // 2a. ->type->validate(value) public function __get($name) { return self::getValidator($name); } // 2b. ->type()->validate(value) public function __call($method, array $args) { return self::getValidator($method); } // 3. construct the class with a mode, validate/sanitize, and then use ->type(value) const MODE_SANITIZE = "MODE_SANITIZE"; const MODE_VALIDATE = "MODE_VALIDATE"; private $mode = ""; public function __construct($mode) { $this->mode = $mode; } public function __call($method, array $args) { switch ($this->mode) { case self::MODE_SANITIZE: return self::getValidator($method)->sanitize($args[0]); case self::MODE_VALIDATE: return self::getValidator($method)->validate($args[0]); } } }I personally don't like #2 or #3 because there's no autocomplete support and I have a philosophy that if I can't get IDE support for something then it is probably a bad idea and needs to be done differently. Fortunately, I'm guessing that #1 wouldn't be a problem based on how I think you're using the rest of the code.

Keep in mind that the developer of the child class has to know about the parent class. You can simply push the "having to worry about conflicting" stuff onto the developer; as long as the parent class is locked down, make them figure out how their class should work. This task thing... can you explain it more? I feel like there's a better strategy to deal with it than creating more and more methods in a child class. Personally I avoid any situation where a parent class needs to call a specific, unknown child method without the child class somehow describing itself to the parent (eg, reporting that it has additional tasks 5-7).

Kinda depends how you want to model the behavior, whether you'll want to alter the child later, if these decorators simply pile on more layers of HTML, that kind of thing. If I were doing it I'd probably have a simple class for an HTML element: tag name, arbitrary attributes, and child elements. Then a special sub-type of element representing just text. The "label" would start as the text element, then the Label decorator would take the element received and add it to a new element and return that. The Div decorator would also take the element it receives and wrap it in a new . #text -> #text -> #text

Abstract classes are the exact same thing as regular classes but with two differences: 1. You can't instantiate an abstract class (but you can instantiate its non-abstract children). 2. Any non-abstract class that inherits from it has to have abstract methods implemented. That doesn't have to be in the class itself but it does have to happen somewhere. abstract class Animal { // this class doesn't know what type of animal it is // child classes are supposed to implement it public abstract function getAnimalType(); } abstract class Cat extends Animal { // this class, and any child class, is a cat public function getAnimalType() { return "Cat"; } } abstract class Dog extends Animal { // dogs can bark but not all dogs bark the same way public abstract function bark(); // this class, and any child class, is a dog public function getAnimalType() { return "Dog"; } } class EnglishDog extends Dog { public function bark() { echo "Woof"; } } class ItalianDog extends Dog { public function bark() { echo "Bau"; } } class SpanishDog extends Dog { public function bark() { echo "Guau"; } } To your code: Every shape: 1. Has area but not all shapes calculate the area the same way. This should be an abstract method in Shape. 2. Has a perimeter but not all shapes calculate the perimeter the same way. This should also be an abstract method in Shape. The Shape class itself should be abstract for two reasons: 1. It has abstract methods so you must make the class abstract. Fortunately that makes sense because... 2. Everything that you would consider a shape is more precisely a type of shape. That means subclass. It doesn't make sense to have an instance of Shape itself. Triangle should extend from Shape (it's a type of shape) and can implement the getArea and getPerimeter methods. You could make subtypes of triangle, like RightAngledTriangle or IsocelesTriangle, and put the code in each of those, but they actually all have the same implementation so it's better to put the code in the parent class (Triangle) instead. Abstract classes share some of the power that interfaces have: you can write code that uses Shapes without having to care about what type of shape it is. Without the parent Shape class, if you wanted to deal with Triangles and Squares then you'd have toa) Write a bunch of methods, one for each type of shape. If you added more shapes in the future then you'd have to add more methods. To call those methods you'd have a bunch of logic somewhere that says "if it's a Triangle then call method A, if it's a Square then call method B, if it's a Circle then call method C..." and that is a nightmare to maintain. b) Write one method that handles all types of shapes. It's nicer in that you have only the one method, but that method can't use typehinting because the various shapes don't have a parent class in common. So then you'd have to check that the value passed was an appropriate type of shape (with the same kind of "bunch of logic" as above); if you blindly called "->getArea" on whatever you received then anyone could pass any type of object so long as it had a method named "getArea". It's a trivial example but function whatIsMyArea(Shape $shape) { echo "The area of this shape is ", $shape->getArea(), "\n"; }1. It enforces that every value passed is a Shape (or subclass of Shape).2. Since you know it's a Shape, you also know that it has a getArea method you can call. 3. More logically, you know that the function was passed an object representing a shape and not, like, a "user" or a "car" or something unexpected. You can't get that kind of certainty unless you (a) use Shape or (b) write a lot of code.

Even cooler would be to use interfaces: you can pass the entire object as an argument and the receiving code knows that it definitely has a specific method on it that can be called. If that makes sense in your situation - I'm not sure if it does since there's not much code, and the design is a bit weird.

Namespaces? Something else entirely. Ever had a set of classes that are named similarly, like db_user/db_post or DatabaseUser/DatabasePost? You could use namespaces to help arrange the classes. Before: class db_user { } class db_post { } $user = new db_user(); $post = new db_post(); $user->post($post);After: namespace db { class user { } class post { } } namespace { use db\post; // so you can refer to it as "post" for short $user = new db\user(); $post = new post(); $user->post($post); } To your problem, final is exactly what you should be using.

Same question as over here.

The value isn't actually the string "NULL". It's the value null itself. Forget the elseif and just do if( $row["$m_primeID"] ) { $company .= "<b>Hours of Operation:</b><br>" . ($row["m_coupon_title"]) . "<br /><br />\n"; $company .= "<b>Special:</b><br>" .($row["m_coupon_desc"]) . "<br /><br />\n"; }[edit] And I doubt you mean to use a variable $m_primeID...