gizmola

Integrate what? The PGP method or the "store to a database method".

You need to provide more information other than "it doesn't work."

Probably the names were changed because there should be an intermediary step where the raw values were "cleansed" to insure that they didn't include anything malicious like javascript code.

I'm not sure what you want help with here, since you've cribbed code from other places, and you really haven't provided any clear questions, or pinpointed any problems, or provided debugging info. With that said, I can make a general observation which is that php is not generally a great language for writing a socket server or even a client. It's strength is running as a cgi or apache module and serving web pages. People typically write their socket servers in something leaner -- c/c++, perl or python are more commonly used for this, and of course you can do it with java. Of course if you are going to do it in php, then you're going to run it using the cli version of php. Now to the more specific, and since you brought it up... you do realize that if you setup a socket server, and it's bound to localhost (127.0.0.1) that is not a public interface, so no processes that are not running on the same server are going to be able to connect to it? The other thing you would need to do to the code you presented is actually implement the chat protocol. Your client seems to be sending json and expecting the same, and your socket server application doesn't look like it has any json send or receive logic in it.

You need to provide more information. If you are moving your site from one host to another then you need, both a database backup of the joomla database, as well as a full tar/gzip or zip of your site. The k2 plugin comes with support for an image gallery that is provided by the same development firm that wrote the k2 extension. It just so happens that I reverse engineered the k2 database, and wrote about this: http://www.gizmola.com/blog/archives/102-Joomla-K2-Component-ERD-Schema-and-Tree-traversal-optimization-with-Catalog-Mode.html If you look at the schema you'll see pretty quickly that k2 doesn't use blobs, so any images are going to be stored on the file system.

I'm stumped. You have an article with php code and structure that shows you how to implement the algorithm and do various things. Then you show us snippets of code, with no context, when the entire point of these algorithms is for bending a relational database into supporting hierarchies using tables. You didn't show any schema or any queries. Who could possibly guess what your problems are from a bunch of array variables that were defined and loaded somewhere else.

It sounds to me like there are two concepts you should explore: abstract classes and interfaces. An interface is basically a list of method signatures that must be implemented by any class that is declared to "implement" that interface. In your example, rather than having all the plugins extend a class, it might make sense for them simply to implement an interface of methods that they need to to support. Since you know that they will not work unless they implement all the required functions in the interface, you can know in advance that you can manufacture and work with any of those objects via their public interface. With that said, because you can not define in advance a return parameter, there is plenty of ways that things could go really wrong, but then that is the nature of a loosely typed language like php. The other possibility is to start with an abstract class. Abstract classes are similar to interfaces in that they have a basic signature of methods. What is different from an interface, is that the abstract class can have non abstract methods in it. You can not instantiate an object of an abstract class with new, so it's really meant to be a common ancestor. You declare any of the methods that you intend to have overridden in the plugin classes to be abstract, and then those abstract classes are expected to implement them, so again you can write code that calls those abstract methods, knowing that they will be available.

You can insert all the rows for the update into a temp table, and then join the temp table to the status table with an inner join on whatever key you're using to identify a status row. This same table can be used to outer join as the basis for a result set that shows you which rows need to be processed as inserts into the status table because they don't exist yet. The other possibility is to write an insert trigger that would allow you to do the more advanced processing needed on inserts. Since you describe this as an exception, a trigger sounds like a good solution, and if you were using a database like Oracle, would probably be the recommended solution to a problem like the one you describe.

My suggestions: - Put every class in its own class file, named using a convention where the file name matches the class. One convention might be: classname.class.php, so class Login ... would be in the login.class.php script. With a convention like that you can implement a simple autoloader if you don't want to manually include every dependency. -Yes declare all your class variables and scope them as needed. There is very little reason to have variables ever be public -- you have private and protected not to mention static and even constants that you can declare. -Don't overuse exceptions. Exceptions should be for issues that are truly unusual, like database errors. Someone supplying a login form that is missing the password or username is not what I would code in an exception. The frameworks for the most part have form classes, with widgets and validators that give structure to that type of code, and a login form is no different than any other type of form. Those are rules that should be built into a validation routine for the form. Just to nitpick further, where you put the LoginException in your routine is ill advised, because you already attempted to query before even checking those conditions. A long time ago I was a developer for a system that had its own custom database engine, and the entire operation was at a standstill because the system seemed to be broken. As it turned out, there was code very similar to what you were doing, where a query would occur with blank or empty values, and what I eventually uncovered with a debugger, was that a blank/empty row had gotten inserted into the database. When the queries would occur, any blank column would cause the blank record to be retrieved, so everyone thought the system was corrupted and broken, because they were always getting a blank screen when they searched.

