Running a PHP script and reading an INI file

Hello everyone. This is my first post on these forums, and I appreciate any help, as I am very new to CMS's in general and ModX in particular, and as a plus I am also relatively new to anything related to the back-end. So I apologize in advance, and also I may use some terms incorrectly. Here is my situation:

I would like to run a PHP script that reads an INI file and generates HTML pages using data from the INI file. I've written the script, and it works fine when I run it on my own Apache local server. However, I am in a situation currently where, due to circumstances beyond my control, I must use ModX (not that I am against it, but it is not the environment I am familiar with).

How would I go about uploading the INI file and the script, then running the script to generate the pages?

Any help would be appreciated. Thank you!

Well, in general, you can upload the ini file to anywhere you like, then use a snippet (MODx's answer to inline PHP) to do whatever you wanted with it. Or if you really want the process to be independent of MODx processing, use the MODx "on page not found" event or its "on page request" event to turn everything over to an external script to generate the requested page.

The thing is, the way MODx and most other CMS applications work is that you create (in one form or another) a template providing the HTML structure that is common for all pages, and the distinctive part of each page, the page's title and main content, for example, is inserted into the template to complete the full HTML document. This dynamic content, unique for each page, is what is managed by MODx "resources".

So if you want to use the MODx template, but insert the dynamic content part from an ini file instead of the database resource content table, this can be done as well.

if we could see (a part of) your INI - file and your script we could tell you more about how you can do it inside of MODX

Generally, you would use the script as the code of a MODX snippet. The code should add the output to a variable called $output and have



at the end.

Then, you put a snippet tag for that snippet on the page where you want the output to appear:



MODX will replace the tag with whatever the snippet returns.

As Susan suggests, you can put the ini file anywhere (even above the MODX root, if it's sensitive information), but a typical spot is under the MODX assets directory, say in assets/ini/. In that case you would refer to the location in your script something like this:

Ugh, I wrote out a reply half a dozen times and clicked Reply and it disappeared. Anyway:

I have included the php and ini files for anybody curious as to what they look like.

I am writing files to the server using fwrite(), and am wondering if that will work, and where the files will show up. In a server environment that I'd be familiar with, they would show up in the same directory as the script. But here I'm confused as to where anything is located. Will it show up in resources? templates? Also, any html files that I generate aren't really in a ModX "format", if that's the right way to say it. They're just stand-alone html pages. Is this going to work the way I'm trying it?

The way I'm doing it makes sense in regards to the project, as far as I see it. The client wants to be able to edit the html pages using a visual editor and be able to see the data from the ini file--in this case, team names for their softball league. The client wants to be able to add scores to the page after-the-fact. If I generated the pages dynamically, the client couldn't see the team names when they are adding their scores. They would only show up when the page is viewed live, and the names have been added by the server.

I will try what BobRay said in regards to how to reference the location of the ini file.

Thank you very much for the help and any additional help coming.

Here is how a page should look when generated by the script: http://www.ecyberdeck.com/championscup.org/index.php?id=1

Okay, when I try to add an attachment, the reply function isn't working. Either way, the ini file looks like this:


and the php script just reads that with parse_ini_file() and has a giant html embedded in a fwrite() function. There's a couple other things, but that's the gist.

Ok, while this is sort of defeating the purpose of using a CMS in the first place, it can be done. Seems a bit redundant to me; if you're going to use MODx you might as well go ahead and use it as it's intended to be used.

You'll have to decide where you're going to upload your ini files to, then tell your snippet where it is located relative to the MODx main index.php file. Then you'll need to tell the fwrite function where to write your finished .html file, again relative to the index.php file.

If you're going to use a MODx page to handle all of this, I'd use a file-type Template Variable simply for the file manager provided so it will be easier to upload the file where you want it. You can even create a Media Source for the TV to restrict the user's access to the desired directory.

The files will be written to whatever path you use in the fopen() call. The problem is that MODX expects to find the page content in the database rather then in a file. There are several ways around that. What I would probably do is to name the files after the pagetitle of each page, then use a snippet on each page to read in the file content.

Say the files are named for the pagetitle and are in assets/myfiles/

You'd create a snippet called GetContent and put this tag in the page content or the template at the location where you want the content to appear:




The snippet code would look like this:

From what I understand, they won't be using MODx to generate the pages at all; the script that reads the ini file actually generates and writes the html file - basically performing the parsing and generating process like MODx does, only using ini files instead of the database for the content, and the parsing script itself instead of a template, and writing to file instead of serving right away. Like I said, rather redundant. But then I don't know the purpose behind it, so maybe it makes more sense than it appears.

It's certainly possible, but it seems a shame to load the whole MODX engine, then not take advantage of everything it can do for you in the way of content management, menus, templates, etc.