gizmola

What do you want us to do for you? It's outside of the scope of this forum to modify a commercial scripting package (phprunner) assuming such modification is safe or advisable. It sounds like you're an end-user and not a programmer. I'm by no means trying to run you off, but this is a community to help programmers, students and hobbyists, and even business people who are trying to modify existing code. With that said, you have to do the heavy lifting -- otherwise it's just programmers doing work for people for free, which is not what this forum exists to do.

Pretty much what fastsol said -- this is what session variables are made for. When the user selects those drop downs, you set them up as session variables. Then have your subsequent scripts include an include file that has simple code like this at the top: session_start(); $category = isset($_SESSION['category']) ? $_SESSION['category'] : 'Some default';

Just for comparison here are a couple of good/heavily used validation libraries to compare and contrast yours with: https://github.com/symfony/Validator http://framework.zend.com/manual/2.2/en/modules/zend.validator.html

The class has a private variable $_errors which is an array where error messages are added when validation fails. Private variables are only visible inside an object of the class. They can not be seen or accessed outside of the class itself. So for that reason the class has a class function errors() that returns the contents of this private variable. This is why the code you have should theoretically work: if ($validation->passed()){ echo 'passed'; } else { foreach ($validation->errors() as $error){ echo $error, '<br>'; } } Your code was missing the end block but I assume that was just a copy/paste mistake. The problem with the code you provided is that I don't see where the $_passed variable gets set to true, but I will assume that it actually works somehow, perhaps by checking the contents of the $_errors array? If that's the case, there is no reason for the $_passed class variable to exist from what I can see. Doesn't seem like the best validation class?

In your list of columns, you don't include MessageDate, however you pass the date as a parameter in the values. You also have some bind variables in there with some regular values. You should only have the bind variable names. $userid, :recipient, :subject, :cc_email, :reply, :location, :stationery, :ink_color, :fontchosen, $messageInput, :attachment, $date $userid, $messageInput, $date --- these should all be bind variable names, not the variable values.

Hey Tony, Yes, I didn't want to get into all that backward compatibility crap, as I think it only adds to the confusion, so I left it out. You make a good point about the plugins location, and I have to assume that a "composer supported" cakephp would need some special configuration that would add its directory to the number of searchable paths. I know that you and I are in agreement that we avoid the old pre-5.0 frameworks like Cake and CI, and I never cease to be amazed by the fact that we seem to get more questions about them then we do about any of the frameworks we actually like and use.

