TweezerMan

When the page does not have a .php extension (like your .htm page example), the web server itself sends a "Last-Modified" header with the page. This is what your javascript reads when it calls 'document.lastModified;'. When the page has a .php extension, the server does not automatically send a "Last-Modified" header with the page. Since PHP is a dynamic language, the web server has no way to know on its own what the "Last-Modified" date of the page is, or indeed even if the page has changed at all. Since no "Last-Modified" header being sent when the page is PHP, it would appear that the "document.lastModified;" javascript is defaulting to "now", and this would explain why your date/time is changing every time the page is refreshed. To make the javascript work as you intend, you need to send your own "Last-Modified" header along with your page. One way to do this is to add the following code at the very beginning of your page (before even the "DOCTYPE" tag): ><?php $mtime=filemtime($_SERVER["SCRIPT_FILENAME"])-date("Z"); $gmt_mtime = date('D, d M Y H:i:s', $mtime) . ' GMT'; header("Last-Modified: ".$gmt_mtime); ?> With the above code in place, the time does not continually update every time you refresh the page.

Welcome to the TCH Forums, Chris! In the HTML source for your page, I see the following tag: ><base href=""> It would appear that Firefox ignores a <base> tag set as above, while Internet Explorer literally obeys it and is thus unable to locate anything with a relative URL (such as your stylesheet and images). I'd recommend either removing the <base> tag, or set its href attrribute to the URL of your site: ><base href="http://www.thaisilverbeads.com/">

I would think not. The IP banning in CPanel looks at the IP address of the machine that orginated the message. It does not matter what IP addresses (machines / servers / routers / etc.) the message had to pass through to get to you. I don't know what South Korea's internet infrastructure is like, but I imagine that the IP address you're talking about is a national ISP or backbone node. Unless the messages were initiated from that IP address, banning that IP address wouldn't gain you anything.

The UserComment text appears to be in Unicode encoding, as identified by the $computedvals['UserCommentEncoding'] field. I don't believe you can convert the encoding, as that would appear to require the mbstring (Multibyte String) extension, which is not enabled by default on TCH servers. I was able to get the UserComment to display correctly in the browser by printing a regular character on the same line with the UserComment text: ><?php echo (" " . $caption . " "); ?> I printed a space on both sides to maintain centering, although only one is necessary to make the browser display the UserComment text correctly. The UserComment text is still encoded, which you can see if you do a "ViewSource" on the page, but printing the extra space characters seems to alert the browser to do a conversion on the fly.

Unfortunately, there is no way for you to do this. Only the root user (i.e. the Help Desk) has the ability to change the owner of a file or directory. (This is a security restriction by the operating system.) You basically have two options here: 1) Ask the Help Desk to change the ownership of uploaded files from "nobody" to your user ID every time one or more files are uploaded. 2) Configure your script to run as CGI script. As a CGI script, your script would run under your user ID instead of "nobody", so any files uploaded and created by such a script would be automatically owned by you. You didn't say what script you were using for your photo gallery, so I don't know how feasible option #2 would be.

It depends on what you mean by "ok". At 0766 permissions, any user with an account on the same server as you, or a malicous user who has compromised any account on your server, has the ability to read the directory (list the files it contains), and create or delete files in that directory. Since Drupal is a PHP script, it is running as the user "nobody", and it apparently needs the ability to read and create files in that directory. Assuming you own the directory in question, the minimum permissions to allow this would be 0766. 0766 directory permissions are not really secure, but it is the only way you can allow Drupal to read and create the files it needs in that directory. I don't know what you've set up Drupal to use this directory for, but if Drupal only needs to create files in that directory during installation and not afterwards, you may be able to secure the directory further after installing Drupal by restricting the directory to read-only for everyone other than yourself by setting the directory permissions to 0744. I believe this would be the minimum permissions you could set on the directory and have Drupal still work without errors. As always, you should make regular backups of your files and databases so in the event of a compromise, you can restore your account back.

The "Error 1044" appears to be an "database access denied" error reported by the MySQL server. This error is normally reported as "Access denied for user 'db_username' to database 'my_database'". I'd suggest checking your database in CPanel / MySQL Databases and make sure that everything is still set up correctly (database exists, username exists, username is added to database), and check your cron jobs / scripts to make sure they are still using the correct username / password to connect to the MySQL server.

