TweezerMan

It looks to me like the links to the images are not set up correctly. One example: The first image on the above linked page is looking for the image at this location: >http://interstateband.com/photos/index.php?v=image&i=100x75&p=Shows/2005/Tracy_Gibson_Benefit/10_01_05_001.jpg Retrieving that link gets the following code instead of an image: ><p>[url_parts]: array(4) { [0]=> string(5) "Shows" [1]=> string(4) "2005" [2]=> string(20) "Tracy_Gibson_Benefit" [3]=> string(16) "10_01_05_001.jpg" } <br>[debug]: url_offset<br>[GET]: array(3) { ["v"]=> string(5) "image" ["i"]=> string(6) "100x75" ["p"]=> string(48) "Shows/2005/Tracy_Gibson_Benefit/10_01_05_001.jpg" } <br>[VIEW]: image<br>[INDEX]: 100x75<br>[IMAGE_FILE]: 10_01_05_001.jpg<br>[IMAGE_DIR]: Shows/2005/Tracy_Gibson_Benefit<br>[PATH]: /home/username/public_html/photos/images/Shows/2005/Tracy_Gibson_Benefit/10_01_05_001.jpg<br>[PATH_BASEDIR]: /home/username/public_html/photos/images/Shows/2005/Tracy_Gibson_Benefit<br>[resize_x]: 100<br>[resize_y]: 67<br>[image_x]: 480<br>[image_y]: 320<br>[cache]: array(4) { ["is_cached"]=> bool(true) ["name"]=> string(55) "Shows!2005!Tracy_Gibson_Benefit!10_01_05_001_100x67.jpg" ["path"]=> string(94) "/home/username/public_html/photos/cache/Shows!2005!Tracy_Gibson_Benefit!10_01_05_001_100x67.jpg" ["cache_url"]=> string(95) "http://interstateband.com/photos/cache//Shows!2005!Tracy_Gibson_Benefit!10_01_05_001_100x67.jpg" } A browser can't display this as a picture, so this would seem to be cause of your issue.

Assuming the error page is on the same domain as the web site, you really shouldn't use a full URL that includes the domain name (see here for details): >ErrorDocument 404 /wordpress/404.php

Welcome to the forums, tima89! The '-q' in '/usr/bin/php -q' only suppresses output of PHP headers that would normally be sent when outputting to a web browser. If you're wanting to get rid of the e-mail headers, that is something that the script itself would have to do.

The quick answer would be to right-click on the link and select "Save link as...". Longer answer: You might check how Windows itself is set up to handle .rar files: - Open a Windows Explorer window. - On the menu, click 'Tools', 'Folder Options...'. - Click the 'File Types' tab, wait for list of file extensions to fill window. - Scroll down to 'RAR', click once on it to select it, then click 'Advanced' button. - See if 'Confirm open after download' box is checked. I suspect it is not, and you'll probably want it check that box to change the behavior you're seeing. - Click 'OK', then click 'OK' again. Hope this helps...

Welcome to the forums, martynw!

Welcome to the forums, chrissy!

Yeah, I was assuming you had your own installation of Mailman. I'm not sure if you can customize the 'Welcome' e-mail for a mailing list set up in CPanel's mailman, but I suspect not.

To verify if magic_quotes_gpc is really enabled in the directory SugarCRM is installed in, you should run a phpinfo script that is located in the SugarCRM directory: ><?php phpinfo(); ?> If this phpinfo script indicates that magic_quotes_gpc is on, then I don't think its being enabled/disabled is what's causing your problem. If the script indicates that magic_quotes_gpc is off, then I'd suggest examining any .htacess files you might have in the /public_html directory and each directory down to your SugarCRM directory. Look for any .htaccess directives that turn off magic_quotes_gpc, or any directives that may prevent you from setting magic_quotes_gpc (such as an 'AllowOverride None' directive).

The passwords in the mt_author table are 'hashed', which could be described as 'scrambled'. This is normal. DBD::Pg and DBD::SQLite are the Perl modules necessary for using PostgreSQL and SQLite, respectively, for your MT database. Since you're using MySQL for your MT database, you do not need these modules and you can safely ignore these warnings. The queries I was referring to would be in a MySQL database backup you made of your MT database while it was on server 101. If you don't have a MySQL database backup from server 101, I think your best bet would be to enlist assistance from the Help Desk. If your data is still present on server 101, the Help Desk should be able to re-copy your database over again. If your data is no longer present on server 101, the Help Desk may be able to retrieve a copy of your database from a recent server 101 backup. If you still have access to your account on server 101, you could perform a backup (export) of the MT database yourself with phpMyAdmin, download it to your PC, then restore (import) it on server 90 with phpMyAdmin. If the database backup is too large, you can upload the server 101 database backup to your account on server 90 then ask the Help Desk to restore it. The ability to do this depends on whether 1) you still have access to your account on server 101, and 2) your MT database has not yet been deleted from server 101. Hope this helps...

