TweezerMan

Yes. Honestly, I would have already tested the script with that cron command (without the '> /dev/null' part) to see if there were indeed any problems or not. If there are any issues, they can occur in any code that is run by the script. The code in included files is run just like the main script code, so there is nothing that would prevent an issue from being in an included file as opposed to the main script. The cron job you were previously trying to run started lynx, which in turn sends a request to the web server for your script. The fact that lynx is no longer available was a direct issue for your cron job. The reason you may need to make modifications to your script is due to the reason why whoever wrote the script required the use of lynx (or GET or wget). When a PHP script is run in the method I described, the PHP environment that the script will be running in is not the same. If a script depends on PHP variables that exist only when the script is called in a browser, the script won't work correctly when it is running outside of a web server environment (like it is when it is called with 'php -q'). A simple example of this: When a PHP script is run in a browser, the PHP variable $_SERVER['DOCUMENT_ROOT'] can be used to help determine the path to a script (for example, an included file). Since the script is running in a web server environment, PHP is able to get the location of DOCUMENT_ROOT from the web server. However, when that same script is called with 'php -q' in a cron job, the web server is not involved at all and does not exist in terms of this PHP environment. The PHP variable $_SERVER['DOCUMENT_ROOT'] will be empty. Script code that tries to use this variable to generate the path to a script file in this case will come up with an incorrect / incomplete path. Other PHP variables that have to do with an HTTP (browser) request are similarly affeted - variables such as $_SERVER['HTTP_REFERER'], $_SERVER['HTTP_QUERY_STRING'], and $_SERVER['REQUEST_URI'] also don't exist when a script is called with 'php -q' - because there is no browser request, no browser, no web server to get these variables from. Any modifications that might be need to made to your script would change the use of variables like these so your code uses variables that do exist in the PHP environment it is running in. They usually do, but it is not a certainty. It depends on the script code actually being run. The author of a script usually has a reason for requiring a script to be run with lynx/GET/wget in a cron job (it usually won't work as it is without it).

At line 30 in the code you posted: >$message = $_SERVER[REMOTE_ADDR]. " -- ". ... ...the variable '$_SERVER[REMOTE_ADDR]' will not exist. Since it's just being used to construct a string, I'm not sure that there would be any harm in leaving it as it is though. I have a feeling that the real problems are in the file your script includes at line 2: >include("../include/common.php"); ...and possibly any files that common.php includes as well. You'd need to examine the code in common.php to see if there are any problems in its code.

I was not aware that curl had been disabled, but it's not surprising, considering that it is in the same class of commands as lynx, GET, and wget. None of the example commands you have listed will work on TCH servers, as all of those commands have been disabled. It is true that TCH made a conscious decision to remove access to curl, lynx, GET, and wget. I don't see that decision being changed any time soon. Fixing your script to run in an environment where those tools are not available falls under the category of '3rd party script support' though, and it is not something that the TCH Help Desk really can help with. Your script needs to be modified to run so it does not depend on these commands. Usually, it does not take a lot modification to make scripts such as yours work, but what exactly would be required depends on the exact code that is in your script. You may want to look at prior forum topics on this issue.

Partly. (Mostly?) In the above command, rather than using a URL as the location of the script (which could, in theory, be on any server, not just the server hosting your TCH account), you're telling PHP to run a script that stored on the local server's file system (disk drive). Yes, it is an actual directory name. Your account is set up in the /home/cpanelName directory on your server, where 'cpanelName' is the user name you use to log into CPanel. The subdirectories you see when you log into your account with an FTP program, or when you look at the files and directories in your account with CPanel's File Manager, are subdirectories of the /home/cpanelName directory that is the base of your hosting account. CPanel does not offer any direct way to see if a cron job was executed. If you want some sort of notification that a cron job was run (for example, when testing your script to verify that it is indeed running and working), there's two common ways I'm aware of to do this: 1) Add some code to your script that will add an entry to a log file in your account each time the script is run. 2) Modify the cron job so that it does not have '> /dev/null' at the end, and if the script does not do so already, add an 'echo' command to your script so it produces some output. When a cron job is run, if the command produces any output, cron assumes this indication of an error and will e-mail the output text to you (to the e-mail address you've configured in the Cron Jobs applet in CPanel).

I'm a little fuzzy on some of the details here, but I think you're having trouble getting the DOS download to work because you're not installing/using it correctly. What you're supposed to do with the DOS download is use it to create a bootable diskette that contains the partitioning and drive overlay software on it. Per the instructions on the WD site, this is what you're supposed to do: 1) Download the dlgsetup11_dos.zip file onto another machine that is working and running some version of Windows. 2) Using a program such as WinZip, extract the contents of the dlgsetup11_dos.zip file somewhere (such as your desktop). There is only one file in the archive, named 'diskette.exe'. This is the point where I believe you are misunderstanding the instructions. The purpose of the 'diskette.exe' file is to create a bootable floppy disk for you containing the partitioning and drive overlay software. It is a Windows-based program, and if you copied this program to a CD and tried to run it from a DOS prompt, I imagine it would tell you that it needs 'win32' (a Windows environment to run in). 3) Still on the same machine where you extracted 'diskette.exe', run the 'diskette.exe' file (double-click its icon on the desktop if you extracted it there). 4) Read and agree to the license agreement. 5) You should be prompted to insert a blank 3.5" diskette, after which you would click the "Start" button. From here, the program should do whatever it needs to do to create the bootable diskette. 6) Once the bootable diskette has been created, you should then exit the program. 7) Insert the new bootable diskette into the computer with the new 120GB, and boot up the computer with this diskette (*not* your bootable Win98 diskette). 8) Once the computer has booted up, the diskette should automatically start up the disk tools without you having to do anything. Assuming the instructions are correct, you should eventually be presented with a menu, from where you can choose "SETUP YOUR HARD DRIVE" and other options. (Booting up from a floppy is slow. ) I think this should resolve the issue that you're experiencing and get you going again. Hope this helps...