We had a long discussion of this not too long ago, and there is simply no good way to do this that doesn't require an insane amount of infrastructure, administration and setup. A far simpler and logistically feasible scheme: - Store the data in a database. (Since you're accepting CC info, this form should be submitted under the protection of https://). - The script can optionally email you a link to access the new entry, but this link should not allow you to actually see the information without first logging into it. - Access these entries via a password protected page that is only served under https:// Ok, so to get it out of the way, here's a way to do it with email, using PGP. http://www.pantz.org/software/php/pgpemailwithphp.html Again the last time we talked about this, the person was stymied with the requirements involved in getting PGP installed in their email client, and getting the PGP key ring and environment setup on the web server, but if you really want to do it, this is the type of method (Public Key/Private Key crypto) that you would want to use.

Haa, I'm not sure where that work though -- maybe at the high school science fair?

PHP 4.x is dead, kaput, end of life. Nobody should be writing code for php4 or considering any framework that was built on it, in my opinion. Right now, the best 2 frameworks for PHP (both of which were written starting with php5) are Zend Framework and Symfony. I have used both for projects so I can speak with experience on each. Symfony has some excellent documentation, and is highly focused on productivity in the same way that Ruby on Rails was designed for productivity. It comes with an extensible automation system that generates your databases, models and base forms, and supports two of the best known PHP object-relational mapping (ORM) libraries - propel and doctrine. It can also be used to generate admin/CRUD screens and has a plugin architecture and a number of plugins that provide advanced capabilities like sophisticated user/group permissions, or drop in image thumbnails. The company that supports it uses it for their own projects, so they're continually improving it, and have even done a ground up rewrite that takes advantage of the oop improvements and features like closures in php6. Symfony does force things like yaml files down your throat and some of the "configuration rather than coding" philsophy can be intimidating, when things don't work the way you want them to. People have the same complaint about Ruby on Rails. Zend framework is more of a massive programmers library, that focuses on the implementation of solid design patterns, but doesn't commit you to any particular approach, so in that way it attempts to be both a framework with an mvc implementation as well as a library of routines that support nearly anything you can think of. For example, you can easily pull out one class (the view class for example) and drop it into your application. That's not the case for other frameworks. Every piece is highly decoupled and independent, which depending on your point of view is either a great benefit, or incredibly over-engineered. I think that if you're already a real expert both in PHP and in common design patterns like MVC, you might find it liberating, and some of the features like the form validation system is really inspired and amazingly powerful. I have nothing against CI, cakephp or Kohana as nearly all of them have solid communities, but the same could be said of Joomla and Drupal. Often they argue that they are "faster and leaner" which really means that they don't do that much and offer little to no flexibility if you have a need that goes beyond what they do out of the box. The internals are also basically pure php4 oop, with minimal changes. I commend the CakePHP team for realizing that they needed to rewrite from the ground up, because design patterns are a product of OOP, and you need the features that were added in php5 and 6 to really do those design patterns justice. For anyone who is a beginner-to intermediate developer, you're going to find that a framework is a challenge to learn. The best way to make this decision is to make a small test app in each and see which one appeals to you. Currently I'd advise that decision to be focused on symfony or ZF, and for most people, Symfony will be the one that's easier to learn and become productive in faster. Zend is more of a programmers library.

Most people challenge themselves by learning a new language or platform. Do you know flash/actionscript? Could you write a side scrolling game? How about Ruby or Python? How about Objective-C coding for the Iphone/Ipad? Are you an expert javascript developer? Can you really get around in photoshop? Your work may be repetitive but there's no reason you can't explore other areas of programming outside of what you're doing now.

The geek factor is high in this thread.