It sounds like, at a minimum, maybe the mt_author table in the old server 90 database did not get replaced with a new copy from the server 101 database when your account was migrated back to server 90. Is it possible? Yes. It's not something that is supposed to happen though. If you have a backup of your MT database from when your account was on server 101, you could try copying out the queries just for the mt_author table and running them on your server 90 database to restore the table to what it should be. You could also submit a ticket to the Help Desk, explaining that your database does not appear to be completely copied over from server 101 and see if they can try to copy it again (assuming it's still present on server 101).

Welcome to the forums, DPK! As there are a number of ways to perform a redirect, it would help a lot if you posted exactly how you did the redirect to main.php.

Assuming the migration was performed correctly and without incident, the only issue I know of that might affect an MT installation would be DNS caching / propogation. A specific error message (whatever is displayed in the browser, or recorded in the web server error log) would help a lot in tracking down the source of the problem.

I don't believe you would create the directory structure at the root of your domain unless you installed mailman at the root of your domain. I believe you could accomplish what you want by doing the following: 1) Download <mailman base dir>/templates/subscribeack.txt to your PC with your FTP program (using ASCII mode). 2) Edit the subscribeack.txt as necessary. 3) In your FTP program, create the directory <mailman base dir>/lists/<yourlist>/en on the server. 4) Upload the edited subscribeack.txt file to the directory you created in step 3 with your FTP program (using ASCII mode). This isn't the only way to do this, but it generally covers the steps you'd need to perform.

That error can be caused by a number of things: 1) the database username is not correct, 2) the database password is not correct, 3) the database user has not been properly added to the database (granting the database user permission to access the database). I don't know if this is relevant, but you have 'cpanelusernamename_dbusername' for the database username and 'cpanelname_dbname' for the database name. These should be both be prefixed with the same thing - your CPanel username and an underscore ('cpanelname_'). You might try looking at sites such as hotscripts.com for something like that.

Welcome to the forums, shane! The text of database error that is occurring would be helpful. Just from what you've described, I'm wondering if 1) magic_quotes_gpc should be off instead of on, or 2) there's a bug in sugarcrm. By the time a script is updating a database with submitted form data, it should have already dealt with whether the form data was escaped due to the magic_quotes_gpc setting or not. (If magic_quotes_gpc is on, then the data should be unescaped with stripslashes().) Before the update query is sent to the MySQL server, the query string should then be escaped with mysql_real_escape_string(). The error message from the MySQL server should indicate whether a quote in your submitted form data is double-encoded, or not encoded at all. If quotes are being double-encoded, you might try setting magic_quotes_gpc to off and see if the errors continue to occur. If quotes are not being encoded at all, that would seem to point at a possible bug in sugarcrm to me.

Putting a 'no-cache' meta tag in your page could slow the loading of your page a little when a visitor views your page again and it had not changed. Because the page would not be cached on the first visit, a second view of the page would result in the server re-sending the same page again instead of the browser retrieving it from the local cache. For what you described, I don't believe you would need a 'no-cache' meta tag. The default settings for Internet Explorer, for example, automatically check for a newer version of a page if the page was last viewed in a prior session of IE, or on a previous day. In the case you describe, IE would display the new content since the page was last viewed on a different day and most likely a different session of IE.

Support for NeoMail was terminated about 2 months ago. It is supposed to be completely removed from the servers, so there would be no way for you to 'get access' to NeoMail.

I believe the path would be more like the following: >$awstats_dir = '/home/cpanelName/tmp/awstats'; ...where 'cpanelName' is the username you use to log into CPanel.

It's not the permissions on picEditor.php that Coppermine is complaining about - it's the permissions on the file albums/edit/NewT.jpg in your Coppermine directory.

Welcome to the forums, Tony!

According to one of comments in the PHP documentation, it just doesn't work. You might try setting this option in your .htaccess file instead: >php_flag session.use_trans_sid off

Welcome to the forums, upchuck!

Welcome to the forums. yyk! TCH does not officially support any third-party scripts (including Movable Type), but the servers are certainly capable of running Movable Type.

a) The log we're been talking about here is the web server access log. The format of entries in the server access log makes no accomodation for error messages, because error messages are stored in their own log. Go to CPanel / Error Log in your browser to see the last 300 entries of the web server error log. b) The date/time stamps in the server access log are in the local time zone of the server. The date/time stamps will not always have a timezone offset of '-0400'. The timezone offset of '-0400' is Eastern Daylight Time (meaning we're currently in daylight savings time and the server timezone offset already reflects it). When daylight savings time ends (the last Sunday of this month). the timezone offset should change to '-0500' (Eastern Standard Time).

Welcome to the forums, Bennett!