6 Replies Latest reply on Jul 29, 2013 10:55 AM by andersmonsen

    Seeking PHP person


      I have a solution with a php component that was developed by someone else. It's been stable for a couple of years, but has suddenly stopped allowing the creation of new records. All the other functions work fine. We checked the usual stuff: the database is fine, no one has access to the server and the IT guy doesn't think any updates have been allowed on the server.


      The person who used to work with my on this project isn't doing FileMaker or PHP any more, so I'm looking for someone who can troubleshoot the php files for the client. If you're interested, please contact me offline at susan@dbhq.net so I can give you more details and hook you up with the right folks.

        • 1. Re: Seeking PHP person

          You might want to check with Anders Monsen of MightyData:  http://www.mightydata.com/company/team.php

          • 2. Re: Seeking PHP person

            Elance.com and odesk.com is another place to check, although Anders's credentials certainly are top notch. Also, working with a consulting firm like MightyData would certainly come with the benefit of other recommendations and enhancements that won't always come from freelancers.


            Although from the sound of it, we might be able to help recommend a few things here. Things rarely just "stop working" in CWP. But when they do (no explanation functionality loss), it's always boiled down to a wipe and reinstall of whatever server is running CWP for me. But that's just a personal experience, and happens far more frequently with IWP for me, so don't let it scare you.


            Has anything else in your environment changed, IE:

            -version of PHP the front-end application is running?

            -major OS or other configuration changes of your backend CWP server?

            -Schema changes in your database (removals or additions of fields)?

            -Privilege set changes in filemaker at all?

            -Is the frontend (public-facing) PHP hosted on the same server as the filemaker database?


            If error reporting is not built into your application, you might want that added as well. Even if the errors are returned in code comments, it would benefit you in troubleshooting what the cause was.


            Lastly, here's a checklist from the FMS11 CWP guide ( http://www.filemaker.com/support/product/docs/11/fms/fms11_cwp_php_en.pdf ), not sure if you went through all of this already yet:


            Troubleshooting your site

            If you have trouble viewing or using your site, verify the following:

            1 The extended privileges in the database are set for Custom Web Publishing with PHP and assigned to a user account. See “Enabling Custom Web Publishing with PHP for databases” on page 17.

            1 The database is hosted and opened by FileMaker Server. See FileMaker Server Help.

            1 The database account name and password you are using, if any, are correct.

            1 The web server and the Web Publishing Engine are running.

            1 PHP Publishing is enabled in the Web Publishing Engine.

            1 Open the FileMaker Server Technology Tests page in a browser:

            http://<server>:16000/test where <server> is the machine on which the FileMaker Server resides.

            1 Click the link Test PHP Custom Web Publishing to open a PHP page that accesses the

            FMServer_Sample test database.

            • 3. Re: Seeking PHP person



              Thanks for the recommendations and the additional things to check out. I appreciate it.


              Susan Prosser


              Co-author of O'Reilly's FileMaker Pro 12:  The Missing Manual

              • 4. Re: Seeking PHP person

                Hi Susan,


                Given the single page/function failure I would not suggest that it is necessarily the install or an OS problem that Mike has so efficiently documented.

                There are a whole bunch of php things it could be but I'd be looking too at FM... the specific layouts and fields referred to in the PHP interactions.

                If something has been changed in the database it would do what you are describing. The permissions, layout names and fields and valuelists and field access on the layout all need to be original... If they haven't been tinkered with, then you might look at corruptions on the layout or perhaps permissions changed elsewhere on a related field shown on this layout.

                You might also opt to reinstate a backup of the file(s) for that bit of the PHP.


                If you don't resolve things with the local guys, get in touch. The pedant in me loves a challenge ;-)


                - Lyndsay

                • 5. Re: Seeking PHP person

                  Thanks for the suggestions, Lindsay.


                  I checked all the usual suspects:  the web layouts, table/field names, and privileges. We did find someone locally who should be able to help. But failing that, I may contact. Love your idea of a "pedant challenge."


                  Susan Prosser


                  Co-author of O'Reilly's FileMaker Pro 12:  The Missing Manual

                  • 6. Re: Seeking PHP person

                    If something stops working it usually means the environment has changed. Either this is on the web server, or in FileMaker. If the web server, then a very likely culprit is a system update on the web server. Although the IT person may think otherwise, no system update at all in two years seems unlikely. With PHP you have several moving parts, and I second Mike's suggestions. You need to test for each of the components: PHP, the web server, the FileMaker database and the FileMaker server.


                    Check the FMS deployment to make sure PHP is running. Check the test page. If you can see the database, but cannot create records, trap for and display error(s). Check the database to see if privileges have changed. Check the layout for field name changes. Run the PHP test page to see if your deployment has changed, or the location of the php.ini file.



                    Anders Monsen

                    Architect of Integration


                    FileMaker 12 Certified Developer

                    FileMaker 12 Authorized Trainer


                    MightyData, LLC

                    972-390-8600 x105