Jump to content

Baloo

Members
  • Content Count

    204
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Baloo

  • Rank
    member
  1. Caveat: Site Assistant generated pages can quickly become a nightmare once you start modifying them. If you need custom pages you're much better off building them from scratch To answer your question: When php loads the page it will set the key value pairs from the URL to the $_GET associative array /* for http://www.site.com/recordlist.php&name=Fred&job=Boss */ print $_GET['name']; /* prints Fred */ print $_GET['job']; /* prints Boss */
  2. In the off chance you haven't figured this out yet (and for folks searching down the road), you need to set the second parameter of getField to the index of the repeating field. i.e. $record->getField('FieldName', 2); To get the second repeating value from the field
  3. How much data are we talking about? I don't have too much experience with runtime solutions and as such don't have a handle on their limitations, but the first thing that comes to mind is a Open URL script step that passes the data to a custom php script on your server.
  4. One quick caveat about AJAX Most browsers will always go to the cache for GET requests with the same parameters. So if your $queryString will always be the same but you expect different results (i.e. changes to the DB) you should either use POST or append a unique parameter like a time-stamp to the URL.
  5. The PHP API has access to any (and only) field(s) on the layout you hook it to, so my first guess is that the fields in question aren't on the layout.
  6. What you have is not really an error in the classic sense. It's just a "warning", which in PHP parlance basically means I know what to do, but I didn't get what I expected so you might not either. In this case the foreach statement is expecting an array as the first variable and it isn't getting one. My first guess is that the value-list in question doesn't have any values and what ever code set it made it null instead of an empty array. If the value-list does in fact have values you should look at the code that calls getInputChoices() an see where the second passed variable is getting set.
  7. The current API code will run fine on PHP 5.3 The deprecated "errors" are just letting you know it will cause problems in future versions. You can easily turn them off by editing in your php.ini file look for a line with something like error_reporting = E_ALL and replace it with either one of the following // Report simple running errors error_reporting(E_ERROR | E_WARNING | E_PARSE); // Reporting E_NOTICE can be good too (to report uninitialized // variables or catch variable name misspellings ...) error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE); After editing your php.ini file you'll need to restart Apache before the changes take effect. Also as with any application's config file Make a backup copy before you start tinkering around. That way if things don't go as planned you'll be fine. On a production server it's generally a good idea to send the errors to a log a rather than the screen You can also set those values at run time with the error_reporting function
  8. foreach() takes two arguments the first has to be an array the second becomes the placeholder for each value in the array. That error means that the first value supplied to the function is not an array. Without seeing the code its hard to say more
  9. You're bumping up on one of the many reasons I loath the Site Assistant. I've never tried it with the name field but you can hack JavaScript's document.getElementById() function to access an element with an integer by casting it as a string. function getNumericID(){ var intVal = 1; var elem = document.getElementById(intVal + ""); alert("name = " + elem.name + "nid = " + elem.id + "nvalue = " + elem.value); return; }
  10. You've got a couple of problems. First, the FindAllCommand is only for finding all the records for the supplied layout. Second, the setOmit() function is only available for a compound find request which would look like this: $cpdFind = $fm->newCompoundFindCommand($layout); $req = $fm->newFindRequest($layout); $req->addFindCriterion("COUNTRY", "="); $req->setOmit(true); $cpdFind->add(1, $req2); $result = $cpdFind->execute(); however in my testing it seems there's a bug in the API that ignores the setOmit = true value if its the only request in the compound find i.e. the above actually returns all records where COUNTRY == "" but the following works $cpdFind = $fm->newCompoundFindCommand($layout); $req1 = $fm->newFindRequest($layout); $req1->addFindCriterion("PrimaryKey", ">=0"); $req2 = $fm->newFindRequest($layout); $req2->addFindCriterion("COUNTRY", "="); $req2->setOmit(true); $cpdFind->add(1, $req1); $cpdFind->add(2, $req2); $result = $cpdFind->execute(); However since all you want is a list of all records where "COUNTRY" is not empty the following would be the easier route $find = $fm->newFindCommand($layout); $find->addFindCriterion("COUNTRY", "*"); $result = $find->execute();
  11. The WPE and XML feed can't seem to access "external data sources" via fmnet:/ as long as your presentation and data files are on the same server just change the reference in external data sources from fmnet:/server.host/DB.fp7 to file:/DB.fp7 and you should be good to go.
  12. Per the FM Knowledge Base article "Import/Export Script on FileMaker Server 10" Is it just me or that this render the ability run Server Side import/export scripts nearly useless?
  13. OK what that means is that the binary data is getting hosed when it renders on your production containerBridge.php page. Surfing to the long URL for a container bridge should bring up the image in a browser not the binary data. The most likely culprit is an error message getting inserted into the page. Try scanning through the binary data and see if you can spot any discernible text. Also double check your containerData.php file. Even a single white-space character rendered in front of the binary data will mess things up.
  14. I'm assuming by this you mean if the binary data is an image you can print out the image as opposed to the raw binary data. Just in case you've overlooked the obvious does the daemon have read privileges to containerBridge.php? Other thoughts what happens when you do the following: right click on the place holder image select and copy the URL listed for Location (Address (URL) in IE) Paste it into your browser's address bar.
  15. the only thing that comes to mind is an error message or some other text on the production server's "container bridge" file (i.e. the local php file that queries FMP and draws the image) Look at that page in your browser and see what comes up. If there is any text you should see it along with possibly the binary container data. Once you get beyond the WYSIWYG wizards, I know somewhere between diddley and squat about firewall management, but I guess it's always possible it's blocking the binary data in the cURL request while letting the XML and text values through. HTH
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.