Your preconceptions are highly flawed. MySQL is in general optimized for select and insert activity. A select is always preferable to an update, and in fact there is nothing that reduces concurrency more than update activity, since it has to place a write lock on rows, indexes and often the table itself. I can't imagine what your application is that would throw away inserts, but be interested in "non" updates to rows. Last but not least, updating a couple of hundred rows shouldn't be a big deal unless this is a significantly large database, and again, updates reduce concurrency, but should allow reads to continue unless the entire table is locked.

You are not seeing the forest through the trees of all your esoterica. Of course it only updates one row, because your query syntax is badly flawed. The only reason you don't update ALL the rows in your table with the same values is that you have added the LIMIT 1. What you are missing is a WHERE clause. What your UPDATE state should be is: $sql="UPDATE movies SET Category = '$_POST[dropdown]' WHERE id = $_POST[dropdownt]"; Now the only way this is going to work is for you to actually understand and fix that dropdown, which needs to have both the movie id (for the dropdown value) AND the title. Why didn't that work you asked? Because your query didn't include the id in the select list. You had $query = "SELECT Title FROM movies WHERE Category='1'"; That query should be: $query = "SELECT id, Title FROM movies WHERE Category='1'"; And below you go back to building an actually useful dropdown, where you display the title but set the value to be the id of the movie row, so the query knows what row to update. echo " {$row['Title']}";

Ok, so did you actually read the link that mjdamato provided, down at the bottom part, where he shows how he sets the include path using ini_set() at runtime? That code shows how the author sets up an array with a number of different paths. He then uses an __FILE__ derivation to get the basepath for his application and sets up all the directories he wants to have in the path. The code then calls ini_set('include_path' ...) to change the default php include path to instead search the directories he wants searched, which are all the directories for his application (and this is what you would setup to match your application instead). As for the config file... that is just a convention that people typically use. They do configuration in this file, and it's included in all subsequent files, either explicitly or via inclusion in a frontend controller script that is the only script that is every called directly, and is responsible for controlling the flow of the application.

Read this.

At this point I don't really understand what problem it is that you are trying to solve, so we're speaking in vague generalities. You keep bringing up the php.ini file. I guess I assumed that you understood how that works but perhaps you don't. It configures php, is a static file that gets shared by all php processes, and typically can not be changed without superuser access. If the install is on shared hosting there is *no chance* that this file can be added to or changed. Any changes made to it require that the *web server be restarted*. I have never seen a single major php application come with the instructions to add or change the php.ini file. Some of the variables set in the .ini can be changed at runtime. This is the key to making the scheme work that has been presented in allowing you to setup your application structure, and then append to the front of all the relative paths, the base path section you derive from the __FILE__ constant. Again you would do this in a routine that would be called in your frontend controller script. If you aren't using a structure that has a controller script, then I can only advise you to take a step back and look at what you're doing, and ask yourself why you are not using the design pattern that nearly every quality application package or website uses. Even if you don't see how you make this work, I have to assume that you have a config.php file that you load somehow in every script. If you're using sessions, database connections, etc, you have to load up these routines. The call to __FILE__ can be done in the config file, and you can set your BASE_PATH constant that way. You do not have to use the include_path and can simply have every include and require append the relative path of those files to the BASE_PATH constant. As for the __FILE__ constant, like most of these concepts that you don't seem to understand, I can only recommend that you experiment with them by writing simple scripts until you understand what they do. We have also talked multiple times about the php include path. Do you understand what it does? If we're not on the same page, or there's a misunderstanding on your part, we have to get to an understanding of that if we're going to help you, because we keep providing and restating a solution to what your original question seemed to be, and you keep stating that you don't see how it can work. I don't really feel I need to justify my answers, due to the thousands upon thousands of answers I've provided, but having invested some time trying to help you out here, if it makes you feel better, I've developed hundreds of websites visited by millions of users, not to mention having contributed to a few open source projects. Some of those sites were for the Red Hot Chilli Peppers, alanis morrissette, Jerry bruckheimer films and scores of others I won't mention, so there's no question of whether this stuff works because I do this type of development on a daily basis. At this point I'll just leave it to you if you want to pursue specific questions.

