I am using wamp server to develop a website using php, mysql, PDO, html and css.
My wamp server is using PHP 5.3.5, MySQL 5.5.8 and Apache 2.2.17, I am also using InnoDB for transactions.
Considering that my internet hosting provider has at least these versions of php, mysql, apache, and supports InnoDB will the website I build act in the exact same way.
Is it possible to design a website in wamp and then expect several errors when going live? And if so how is this overcome?
Thanks.
As others note, there are many potential hiccups (but I view them as learning opportunities.) But I've done it this way for over five years and have yet to find a difference that wasn't easily overcome. Just stick to the middle of the road, use defaults as much as makes sense, and have fun. It's a great way to explore the platform.
There are many things that can go wrong, most of them having to do with how the web server and PHP are built and configured.
The simplest example is PHP's safe mode: there are many things that safe mode does not allow, and turning it off may not be an option if you are on a shared host. Another example is which extensions are enabled in PHP (your app may require one which the host does not have).
Of course this is all moot if you rent the whole server (or a VM), as in this case you will be able to do whatever you please.
For completeness, I have to mention that there might be platform-specific differences in behavior resulting from the same library (which PHP uses to provide some functionality) compiling into different behavior on different platforms (think platform sniffing in C with #ifdef). I have been bitten by this in the past, but the possibility is not large enough to worry about it beforehand.
A lot of the issues can be worked around by moving constants into config files, like Jon says. Some issues will be less in your control and harder to diagnose. For instance, the output buffer control may be configured differently outside the DocumentRoot you have access to. This can cause confusing problems when you try to write headers out when other content has already been sent out. Similar issues with the timeout numbers, etc.
Related
I would like to use the php built-in server just for dev environment, as opposed to starting WAMP everything, which consumes more resources, and since my site does not depend on any of the apache modules, I was able to do some work just fine, also using mysql from the command line.
The problem I have encountered is that, The built-in server is definitely slower compared to WAMP. Specially when doing database queries.
But what I would like to know is that, if the server is 100% reliable in-terms of building projects with it and directly uploading it to my server. Are there any other precautions to consider before attempting to use it as replacement for wamp?
Your observations are correct. PHP's built-in webserver is usually slower than Apache+PHP, but for quick & dirty testing on your machine it's fine.
I prefer it over full stacks, because I don't like having Apache as a Service on my system which always starts (as XAMPP does by default) manually starting/restarting a Windows Service on the other hand can be quite annoying (compared to a simple php -S). You also might have to change configs (e.g. when using vhosts), copy/symlink your project, maybe edit your /etc/hosts-file. All in all I think the built-in server is less hassle, than full stacks like WAMP.
I don't think #Areks concern weighs heavily against using the built-in server. If this really is a concern for you, you should account for different systems/configurations, e.g. by writing tests and using tools TravisCI, Vagrant and/or others. If you develop for a specific system you probably have a staging environment (as similar to the production env as possible) anyway.
yes, you must been warned that the php builtin webserver does not provide support for .htaccess, which is extremely useful (though i use it quite often for small tests)
I have used apache solr in my java project smoothly, but when i come to the end to solve a same kind of issue with PHP, this issue is arising:
To run apache SOLR, we need JVM to be installed on the server. But I don't know whether there is JVM installed in my client server or not. Because it is PHP apache linux server (not dedicated), I don't know whether I will get to access the console by which I can manage a bit.
Could any body tell me what is the alternative for apache solr for simple PHP environment?
Or please suggest me best indexing search technique for PHP.
Some options:
The worst solution, but probably the easiest if you want to remain in this (shared?) environment is to use a php solution like aitchnyu suggested. You could even use your own.
Shared environments often have access to mysql, you could search based off that. (Also not ideal, but possible)
Upgrade servers to like a virtual-shared server or use a seperate server for SOLR (I use ec2 free-tier which works well)
Not really an option but to answer your question, yes you can access the terminal through php but this is far from what you should really do because most shared servers disable access through php (in fact they didn't give you ssh access for a reason).
Also because even if they forgot to close this security hole (which happens sometimes) you will exhaust your resources (ram, cpu) pretty quick and you'll have to upgrade servers anyway.
I would like to host a few 3rd party PHP scripts on a Windows server (running in VMware), so I am looking for a way to limit all the users to accessing their own directories (and subdirectories) and prevent them from executing anything on the machine.
Port 25 is completely blocked and there is a very low limit on the number of external connections they are allowed to make.
There must be others that have come across this issue and any ideas, advice and tips are welcome.Thanks!
For PHP, there's the open_basedir restriction that is supposed to limit PHP script access to certain directories, and it usually does. However, it seems to be flawed. Article here - It's from 2008 though, so the shortcomings described there may have been already addressed in a recent release.
There's also the much hated safe mode that may have its place until PHP 6 comes along (it will be removed there.) be very careful with allowing scripts to execute outside binaries.
Suhosin adds additional security and restriction possibilities to PHP and is certainly a good idea to install. Its defaults may interfere with more complex apps, so be sure to look deeply into its config file. However, it looks like you have to recompile PHP to get it running on Windows. This is something I would really recommend looking into.
If you need something stronger and can use Linux, putting Apache in a chroot jail is something I came across a few days ago. It looks totally advanced, though.
I just noticed a PHP config parameter called allow_url_include, which allows you to include a PHP file hosted elsewhere as you would a locally. This seems like a bad idea, but "why is this bad" is too easy a question.
So, my question: When would this actually be a good option? When it would actually be the best solution to some problem?
Contrary to the other responders here, I'm going to go with "No". I can't think of any situation where this would make a good idea.
Some quick responses to the other ideas:
Licensing : would be very easy to circumvent
Single library for multiple servers: I'm sorry but this is a very dumb solution to something that should be solved by syncing files from for example a
sourcecontrol system
packaging / distribution system
build system
or a remote filesystem. NFS was mentioned
Remote library from google: nobody has a benefit to a slow non-caching PHP library loading over PHP. This is not (asynchronous) javascript
I think I covered all of them..
Now..
your question was about 'including a file hosted elsewhere', which I think you should never attempt. However, there are uses for allow_url_include. This setting covers more than just http://. It also covers user-defined protocol handlers, and I believe even phar://. For these there a quite a bit of valid uses.
The only things I can think of are:
for a remote library, for example the google api's.
Alternately, if you are something like facebook, with devs in different locations, and the devs use includes from different stage servers (DB, dev, staging, production).
Once again during dev, to a third party program that is in lots of beta transition, so you always get the most recent build without having to compile yourself (for example, using a remote tinymce beta that you are going to be building against that will be done before you reach production).
However, if the remote server goes down, it kills the app, so for most people, not a good idea for production usage.
Here is one example that I can think of.
At my organization my division is responsible for both the intranet and internet site. Because we are using two different servers and in our case two different subdomains then I could see a case for having a single library that is used by both servers. This would allow both servers to use the same class. This wouldn't be a security problem because you have complete control over both servers and would be better than trying to maintain two versions of the same class.
Since you have control over the servers, and because having an external facing server and internal server requires seperation (because of the firewall) then, this would be a better solution than trying to keep a copy of the same class in two locations.
Hmm...
[insert barrel scraping noise here]
...you could use this is a means of licensing software - in that the license key, etc. could be stored on the remote system (managed by the seller). By doing this, the seller would retain control of all the systems attempting to access the key.
However, as you say the list of reasons this is a horrifying idea outweigh any positives in my mind.
We have an existing windows desktop app written in C# 6 that uses an MDB MS access database for its storage. I need to write a web interface that can read that php webpage and maybe write to it later on.
This web interface will be included with our current installer for the application or as a simple addon. The user should only have to click start server and it should just work serving the php pages from the installation directory.
I was playing with gwan, nginx, quickphp. Only the last one seems simple enough to work.
So my question is what do or would you use to achieve this? Are there alternatives to quickPHP?
Distribution. I'd also like to have something we can include in the installer. I dont want the user to have to do and download any additional apps.
I know you said PHP, you also mentioned your app is written in C#.
You might want to take a look at aspnetserve if you are willing to write the web part in .NET. It might be possible to use PHP with it, but I don't know.
Either way I have found it very useful in several projects.
If you can live with other types of server side scripting than php, Microsoft's Cassini server looks like potentially a very good match (.net based, source available, small, ...).
Oddly enough it's hard to find a "canonical" url for it but Googling or searching here on SO brings back plenty of links.
Edit: an at first sight surprising feature may be that out of the box Cassini only seems to listen to localhost (127.0.0.1). However, as explained here,
Cassini only listens to localhost requests (for security reasons) -- it
uses IPAddress.Loopback in the code. You can find the code in Server.cs and
you can change it to IPAddress.Any to enable access from other machines. Of
course, you'd be opening up the port for outside access, so you need to be
aware of the security implications.
Or go with UltiDev Cassini
EasyPHP
Lampp
For a light-light-weight server without installation you can look at nanoweb portable. I am not sure how performant it is though.
Are there alternatives to quickPHP? The user should only have to click start server and it should just work serving the php pages from the installation directory.
G-WAN works like this (zero-configuration): scripts and "edit & play".
And G-WAN v3.10+ supports C#, Java and PHP scripts (all natively).