Hi evansste, Security is a very complicated subject. In my experience, and unless you have some enemies out there targeting you, it's highly unlikely that someone would spend the time to try and exploit your specific site. Most attack vectors are automated, and the exploiters are not interested in your specific system. Typically exploits attack some known weakness of the operating system or a specific package you might be running like wordpress or joomla or phpbb. Scripts you run that you otherwise don't understand would be the most likely culprits. You currently don't have enough information to even determine that your password was changed. That's an assumption that could be entirely incorrect. We could all conjecture until the cows come home, but I find it unlikely that someone would exploit your site with the specific goal of changing your mysql password which only serves to tip you off that something has changed. Really, your specific hosting setup is the first thing someone would need to understand. There are bad shared hosting setups for example, as alluded to previously, which make it easy for someone on the same shared host to read all the files in your webspace, but I find it hard to believe in 2014 that there are too many shared hosts who still run those types of setups. For the most part, they implement fastcgi and insure that the apache process(s) run as your user, so that those types of "trusted user" exploits aren't possible anymore. For all we know they had a blip in their setup or someone screwed something up so that you can't attach to their mysql server as the same user anymore. If you did have a sql exploit, they might also have dropped your entire database (if it's an especially malignant and destructive bot) but again, that is not the goal of most exploitations. What they want is access to your resources, typically to run programs, store files and serve them (leeching your bandwidth) or send spam email through your server. All this is automated. In order to get what they want, they have to be able to control their botnet, and often this is done through IRC channels, so a telltale sign of compromise is that they setup outbound irc connections to their control channels. Sometimes their scripts screw up, but changing a mysql password is just something these exploit scripts wouldn't do intentionally. Only someone with root access is going to be able to probe and figure out what exactly has gone on with your server/instance etc.

When you send variables between scripts, you have these options: -Get parameters -Post parameters -Cookies -Session variables. In form2.php you get the return of your form, and you set these to php variables, but when the script is done running all those variables are discarded. If you really want to continue with this 3 script structure, probably the easiest way would be in script 2 to set your form with a corresponding number of hidden form variables with the same names. Then your current structure will work basically as expected. So one example would be: <?php $fname = $_POST["fname"]; ?> <input type="hidden" name="fname" id="fname" value="<?= $fname ?>">

Just FYI SQL Anywhere is not SQL Server. It was originally a product from Watcom that provided a small scale rdbms focused on data replication. It was designed for small shared sql databases that needed to be replicated potentially across wan's and possibly hundreds of servers. It is often licensed as an embedded database for small scale sql db needs, being that it has a lightweight engine process that has been ported to a lot of different platforms. It's not surprising that a company might have built a product with it embedded. I don't know that we're clear on your requirements. What does "make it publicly available" really mean? I'm guessing here that what you mean is that you are going to have to develop an extension to your website that does queries to the sql anywhere database. Assuming that is true, and because sql anywhere intrinsically has this replication capability, one option is to run a sql anywhere instance on your linode box, and then all you would want or need to do is allow just enough access through your firewall for the replication traffic to run between your internal box and the linode instance. You could tighten these rules down to the specific ports and ip's with port forwarding and deny/allow rules. You would not need nor want to put the box in the DMZ. I'd really want to fully understand the vendor's solution stack before I made any decisions on this, so consider it food for thought, although you can run this idea by them, again assuming that their system is built on top of sql anywhere.

Vagrant is a popular solution for all these problems. With that said, composer does do much of the heavy lifting. With vagrant, and some puppet or chef configuration files, you can have complete self contained virtual machines you can start or stop as needed. It automates the creation of a VM and all the initialization can be automated. What I really like about it among other things, is that it keeps all that configuration in a shared-nothing environment -- so if you need a complete vanilla LAMP environment with a basic cakephp environment, you could set that up, and tomorrow if you need a 2nd environment, you can simply use the same vagrant file. You do need a fairly beefy machine with plenty of available memory, but Vagrant has packaged and simplified most everything else. For example, I found these 2 vagrant files to look at: https://github.com/FriendsOfCake/vagrant-chef https://github.com/rehabstudio/vagrant-puppet-cakephp From what I saw there are many more to investigate. Just to be clear, if you had vagrant setup on your workstation, you could grab one of these vagrant file projects, copy the structure to a new project directory you make, change to the directory and vagrant up, and you'd have a full working system where you could iteratively work and develop new code.

Just to clarify, Composer files have to be in json format. So you need a composer.json file, not a composer.js. It is json, not javascript code. Aside from the location of the file, a library really needs to be in a public version control system. The way dependencies work, and for the ongoing development of the library, the author already needs to be somewhat savvy as to how to version the library. You don't for example only want to have a master branch, and have everyone pulling the library from master, if you will be actively updating it, perhaps with new features or changes that will break the old functionality. For that reason, ideally the author should already have a release branch and have version tagged it appropriately. This information all goes into the composer.json file. More about setting up a library is in the composer manual: https://getcomposer.org/doc/02-libraries.md The library also needs to be PSR-0 compatible. See: https://gist.github.com/Thinkscape/1234504 PSR-0 insures that libraries will be setup in a structure, and to have used php namespaces so that there won't be collisions, and that composer will be able to build a valid autoloader to make the use of the library functional.

SF2 is a dependency injection framework. It's probably a reach for you to expect to understand DI when you don't grasp the basics of oop. These days, the state of the art in PHP is component libraries, thanks to composer. You need to get it installed and learn the basics of it, if you want to bring yourself into the modern era of PHP. I should point out that Laravel's core is the symfony2 components. With all due respect, are you really in a position to judge the benefits of OOP? I understand if a master coder who can use OOP fluently wants to rail against it, but someone who admits they don't yet understand the basics of it, isn't really in a position to dismiss it. Take the time to watch this video, and it should help you understand why Composer is important, and why component libraries are the state of the art in the PHP world (and why this was a long time coming and absolutely necessary for PHP to continue to compete with alternatives like node.js, python and Ruby). Here's a 2 minute video on namespaces which are important to understand when using libraries and modern PHP OOP: https://knpuniversity.com/screencast/php-namespaces-in-120-seconds/namespaces Here's a 14 minute video on composer: https://knpuniversity.com/screencast/composer/composer After you have watched these videos, I hope you'll start to gain some clarity. After that you'll be in a position to begin to untangle frameworks (which are really a set of interdependent classes), and you might even be inspired to start to play with some of the individual symfony2 components. Try making a simple project that utilizes one or two components and just write some simple code. A great one to start with for most people is: http://symfony.com/doc/current/components/finder.html For example, you could write a simple script that uses the component to find all the files in a particular directory (and it's subdirectories), sort by name and list the files out. Try it with the special $finder->in(__DIR__);constant __DIR__ which will be the directory where your script is located. With the component, it is literally something you should be able to write in 10 minutes or less, using only a handful of lines of code.

SQL injections are basically a situation where the user is able to "inject" a modification to the SQL statement via input. Here's a simple example: $sql = "SELECT * from MEMBER WHERE account = '$account' AND password = '$password'";This is a somewhat typical login statement, where someone will provide their account name and password to a form, and you accept input and build your sql statement. Then based on the return of a row, people will often accept the login as valid and set the user's session variables with the account information. BUT!!!! What if the user sends this as input --- ' OR '1' = '1 Now when the password variable gets interpolated the SQL string becomes something totally different than what you originally intended. For this reason, you typically have to be extremely careful about escaping input variables so that these types of injections can not get into the code. It's just much simpler and safer not to have to deal with escaping at all, and instead, to use prepared statements with bound variables anyplace where you're going to take user input and use that as the basis of a query, whether that be a select or an insert or update.

Yes, but between is the same as WHERE t.foo >= {low} AND t.foo

No, PHP does not have a compiler -- it's an interpreted language with a runtime environment.

I know you think that this idea is actually simpler, but it's really not. If you had a decent base model class you could create all the child models in no time at all and be able to implement your admin/crud without sticking sql strings into a database.

Now that you have the library working with composer, whatever instructions they provide for cakephp is the one that you should be following to use the wrapper library. Composer has downloaded the dependencies and generated an autoloader, but how that autoloader is used from cakephp is something I can't speak to. I see no reason that you would need to do this however: App::import('Vendor', 'HighchartsPHP/Highchart');The autoloader should already have taken care of that. I found these references that look like they provide the needed information: http://book.cakephp.org/2.0/en/installation/advanced-installation.html https://learntech.imsu.ox.ac.uk/blog/?p=926 There are some javascript framework dependencies described here: https://github.com/ghunti/HighchartsPHP -- however, that would be something you would expect to see generate a problem after the page is running ok from the php side.

Ummm...... go into shell. cd to the project directory. Run: composer update

This pretty much covers the way I've upgraded php and other components of a MAMP stack under osx -> https://trac.macports.org/wiki/howto/MAMP As an alternative, let me suggest investigating a few vagrants. Pretty much any lamp or nginx based distro of your choosing could be located, or there are some pre-packaged vagrants you could try, that popped up in google: https://github.com/irmantas/symfony2-vagrant https://github.com/kleiram/vagrant-symfony Vagrant is a great way to develop without having to mess with your host OS. The only issue I have had in the past is that sometimes composer can be hinkey under virtual box, but I'd still recommend looking into it.

There are entire books about the topic of OOP. For CI, how about http://tutorialcodeigniter.com I don't use CI and I don't recommend it, because it's antiquated. Why learn a framework that came out eight years ago, when PHP had a lot fewer OOP features. I'd suggest you instead learn symfony2 which as a community has been instrumental in moving the state of PHP development forward: http://symfony.com Although not free, this company run by the symphony documentation lead, has a low cost video series that will teach you symfony2 development: http://knpuniversity.com

If an IP or IP block is blacklisted, then that's going to be a problem. When you say "whitelisted" I'm not sure what you mean by that. Getting individual customers to whitelist your emails is hard to do in my experience, even though companies routinely try to send people instructions on how to do just that. But that doesn't involve knowledge of an IP address. Otherwise, SPF, Reverse DNS and to a lesser extent, DKIM are all important, so I agree with you strongly that an understanding of those things is very helpful in figuring out how to maximize acceptance of your outbound email.

Yes, access the files directly using the full filesystem path to them. I've stated this 3x now.

Yes, which is how browsers work --- they make HTTP requests from the client to the server, and the image resource is assembled on the client. You are coding a PHP/Serverside script. Are these images on your server? If so, your script should access the image files directly. Strictly speaking file_get_contents can use the HTTP wrappers if that is turned on, but as it's a huge security hole, most servers do not have that feature enabled for these types of file oriented functions.

A url is not the same thing as the path to a file. Based on what you're trying to do here, you need the filesystem path to the images.

Also once you use the structure Barand provided AND you remove leading '%' from the LIKE queries, you'll have a performant system for querying for serial numbers with a single index on the serialno column. If you want to provide some extra usability you could have your query add variations to it, so: /// $searchno contains criteria SELECT * from SERIAL where serialno LIKE '$searchno' OR serialno LIKE '00$searchno';