Generally, the database is used to store 1) information about your specific Gallery installation, and 2) information about your pictures and their organization. I don't currently have an installation of Gallery to look at, but I do have a Coppermine one. Information about your installation would include things such as the base URL of your photo gallery, the name of your gallery, authorized users and what permissions they have to do various things, how thumbnails are generated (or if), etc. Any settings that you can configure within the application will usually be stored in the database somewhere. Information about your pictures would include things such as the path and file name of the picture, the file size, the width and height, the number of times it has been viewed, its title and/or caption, which album it belongs to, comments and/or votes on the picture etc. You can browse your Gallery database with phpMyAdmin and see what exactly it's keeping track of if you really want to know the details. Hope this helps...

Images can be stored in a database (in a BLOB or BINARY type field), but they usually aren't. Image data stored in a database would have to be written to a temporary file before it could be displayed in a browser because <img> tags require real file names on the server. Continually having to create and delete temporary files on the server to display images would be a lot slower than just serving the image file directly from the server. Also, storing the image data in the database would greatly increase its size for little benefit.

This line appears to be the problem: >ini_set ('display_errors" 1); 1) 'display_errors" starts with a single quote and ends with a double quote, and 2) There is a comma missing between display_errors and the 1. The line should look like this: >ini_set ("display_errors", 1);

Your databases are stored on the same server your account is on, but they are in a directory that is not accessible by you. (They are stored outside of your /home/cpanel_username directory.)

After checking the things Tim has listed, if you still do not see any response from the server, one more thing to check is to make sure port 3306 is open in your firewall. The "I get no answer" makes me think your firewall could be blocking the connection, so whatever you're using to connect hangs because it's waiting for a response that's never going to come.

SpamLookup is a plugin that just happens to be provided by Six Apart. It's code is not a native part of MT. Trackback throttling is built into the MT code, and is one of the few (weak) defenses against trackback spam that MT natively has. Trackback throttling occurs early in the process of receiving a trackback (before a database record has been created for the trackback), while SpamLookup and other anti-spam plugins process trackbacks much later in the process (after the trackback has been accepted and a database record created for it). If a trackback has been throttled, SpamLookup and other anti-spam plugins won't even see it. If junk trackbacks are preventing you from pinging your own weblog, you can change the settings in MT as described above, or delete the junk trackbacks. You should be able to ping your weblog for at least a short time after deleting the junk trackbacks, until the spammers send enough trackback spams to trigger the throttling again.

Junk trackbacks are included when MT is counting the number of trackbacks received for throttling purposes.

SmartFTP will also show who owns the files in a server directory listing. All files and directories on the server have an owner. The user 'nobody' is a real, low-privileged user created by the system that can be used to limit what scripts can do on the system. PHP scripts on TCH servers run as the user 'nobody' for this reason. Actually, you can delete files you don't own *if* the directory containing the file you don't own has 0777 permissions. If you own the directory containing the file, you can change the directory's permissions to 0777, delete the file, then reset the directory permissions back to what they were (usually 0755). If 'nobody' owns the directory and it's permissions are not 0777, that would be a problem, as you can't change the permissions on directories you don't own. In that case, you'd need to ask the Help Desk to delete the file for you. If the file was created by a PHP script, it will be owned by 'nobody'. In any other case, the file will be owned by you.

The column you're interested in is the "Local Value" column: - The "Master Value" column contains the settings that are globally set for all PHP scripts across the entire server by the server's php.ini file. - The "Local Value" column contains the settings that are currently in effect for your PHP script. The "Local Value" settings may be different from the "Master Value" settings due to PHP directives in the web server's configuration file (which is most likely where the open_basedir directive is set for your TCH account), .htaccess directives, or ini_set calls in a PHP script. These are all applied after PHP has read the php.ini file. Since there a value for open_basedir in the "Local Value" column, you're okay on this issue.

Just a guess here, but I suspect the permissions on your files did not change because MT detected that the rebuilt files were identical to what was already on the server, so it skipped writing the files. This is normal and expected behavior for MT, as it preserves the "file modified" date on your weblog pages that have not changed (this keeps web browser caches working correctly, for example). I'd recommend deleting all of your weblog pages, then immediately rebuild your entire weblog to recreate your files with the proper permissions (which I see you did in your last post). Yes, it is. You can, but it's not the recommended way to do it. The HTMLPerms and UploadPerms setting were intended for situations where you needed to set executable permissions for your files, such as creating PHP files that need 0755 permissions. Also, neither of these settings affect directory permissions - the DirUmask setting is the only way to control them.

The permissions that MT sets on files is controlled by the HTMLUmask setting in your mt-config.cgi file (or mt.cfg). The default setting for HTMLUmask is 0111, which results in file permissions of 0666. In your mt-config.cgi / mt.cfg file, the HTMLUmask setting should be present, but is probably commented out (has a "#" at the beginning of the line): ># HTMLUmask 0022 If you remove the "#" from the beginning of the line, MT will use the HTMLUmask setting of '0022' and this will make MT create your weblog pages with 0644 permissions instead of 0666. There's 3 other settings that should be listed with HTMLUmask (also probably commented out): DBUmask, UploadUmask, and DirUmask. DBUmask is useful only if you're using BerkeleyDB for your database (which you're not). UploadUmask controls the permissions on files that you upload to the server with MT's "Upload File" function (such as images). DirUmask controls the permission on new directories that MT creates (such as new directories for each month or year of your weblog's archive pages). If you uncomment HTMLUmask, I'd recommend also uncommenting UploadUmask, so uploaded files will also be given 0644 permissions, and DirUmask, so new directories will be given 0755 permissions (instead of the default 0777, which is not very secure). After making the above changes, the settings in your mt-config.cgi / mt.cfg file should look like this: ># DBUmask 0022 HTMLUmask 0022 UploadUmask 0022 DirUmask 0022 This should resolve your issue.

I was just answering the questions that salguod initially asked: The existing tables in the database need to be dropped before doing the import. It's possible that the dump itself contains commands to drop any existing tables, but it's usually best not to assume that it does. You can drop them from phpMyAdmin, or you can ask the Help Desk to drop them for you. Yes, you can do both the dump and the import yourself, or you can have TCH do both for you. It's not really a matter of "should" - it's more what you're most comfortable with. If you want the Help Desk to do it for you, you need to specify in your Help Desk ticket to drop all existing tables in your database before doing the import. Prior to submitting your Help Desk ticket, you'll need to upload your MySQL dump file to the TCH server and provide the file name and location in your ticket so the Help Desk tech can find it.

The MySQL dump file will contain everything stored in your old database, including the templates, so those don't need to be backed up separately. Rather than delete the default weblog, what you need to do first is drop all of the existing tables in your MySQL database. This will delete everything that MT set up in the new database, including the default weblog. Then you can import the MySQL dump file from the database at your old host. If you don't drop the tables before doing the import, the import would most likely abort when it tries to create tables that already exist. You can drop a database's existing tables and import a MySQL dump file from phpMyAdmin, which is accessible from your CPanel. Click on the "MySQL Databases" icon/link, then click the "phpMyAdmin" link near the bottom of the page. If you have more than one database set up, you'll need to select the MT database from the drop-down on the left. You should then see a list of the table names within the database. To drop all of the tables, scroll down to just below the last table name and click the "Check all" link, then select "Drop" in the "With selected:" drop down. To import your MySQL dump file, click the "SQL" tab at the top of the page, and where it says "Or Location of the text file:", click the "Browse" and locate the MySQL dump file on your computer, then click the "Go" button to upload it and import it. If your MySQL dump is large, you may have problems importing it yourself with phpMyAdmin. In that case, you can upload your MySQL dump to your account with an FTP program, then open a ticket to the Help Desk and ask them to perform the import for you. Hope this helps...

I'm not sure if that IP address is a typo or not, but I think it should be 127.0.0.1, not 127.0.1.1. Your computer and web server normally aren't listening for connections on 127.0.1.1, and this probably would prevent the VirtualHost directives from working.

Glad to know the script change I suggested works the way you want it to! Assuming the duplicate <script> tags both referenced the same file, I don't suppose there would be any harm (nor do much good either). In this case though, the duplicate tags are not referencing the same file. In the <head> section of your page, you have this <script> tag: ><script type="text/javascript" src="/pool/jscript/jscript/global.js"></script> And just above your menu code, you have this <script> tag: ><script type="text/javascript" src="/pool/jscript/global.js"></script> The src path in the first <script> tag is not correct (there's an extra "/jscript" in the path), so it does not load anything, making the second <script> tag necessary for your menus to work. Just before both of the above tags are another set of duplicate <script> tags: ><script type="text/javascript" src="/pool/jscript/addloadevent.js"></script> I'd suggest fixing the link in the first <script> tag in the <head> section of your page, then removing the duplicates from the <body> section of your page. You also have some duplicate <link> tags referencing stylesheets. In the <head> section of your page, you have this link tag: ><link href="/Templates/assets/mycss.css" rel="stylesheet" type="text/css"> This file does not appear to exist, so it does nothing on your page. Right after that tag is the following <link> tag: ><link href="/assets/mycss.css" rel="stylesheet" type="text/css"> There is nothing wrong with this tag or its placement. Then, right after the <body> tag is a duplicate of the above tag: ><link href="/assets/mycss.css" rel="stylesheet" type="text/css"> This tag can be safely removed from your page. If you really want to get fancy, you could take the code from the addloadevent.js file (which is a single function with about 10 lines of code), add it to the bottom of your global.js file, then eliminate the <script> tag that loads addloadevent.js in your HTML. One <script> tag is better than two if you ask me! Hope this helps...

