Custom Web Publishing technologies are programming technologies in the traditional sense. A programmer writes program code in one or more text files and then a web Application Engine interprets those files. As with certain programming languages, syntax errors can stop your program cold and there can be significant learning required to become proficient with PHP. Custom Web Publishing offers great power, but it does not offer the same easy use as the mouse driven development tool set of native FileMaker Pro. But as we've established earlier in this discussion, when you need Custom Web Publishing, you need something that doesn't have access to the client.
So all the same for certain classes of problems, Custom Web Publishing is certainly the best choice for Web Publishing your FileMaker data. Although authoring PHP pages is outside the scope of this title, I have gone ahead and created a simple set of PHP pages that communicate with the Invoices_11_09 database. And I have included the database and the entire set of PHP Application Files in the exercise files for you to work with. However, they are there for you to pick apart and try to get some exposure to PHP.
Please do not contact the author or lynda.com support if you're experiencing issues or want to make modifications. See the FileMaker Server or Web Server support documentation only, but I have provided this application to you for learning purposes. But what I do insist that you do, do is to consult the lynda.com online training library. If you go into the online training library and search for PHP, you'll find a plethora of courses that will help you to get familiar with PHP, from having no experience whatsoever, or even into more advanced programming knowledge regarding PHP.
So again, we provided you with an entire PHP Web Application and its supported database inside the exercise files for this course. But we'll ask you to refer to other resources for support or learning more about PHP. Because quite frankly we can talk for weeks to you about PHP and all the different great things it can do. So first thing that you are going to have to know is that all the PHP files are going to need to be placed in a certain directory inside your web server. So you'll notice that we have entire folder with PHP files in it. This is the entire family of files, including error pages and CSS, and every thing that you are going to need to run this in a web browser.
And it has to be placed in a specific location and it's a very easy place to find. I'm on a Mac, so I'm running Apache, so the way that you get to the Apache web root folder is to click on Library, then WebServer and then it's the Documents folder, that's where the web root folder is on Mac. On Windows the path is the www.root folder, and any folder that you place inside there will then be inside the web root. So all we have to do is take these files, drop them into the documents directory, and we we'll authenticate, and now anything that's in the web root, like any other root, can be accessible by just putting in the IP address of this machine, and then forward slash (/) with the directory name.
So the directory name is php, and I've got a page in here called home. So let's open up Safari and type in the IP address of the web server, or if all the different components are running on the same machine, it's the IP address of that machine. So IP address/PHP/home.php. So all you have to do is do the IP address/the directory where all your PHP files live, and then forward slash any one of those PHP files.
So in this case I have created a very generic homepage with all the different navigation you need, and when you hit Enter, you will be able to see your PHP application appear. So nothing fancy, what I've done is created a style sheet that is nearly devoid of any style, but it's called White.CSS and I'll show that in the second. But the homepage contains references to navigation, and some brief text that I put on here, but I wanted to show you some of the basic ideas behind what you can do with PHP.
So here's an example of finding all the records in the database. So you'll notice that I've found 1535 Records, if I go back to the database and navigate over to Customers details, we see that we in fact do have 1535 records. I can delete one of those records if I'd like to, just to show you that we have got no tricks up our sleeve and we are going to go back. And you'll see now by simply refreshing, we have got 1534, now that refresh action is very important.
Because right now, I'm looking at data from a FileMaker database, but I am in the browser, but I am not connected to the database. I do not have a database session. I'm not using a thread on the database. Unlike Instant Web Publishing where, in between when you are connected and you log off, you are using up one of those threads. With PHP the only time I actually interact with the database, is when I press one of these buttons. So for example, if I simply click on the button to show me the detail page for one of my Customers, I've communicated just for that split second with the FileMaker database.
So when we talk about having a limitation of either 100 concurrent users supported by FileMaker Server for Custom Web Publishing, or in FileMaker Server Advanced we have upto 200 concurrent users. It's extremely important to take into account what we are talking about, when we talk about users and their session. So right now I just hit the Edit button and in less time than it took to refresh this page, I was communicating with the database server, and therefore I had a session. If several other web users and I, all hit that button at the same time, 200 of us will be able to get a request back in that split second.
And any one beyond that will just be queued up and then a second later will get their request. So we're not going to get errors, people aren't going to be kicked out. It's really, really important that you don't frame up the limitations for PHP in the same way that they are for IWP. Throw out all that understanding. There are no database sessions. As long as you have an application that it only receives requests of up to 100 concurrent at a time or 200 at a time, you're well within the bounds of FileMaker. So what this actually translates into, depending on what you have going on with your application, like right now I have been sitting here talking to you, and I haven't actually interacted with the database more than a few times.
So while I've done that there could be hundreds, possibly even thousands of other users out there doing the same thing. So you can simply do the math determining what kind of actions you're expecting. If people are just adding records to the database, well then, think about how many records you expect to be added in the 24 hour period. Do some math depending on how many hours that would be, and then within those hours get it all the way down to a second, and that can tell you how many records being added you can support within a 24-hour period or even an hour period. So that's the math that I used to determine the transaction.
Now don't get me wrong you can create new amazon.com or google.com with FileMaker as a back end, it just doesn't make sense. You are not going to have the multiple thousand transaction abilities that you have in those cases. But for several hundred or thousands of users over a 24-hour period, it's very likely that you can pull this off. I've created applications over the last 10 or 15 years that have supported that kind of a load. And FileMaker Server 12 has just recently been reengineered and the web Publishing Engine completely tore down from scratch, which of course serves Custom Web Publishing.
In order to be able to accommodate even more users or twice as many transactions as it's been able to do in the past. So trust me when I tell you these are not the limitations that Instant web Publishing has, as a matter of fact, they are not even in the same conversation. So let's get back to showing you some demonstrations. I want to add a record, a Customer record, I am just going to put a couple of pieces of data in here. And now I'm going to hit Save. Again, just communicated, done communicating; even in less time than it takes me to actually say it.
But now if I go back to the database I want to show, you the Company's name is Sample, and now I see Sample, and I see that that record has now been added and I am back up to 1535 records in my database. And also, I can go in here in Edit and call it Super Sample, go back, save my change, and we can go back into the database and without even refreshing we see that's updated. So the idea here is you can have live interaction with your FileMaker database, and enforce any rules that you might have inside your PHP application.
This is about as low end of a PHP application as you can get, but it can do things like Find, and I do a search, I see I have three records, I can click on one of them, and again like I said, I can do my editing, or I can look at all my records at once, find all them. Then I added something interesting here, it's called the Customer Summary Report. I want to show you that there is no layout in the FileMaker database. There's Invoices summaries, printing, Customer PHP, that's it.
No Customer Summary, there is not even Customer Summary fields created inside the Schema. As a matter of fact, we have no summary fields created in the Customer Table. But what I was able to do in PHP is create essentially a SubSummary Report that groups all 1500 contacts, and you saw it had a brief delay, but it didn't take long to do that. Groups them all by state then gives me a count of each state. I did all this programming inside of PHP. So that I don't have to bother the database with this processing, instead I can have this happen on the browser side, and let the client manage this.
So just an example of what can be done with PHP. So what's going on in the backend of these files, here I am showing you the same files that we've been working with inside of a Text Editor just to give you a glimpse of what PHP code looks like. There are a couple different types of files. First I have got a CSS file, if you're familiar with any kind of cascading stylesheets, you can see I've set it up in the same way. I've got header declarations in here, container stuff, page navs.
I have got every possible CSS that FileMaker could use within its API, but really I didn't actually populate them with anything more than just black and white color. But if you're familiar with CSS, this format should look very familiar to you as well. I've got things like Add Record Pages. And you'll see I am doing things like calling other pages like FM View and Error PHP. The FM View is a page that's very critical for you to be able to control, or any FileMaker application that you create in PHP requires an FM View file.
This is where all sorts of things live, like, the Usernames and Passwords for logging in, how your session management happens and all these different functions that are happening are all written inside this FM View, and then you'll notice that other pages throughout the application, all call the FM View. So instead of having to write all of that code in each one of these individual files, I just call it. I will write it inside FM view and I refer to it here. The same is true for the error pages.
You see that I write an error page and then I'm calling it from various different records in the database. The report is the one that does that SubSummary Report without going into it. You'll see some things that are kind of familiar though. See things like variables declared and if statements, in the same kind of formats as you might be used to, a lot of use of variables. And then you see common HTML. This is so that we can render all the data that's being produced by all these functions into something that can actually be interacted with inside of a web browser.
So I implore to you take a look at all these different files and try to get familiar with PHP, and again, consult the lynda.com online training library for more information on what all of this means when you're inside the code. Now at the very least you can take the files that I provided to you and point them to your database instead, and maybe work a little bit with the CSS and possibly end up with an application after some slight modifications that will allow you to use it with your own database. Not the least of which is changing the database name inside these files to your database name, and the layout name to your layout name and then the rest is customizing the application.
PHP and FileMaker combine to offer great power, but it does not offer mouse driven development tool set of native FileMaker Pro, but it doesn't have to. So you should set that expectation before you jump into PHP, you can completely customize the user's experience and do all sorts of things that you don't even have to do inside of FileMaker, just by using the FileMaker PHP API, along with the database and FileMaker PHP applications. All the same, for many classes of users and requirements, PHP is certainly the best choice for web publishing.
- Managing access to your database
- Parsing text with calculation functions
- Using calculations in field validation and auto enter options
- Creating nested subsummary and crosstab reports
- Creating user-driven and multi-criteria relationships
- Working with intermediate script techniques
- Extending Web Viewer using HTML5 and data URLs
- Sharing databases on a network using FileMaker Server
- Publishing your databases to the web using the Instant Web Publishing or PHP