data disappearance in browser

[mathematrucker]

A certain field's data has disappeared in my browser. It's still there in the FM 10 file though.

The data in that field had previously been displaying fine on the web. Note, it's just one field from each found record that disappeared, not entire records - the data from the other fields continue to display fine.

The only difference between those fields which display and the one that doesn't, is I made some changes to its field definition to perform some text manipulation (it's an ordinary text field). If I recall correctly, I created a new calculation field using the Substitute function, changed that calculation field to a text field, deleted the old text field, then renamed the new field to match the name of the old field.

How could this make the data disappear on the web?

After this happened I wondered what would happen if I created a new text field from scratch, entered some text in it, and tried to display that field on the web. As I suspected might happen, the data did not display.

The only guess I can muster is maybe there's something going on with Accounts and Privileges that I don't understand. Maybe I was logged in with too many or too few privileges when I made the changes, compared to the ones I was trying to view the data with over the web.

If that is the case, what should I try next?

[Peter (duksis3)]

Practically every time you make changes in FM fields - change data type, add drop-down etc. menus and so on, you need to change PHP source.

If you make PHP via PHP Assistant, every time save generated site. If changes are necessary - open saved phpsa file, make necessary changes, generate new PHP source and replace old one on webserver.

Yes - it is a bit complicated.

[mathematrucker]

Can you please be more specific? Let's say I just want to display a newly added text field in my browser. What additional PHP needs to be added besides simply referring to the new field's name in something like this:

$record->getField('new_field', 0)?

I would have guessed that anytime PHP initiates a new session and creates a new database object, it looks at the database that's currently out there and bases the object on whatever it finds, not on some additional PHP code I wrote to tell PHP I added a new field.

[Peter (duksis3)]

Simply way way to do that is to open PHP source (remember - for each: browse record, recordlist, edit etc. is separate PHP file) with TEXT editor (not word processor like MS Word, OpenOffice, TexEdit and so on -I use Smultron), look how fields are represented (similar like you say), Copy all corresponding to existing field, Paste in place you need o appear new field (before some field, after some field), then change Field name and Get() is necessary.

Do it for ALL files where new field must appear.

"I would have guessed that anytime PHP initiates a new session and creates a new database object, it looks at the database that's currently out there and bases the object on whatever it finds, not on some additional PHP code I wrote to tell PHP I added a new field" - NO, PHP can represent ONLY what is written in file source. PHP doesn't guess anything.

PHP is more advanced, sometimes much faster like IWP but take more job to make all running as you want. And is very good to have some knowledge about CSS.

Look in www.hierarchy.lv - there are couple of ideas about php to go forward from PHP Assistant generated file.

[mathematrucker]

This reply isn't at the level of specificity I was hoping for, but I understand what you are suggesting.

btw, I use BBEdit to edit code. On Windows I use Epsilon.

When I first ran PHPSA on my FM 10 database a couple months ago, with a modicum of effort I was able to customize PHPSA's original PHP and HTML code to do exactly what I wanted, to build a custom website that uses just one database table.

My next task was to add three new tables obtained from a separate FM 6 CDML website (that uses three FM 6 database files). The task of editing the PHP files so the new FM 10 PHP-driven website's appearance and functionality matched that of the FM 6 website was fairly easily carried out.

That's worth repeating: I added three whole new tables with dozens of new fields to my original FM 10 database, and encountered little trouble adjusting the PHP files to make things work. There isn't much else to do beyond simply adjusting the $layoutName variable to match the name of your new table.

Field definitions don't come into play - you don't have to manually write anything into the PHP having to do with field definitions. The whole purpose of the FM API is to simplify tasks like adding fields, etc.

It's still a complete mystery to me why my text field won't display in a browser.

Edited November 15, 2009 by Guest

[Peter (duksis3)]

If you haven't defined field in PHP, you never see it on the web.

PHP API does not add any fields in PHP script - how it can be done from your point of view?

If PHP source is correct you see PHP reflected FM content in browser - check PHP API documentation.

No Martini - no party; No field in browser - no correct PHP.

And here is nothing wrong with browser, FM or PHP API.

[Peter (duksis3)]

Sorry - forget:

You say - "The whole purpose of the FM API is to simplify tasks like adding fields, etc."

NO.

This is the purpose of PHP Assistant.

[mathematrucker]

You don't define fields in PHP, you define them in FileMaker.

Like I said, I already added lots of new fields in new tables without any trouble. Your last reply had nothing to say about that. Wouldn't you think I was already aware of what changes needed to be made in the PHP to get my browser to display all those new fields/new tables? I already know the drill dude.

Neither you nor I has any idea why the text in a certain field on my website stopped being displayed.

One thing I haven't mentioned yet, is the disappearing field is a related field, but I don't see how that would matter. All the other related fields within the same (related) record display just fine.

One possibility I wondered about, is if one record had some weird unrecognized character in that field, could that cause PHP to reject that field's contents for the whole database? I'm grasping at straws - it's time to stick one in a Martini!

[Genx]

This might be stating the obvious but:

1) Check the layout that the php page you're trying to access is relying on

2) Navigate to that layout in FileMaker and ensure that you can see that field in the portal. Also note that field names are case sensitive and should obviously be prefixed with the correct related table occurance name.

Second Obvious:

Check security and ensure the account you are using to access the system via the API has access to that field.

Alternatively:

You'll have to have a play with the API and loop through the layout object to ensure that the xml request is actually seeing the field at all let alone it's value. If it's not then come back and we can shoot a few more ideas back and forth.

[Peter (duksis3)]

If PHP is correct, then check access to that field for all accounts in use. And ... Check again PHP. Something "very small" can be incorrect in PHP and you have no result. And be sure - checking can take hours :

Does the field you are trying to see in browser appear in IWP?

[Tony Morosco]

If the disappearing field is a related field, you may also check on the following, which caused me great problems for a few hours:

If your related files are old-school (multiple tables, multiple FileMaker Files), it may be the an alteration to your External Data Sources (File > Manage > External Data Sources...).

I recently 'cleaned up' our External Data Source listings, which had proliferated beyond belief.

Since we host our tables on FileMaker server, I cleaned them all down to a single reference of

fmnet:/host.domain.name/

But this broke my PHP scripts whenever I tried to access a related field in a table. (it would say the field wasn't there, despite everything working just peachy on the native FileMaker app layouts.)  Of course this change was in the middle of a bunch of other changes to the database, so it took a lot of tail chasing with permissions (assumed it was because the related table had the wrong permissions for PHP access).



I had to re-add the following to External Data Sources, and voila, everything was restored and my related fields started displaying again in PHP:

fmnet:/host.domain.name/

file:.fp7

Cheers,

Tony

BTW, the reason I cleaned up the external data references was we suddenly had a problem of a 30 second time lag when first opening a database, for no apparent reason. But the cleanup didn't help.

[mathematrucker]

Stating the obvious is a good practice when troubleshooting. It has solved my problem.

When I created a new calculation field based on a certain text field, then deleted that text field and renamed the new field to match the old one and changed it to a text field, it slipped my mind that the old field would be gone from the portal and thus need to be replaced. I should have explained right from the get-go that it was a related field that was missing.

Thank you very much to everyone who supplied replies.

[Genx]

One thing I've learnt from a heck of a lot of development is that in 99.9999% of the circumstances that come along where you think PHP or FileMaker or something similar is broken... it's not - it's more than likely something you did.

If you go into it with that mindset you're much less likely to spend hours on end bashing your head into a wall :(