The menu initially appears fully expanded when a page is loaded because the menu's CSS is set up to show the entire menu. Your menu's javascript subsequently tweaks the CSS on the fly to collapse all of the years so the months are not displayed. Since javascript does not begin executing until a page has fully loaded, the menu is going to be fully visible for a short time. There really isn't any way around this behavior. If you code the CSS for your menu to hide all of the months, and someone visits your site with javascript disabled in their browser, they will never see the links nor have any way to access them. These visitors should see the menu fully expanded. There's more than one way for the menu to have a particular year stay open when clicking links within the menu. I tested some code I added to the prepareMenu() function to perform this task: >function prepareMenu() { if (!document.getElementById || !document.getElementsByTagName) return false; if (!document.getElementById("menu")) return false; var links = document.getElementById("menu").getElementsByTagName("a"); for (var i=0; i<links.length; i++) { links[i].onclick = function() { toggleMenu(this.parentNode.getElementsByTagName("UL")[0], this.href); return false; } if (links[i].href == window.location) { toggleMenu(links[i].parentNode.parentNode, links[i]); } } } This is the code I added: >if (links[i].href == window.location) { toggleMenu(links[i].parentNode.parentNode, links[i]); } When the browser is running this code, the page has already been loaded, and all of the years have been collapsed with javascript. The prepareMenu() function goes through all of the <a href> tags (links) in the menu and adds code to the year links to toggle the expansion and collapse of years when they are clicked. The code I added compares each menu link with the URL currently being displayed in the browser. If there is a match, the year containing that link is toggled again so it is displayed expanded (giving the effect that I believe you're wanting). It is working, but something is not right with the way you're including the files. You should not include an entire HTML document that has its own <html>, <head> and <body> tags into the <head> section of another HTML page - it's not valid HTML. If you look at the HTML source from one of your photo pages, you can see the extra <html>, <head> and <body> tags, as well as duplicated <head> elements such as <link> tags linking to your stylesheets and <script> tags linking to your javascripts. I can't tell from the HTML source what you're doing wrong, but I'm sure there a better way to do it that will generate valid HTML for your pages. Hope this helps...

The ">/dev/null" part of your cron command causes all output and errors to be discarded, so there would be nothing for cron to send you. If you want to see if there's any errors being reported, you'd need to temporarily remove that part of the cron command and test it again.

I see a few problems with your code: 1) Random number function outputs incorrect range of values: >var ranNum= Math.floor(Math.random()*4+1); This code outputs a random integer in the list of 1, 2, 3, 4. To get a random integer in the list of 1, 2, 3, you should multiply Math.random by 3, not 4: >var ranNum= Math.floor(Math.random()*3+1); 2) Code in link() function should not be in function at all. a) Using function name with same name as variable (array) can have unexpected results. >var plist = get_random() The above line of code should be in move() function so a new random integer is generated every time a new random link is needed (every 15 seconds in this case). c) >link = new Array(3) link[1]="net radio/test 1.m3u"; link[2]="net radio/test 2.m3u"; link[3]="net radio/test 3.m3u"; This code should be outside of any function, so the link[] array will only be defined once and will be accessible to any javascript code on the page for as long as the page is loaded. Side notes: Arrays in javascript are zero-based. Defining an array with 'new Array(3)' will give you an array with 3 elements - [0], [1], and [2]. When you code assigns link[3], javascript will automatically expand the array to 4 elements to contain it, but I'd recommend defining the array with 4 elements. >var time = null Also, the above line of code does not appear to server any purpose in this code. With the changes I've described above, your code would look like this: ><script language="JavaScript"> <!-- link = new Array(4) link[1]="net radio/test 1.m3u"; link[2]="net radio/test 2.m3u"; link[3]="net radio/test 3.m3u"; function get_random(){ var ranNum= Math.floor(Math.random()*3+1); return ranNum; } function move() { var plist = get_random() window.location = (link[plist]) } //--> </script> </head> <body> <script language="JavaScript"> <!-- var y = window.setInterval('move()', 15000); //--> </script> Hope this helps...