fields.ini not being recognized

[fingerprn]

First of all, it was difficult to install a xataface interface because of limitations by my webhost, so I'm guessing this may have something to do with why this doesn't work. I'll explain what happened:

1. Webhost has the open_basedir tweak set up, so xataface couldn't write its random-named temp directory. I changed the path to within my home directory using the recommended method and it worked just fine.

2. I can't SSH to root to run the makesite script, so I just ran the auto-install. This meant that the tables directories were not made.

3. Manually created /tables/Landing/fields.ini, but did not create any other files. I had no other tables.

4. Added the following to the blank fields.ini file:
[Lnd_body]
widget:type = "htmlarea"

5. Tested and... no wysiwyg editor.

Any ideas? Thanks in advance.

Extra info you might want:

PHP version: 5.2.4
MySQL version: 5.0.51a

---------------------
conf.ini file
---------------------
;;Configuration settings for application
title="genn_landing"

[_database]
host="localhost"
name="genn_landing"
user="landing"
password="xxxxxxx"

[_tables]
landing = "Landing"


-----------------
index.php file
----------------
<?php //Main Application access point
require_once "/var/www/vhosts/domain.name/httpdocs/xatafacex/dataface-public-api.php";
session_save_path('/var/www/vhosts/domain.name/httpdocs/genn_landing/sesstemp');
df_init(__FILE__, "/xatafacex");
$app =& Dataface_Application::getInstance();
$app->display();

[shannah]

Have you modified this line for posting here?

Code: Select all

df_init(__FILE__, "/xatafacex");


The 2nd parameter of df_init could be the source of the problem. If you are specifying a full domain (e.g. mydomain.com/xataface), but you access the site from a different domain (e.g. www.mydomain.com/mysite), then the browser might prevent the cross-domain requests for the wywiwyg editor. If you keep Xataface at the same domain exactly as your app, then it should work fine.

Other than that, check your error log to see if there are any clues.

Steve

[fingerprn]

Thank you for the reply. Same domain and nothing is showing up in the error log, so I'm at a loss at this point.

[shannah]

Has anything at all been modified in the index.php file you posted or us it exactly as posted?

Check your browser JavaScript log for clues.

[fingerprn]

Yes, for privacy reasons I changed my domain name to domain.name and the folder name genn_landing was a little different, but I changed it in all instances before I posted.

Browser logs didn't indicate any errors.

How about clearing a cache? I can't directly delete any of the template files through FTP because of permission issues, but is there another way to do that? Clearing the cache has often helped with other scripts I've used.

[fingerprn]

Okay, clearing the template_c folder was definitely not the answer! (But I'm guessing you knew that). Looks like I'm be trying to re-install some stuff. Maybe that will fix it.

[fingerprn]

Well, that wasn't fun. Got everything installed and working, but the fields.ini folder still isn't being recognized.

[silma]

Have you tested with something else than a HTML area ? A widget description for exemple ?
Just to be sure that it's the field.ini that is involved, and not the HTMl editor ?

Also, i'm sure you have already checked, but the table name must be exactly the same that the folder name (it's case sensitive), idem with the field name in the fields.ini file that must be the same that the fiels in your table.

(Sorry for the english..)

[fingerprn]

Thanks silma for the response. Yes, I tried using the widget:label option with no effect. Everything else is set correctly regarding folder names (X converted my table name "landing" to "Landing" so that's what I named the folder).

I also tried changing df_init(__FILE__, "/xatafacex"); to another path. Not only did that not work, but it screwed up the template display, so I know it was originally set correctly.

[shannah]

That makes it clear that it's just not picking up the fields.ini file at all. This means one of:

1. The fields.ini file named wrong or in the wrong location.
2. The fields.ini file has a syntax error.
3. The fields.ini file is not readable by the web server process (permissions issue).

#2 is easy to check because there would be a warning or error in your error log. Make sure that your fields.ini file is located at:
tables/tablename/fields.ini file
where "tablename" is the name of the table (case sensitive). It is all case sensitive.

[fingerprn]

Thank you for your help on this. I know it's easy to make a boneheaded syntax error, so let's go through each and make sure I didn't...

1. The fields.ini is located in /httpdocs/genn_landing/tables/Landing/fields.ini

I copied this DIRECTLY from FileZilla so that there is no chance of giving inaccurate info. I realize this isn't the full path, but FileZilla doesn't display that with my limited access. The full path is:

/var/www/vhosts/domain.name/httpdocs/genn_landing/tables/Landing/fields.ini

This has been verified by phpinfo(). I changed my real domain name to domain.name on this post for privacy and security reasons.

The real name of my table is landing with a lower-case l. Therefore, this path should be accurate.

Bottom line: I feel confident this is correct.


2. The fields.ini file could have a syntax error. I think I may have included one in my original post, but I think I've fixed it now and it still doesn't make any difference. The real names (i.e., names within actual database) of my fields in the landing table are lnd_headline and lnd_body. The following is pasted directly from the fields.ini file located on my server:

[lnd_body]
widget:type = "htmlarea"

[lnd_headline]
widget:label = "TEST"

NOTE: There were some discrepancies between how Windows Notepad and Notepad++ handled this file. That is, Windows Notepad didn't recognize the carriage returns that were created in Notepad++. I tried reformatting the file in Windows Notepad, but it didn't make any difference, so I set FileZilla to use Notepad++ for consistency.

I am getting no warnings or errors in my error log. I also set PHP to show all errors and warnings and I'm not getting any.

Bottom line: Not completely confident this is set up correctly. Please confirm based on what you see.

3. I set all permissions throughout /tables/Landing/fields.ini to 777.

[shannah]

The real name of my table is landing with a lower-case l. Therefore, this path should be accurate.

Then why do you us upper case "L" in the name of the table's config folder. E.g. it should then be
tables/landing/fields.ini

3. I set all permissions throughout /tables/Landing/fields.ini to 777.

These should be 644. In fact setting files to 777 will sometimes trigger security measures on the server to block access to it (on some hosts). It isn't a good idea to use 777 any more than you have to. Even in places where we use examples setting permissions to 777, it is usually better to instead figure out who the web server process is and grant them group permissions (e.g. 775 and make the group something that the webserver belongs to).

-Steve

[fingerprn]

Then why do you us upper case "L" in the name of the table's config folder. E.g. it should then be
tables/landing/fields.ini

Thanks Steve! That was the problem. I kept noticing in other posts that people were talking about having to capitalize the first letter of their table name. Add to that capitalized table in your example and the following in my conf.ini file: landing = "Landing" and I was completely convinced I had to capitalize my folder name. Ugh!

I only changed my permissions to 777 after you mentioned a permission issue in the previous post. I'll change them back.

Thanks again for your time.