I should probably add, that having margin, padding, alignment and font consistency is what you want to aim for here. Reduce your site back to its content, with simple markup around the elements: h1, h2, h3, div tags, p tags, ul's, anchors and img. Then start adding styles back in, and your site will transform into one that is consistent and looks professional and modern.

A really simple approach to this that I recommend to people in your situation is to create a simple controller script. You should call this script index.php. That script becomes a junction box for your site that takes a single parameter and then loads the appropriate content using include. The entire thing is based on a single case statement. Here's what I would recomment for you: -create a header.php file. In this file stick your valid html doctype, your head and title and anything else you want like meta keywords and description. Load your main .css style sheet. This might be the only one you have in a simple site, although you willl also be able to load individual style sheets for each page in the index.php. This file can start your body and usually people have a div that contains an actual header for the site, with logo and sometimes a top navigation. It's considered good practice to have a top nav and a menu nav, and a lot of people also repeat the nav in the footer. There's lots of tutorials on how to create an attractive menu using pure css, usually with an unordered list for the markup. - create a footer.php have a footer div here, and any copyright or similar info you want, and many people also repeat their menu. -menu.php have a div and markup for your sidebar menu. -index.php This is your junction box. It includes the header.php, then sets up a main div. If you want to stay with the basic structure you have, then have a $page = $_GET['page']; require_once('menu.php'); switch ($page) { case 'president' : require_once('president.php'); break; case 'clubinfo' : require_once('clubinfo.php'); break; ..... a case for each page. case 'home' : default : require_once('home.php'); } require_once('footer.php'); Now you simply make a php script for each page on your site, and your navigation url's should always be: ?page=president or whatever you have for each page in the navigation. This scheme is conducive to adding a simple mod rewrite rule so that you can have the navigation omit the 'page=' so all your urls would be seo friendly: www.yoursite.com/president www.yoursite.com/weather etc. Here's a link to a clearly written article that shows you how to implement a 2 column css layout: http://www.456bereastreet.com/lab/developing_with_web_standards/csslayout/2-col/ Now you have pretty much everything you need For inspiration you might want to look at http://www.csszengarden.com/ Every site you click on in the right hand side uses the same markup file. The look and feel (style) of the sites is all done using css with some images included as background elements. They can not change the markup, so you'll see that incredible things can be done purely in the .css stylesheet.

Just to go back to what I previously wrote -- and to mjdamato's code, you already saw the __FILE__ constant that helps all this work. All it needs to do is set the base path based on where it is running from, which is an automagic PHP feature: "Oh, the application is running from *here*". One other thing I want to point out is that the most difficult thing to deal with in PHP application installation is permissions. There is no way for an application to do things like make directories and copy files without the right permissions configured. So while you can strive for a zero configuration install process, you'll never truly achieve it. Installers like the ones that come with Joomla, phpBB and other popular packages often will attempt to check permissions, and alert the user if they can not be set as needed. Most packages are distributed in zip/tar-gzip'd files for this reason -- it makes sense to just have the application structure installed when the file is unzipped or untarred, and then you have a setup script that will do some configuration like the permissions checking, and storing of database user/credentials if that is needed. Those values are often written into a config file, but again, if the permissions don't allow your script to write those values out, there is nothing you can do other than to present the user with the values they need to set, and instruct them to create the file manually.

Hello 1997! To Ignace's point, that is a very dated design. I'd suggest an immediate revamp where you lose the marquee (really annoying) and the frames structure. Work up a new design using html and css and start to port your site over to that.

I don't see how globals comes into it. You showed us a snippet of class code that is apparently setting up some class internals. "$this->" indicates "this object", so it's code that calls a "loadClass" method that is part of the class definition.

Most web applications these days are built around the Model View Controller (MVC) design pattern. In this pattern you have a front controller or bootstrap script that is the entry point of the application, through which all other scripts run. You might want to take a look at some of the popular frameworks, like Zend Framework, Symfony or CakePHP to get an idea of how you can implement this. As for "knowing the environment" there is no need to know it. Your application only needs to know and setup its structure, and to set the include path using ini_set() in a manner similar to the one described in the link mjdamato posted.