I'm using the PSPad text editor. It indicates in the status bar at the bottom of the window that the file has Windows (DOS) style line breaks in it. I also looked at the file in a hex editor. This file has both Mac-style (described as \r or CR) and Windows-style (described as \r\n or CR/LF) line breaks intermingled in the file - the non-extra lines have Mac-style line breaks, and the extra blank lines that have been added to the export file have Windows-style line breaks. Ideally, this file should have Linux-style line breaks in it only (described as \n or LF). Your browser is displaying the file single-spaced because it is only seeing and displaying one style of line break (probably the Windows-style line breaks) and ignoring the other one (the Mac-style line breaks). Your previous file did have only Linux-style line breaks in it. I'm at a loss to explain why the line breaks in your file have changed so dramatically.

You would probably end up running your script like this in a cron job: >php -q /home/cpanelName/public_html/admin/expire.php > /dev/null Your script will still be run from a cron job. The above command invokes PHP directly to run your script without a browser and without calling it through the web server. Whether or not you have another script written is up to you, but it's usually not necessary. You should be able to get your script to run by making at most a few changes to the script. What exactly would be required would depend on the actual code in your script, but you can see an example of one such case here. Adding about 10 lines of code was all that particular script needed to be run in a cron job without requiring lynx/GET/wget.

The file appears to be double-spaced (there's an extra blank line inserted after each proper line in the file), and the file has Windows-style line breaks in it instead of Linux-style line breaks.

Welcome to the forums, clickit55!

Welcome to the forums, Mary Beth!

lynx is a text-based browser. What your developer is saying is that he can browse to the URL of the script from a browser on his machine (could be lynx, could be IE or Firefox) and it works as expected. What you're trying to do in your cron job is basically the same thing - to open a browser and run your script in it. The problem is that on TCH servers, there is no longer any access to any command-line browsers (lynx, GET, and wget) that can be used to call your script through the web server. Yes, scripts can be rewritten so they do not depend on be called through a browser. There are usually some differences in the PHP environment that have to be taken into account; once they are, the script should work just fine. There is, but the '>> /dev/null' part of your command is throwing away all output from the command, including error messages. (Note: The '>>' really should just be '>'.)

Welcome to the forums, dj2000!

Welcome to the forums, schwascore!

I believe MT is not importing your entries because there is no value for 'DATE:' in the export file. Your template does also appear to need a line feed after the last line.

The file you linked to is the same as what you posted above - it's the Picasa template, not the actual export file that you would import into MT.

I don't see anything obviously wrong with your template, but ultimately it's the actual export file that Picasa produces that's important, and that's really what should be looked at. The only suggestion I have on your template is that the very last line may need a line feed after it (there doesn't appear to be one in the code you posted). If you can make a copy of your export file available on your web site and post the URL to it, then we can look at the same thing MT is looking at and try to spot whatever MT is objecting to.

Welcome to the forums, Ben!

If you don't already have it visible, you need to turn on the 'Tool Options Palette' by clicking 'View', then 'Toolbars', then checking 'Tool Options Palette'. Once you have the 'Tool Options Palette' visible, you can set the line width on the 'A' tab (Text) of the 'Tool Options Palette' window by setting the 'Width' option.

With transparent session IDs enabled, PHP is able to silently rewrite relative URLs on your site to contain the PHP session ID. This is necessary only if cookies are not enabled in the user's browser to save the session ID in instead. Normally you wouldn't want the session ID to show up in URLs to your site because 1) they make your site URLs long and ugly, 2) they can mess up search engines trying to spider your forums, and 3) they can be a security risk. I've never run a phpBB forum and I don't have direct experience with this issue, so you should probably take what I've written here with a grain of salt. Your forums should be okay, but I can't be 100% sure or guarantee that they will. If this suggestion does not work out for you, it is easy enough to undo it though. Nice to meet you, Tony!

As near as I can tell by searching Google, this is a conflict between the use of gzip compression and transparent session IDs in PHP. The recommended solution is to add the following to your .htaccess file: >php_flag session.use_trans_sid off ...which will disable the use of transparent session IDs. Or, you could disable the use of gzip compression in your script (phpBB in this case). I see this error only when there is no PHPSESSID cookie stored on my machine (from www.bloggy.biz). When browsing to the page for the first time, I see the error, but the PHPSESSID cookie is also created, and subsequent views of the page do not display this error. If I delete the PHPSESSID cookie and visit the page again, I again see the error just for that one page (because the PHPSESSID cookie is recreated). Hope this helps...

Welcome to the forums, Bill, and thanks!

Welcome to the forums, mr_gerg!

There's three parts you'd need to delete to completely remove Movable Type: 1) MT application files - the MT *.cgi and *.pm files you installed on the server that actually comprise the MT application. 2) MySQL database - the database you created in CPanel to hold your MT weblog data. 3) MT index and archive pages - the pages MT produced as the visible pages for your weblog. Hope this helps...

Welcome to the forums, PathDæmon!

Bots aren't always that smart - many will keep beating their head on that brick wall .