TweezerMan
-
Posts
1,763 -
Joined
-
Last visited
Everything posted by TweezerMan
-
I don't know much about Google's AdSense, but it sounds to me like you've got your site set up in such a way that a user can get different content with essentially the same URL. I imagine that Google has to spider your web site in order to figure out what ads to send to you - it doesn't seem practical to me for Google to have to pull your dynamic page every time a user requests the same page in order to generate an ad that matches the current content. I don't see how mod_rewrite would help you. If I understand the issues correctly, your web site should display the same content each time the same URL is requested. It is certainly possible - this is what blog apps do, as well as CMS apps (content management systems). Storing content in a central database, publishing that content with templates set up in the system and writing the resulting pages to disk is the heart of what blogging and CMS apps were designed to do.
-
Graphic images aren't that safe either.
-
Coppermine Photo Gallery Version 1.3.2 Problem
TweezerMan replied to Prel's topic in Installing Scripts
abinidi had a similar problem today and was able to resolve it by clearing his internet cache. -
Welcome to the forums, jpepper! I don't really know anything about PHP's IMAP functions, but I did find the following in the PHP documentation (and comments): 1) imap_header() is an alias of imap_headerinfo() - they are the same function. 2) One comment noted that some IMAP servers don't support imap_headerinfo(), and recommended using imap_fetch_overview instead. 3) One comment noted that calling imap_headerinfo() after calling imap_body() didn't work for them - they had to change their script to call imap_headerinfo() before imap_body(). Beyond that, I think you'd need to post what code you're using and what error you're seeing (if any), and maybe someone here can figure out why it does not work.
-
Creative Commons offers a series of copyright licenses for authors. Authors choose an appropriate CC license specifying what rights users do and do not have with regards to the use of their original work, and the license chosen is displayed on the author's web site for all users to see. I did not see any way to submit your site to the Creative Commons search engine, but the HTML code they gave you should have included an img tag with a src attribute that links back to the CC web site. When someone browses your web site, the image will be pulled from the CC web servers, and they will know of your web site by looking at the referers in their web server's access log. I presume this is how the CC search engine will find out about your site. I don't know what you'd like to know about Creative Commons or their licenses. I know a little bit about them from the web and from the CC support built into Movable Type. About the only advice I have is choose your license carefully - some of the licenses can't be revoked if you change your mind.
-
I messed with the code in FrontPage and tested it both in IE and Firefox. I believe the problem is with the first table tag after the <body> tag: ><table align="center" width="800" height="100%"> Adding cellpadding="0" cellspacing="0" to the tag seemed to fix the problem: ><table align="center" width="800" height="100%" cellpadding="0" cellspacing="0">
-
Your Coppermine pages are working fine for me in both Firefox and IE6.
-
Thanks for the heads up!
-
I don't know if the times from last winter will be an hour off or not - that's why you should test my suggestion and see if it works, or makes things worse. For Eastern time zone, you should add: >putenv("TZ=EST5EDT"); ...to your script and see what it does. If it doesn't solve your problem, then just remove the line so your script is back as it was.
-
Welcome to the forums, jacobow!
-
The "www" in your domain is a symbolic link that is automatically redirected to your base domain (example.com). Using CPanel to redirect example.com to example.com/dir should work just fine, even if the user goes to www.example.com.
-
I don't know that you're doing anything wrong. phpMyAdmin's inclusion of character set and collation data in database exports is advertised as a feature that I don't any way to disable. Since phpMyAdmin doesn't appear to be able to export a MySQL 4.1.x database that can be imported into a MySQL 4.0.x server, I see two possible options: 1) Try having your host run the mysqldump command I indicated above manually. 2) Take the MySQL export file that you have now and open it in a text editor. Do a Search/Replace for: >CHARACTER SET latin1 COLLATE latin1_swedish ...and replace all occurences with nothing (delete the text everywhere it occurs). I don't know if the above text is exactly what's in your export file - you'll need to examine the file yourself and search for whatever text is there, similar to what I have above. Save the file, then see if it can be successfully imported. Hope this helps (again!)...
-
Welcome to the forums, Eric! Assuming TCH-Jim is correct that you are 1 timezone off from your web server, you could set an environment variable in your PHP script that would force PHP to calculate dates and times for your timezone instead of the server's. At the beginning of your script, add the following line: >putenv("TZ=PST8PDT"); Use the value for TZ below that corresponds to the timezone you're in (assuming U.S. timezones here): Pacific - PST8PDT Mountain - MST7MDT Central - CST6CDT Eastern - EST5EDT This should correct your timezone problem as well as automatically take Daylight Savings Time into account when it is in effect. After you've made this change to your script, I'd suggest checking the date/times that are already on your web page and make sure they're showing the correct date/time (that they're now not an hour off). If they are, you'll need to correct to date/time in the database. Hope this helps...
-
Welcome to the forums, LATD Inc! I didn't know phpMyAdmin had such an option (never seen it on either TCH servers or my own local install of phpMyAdmin). It would appear that the MYSQL323 option did not work, otherwise the COLLATE clauses/fields would not be in the exported dump file. They probably could if they had access to a MySQL server running 4.1.x. To my knowledge, all TCH servers are running MySQL 4.0.x. According to the MySQL documentation, the only way that data from a MySQL 4.1.x database can be downgraded and imported on a MySQL 4.0.x server is for the data to be exported from the MySQL 4.1.x server with the "--compatible=mysql40" option: The data must be exported from the MySQL 4.1.11 server with the "--compatible=mysql40" option so anything relating to COLLATE is removed. Your best bet is to try dumping the file again with the correct conversion options so it can be imported on a MySQL 4.0.x server. If phpMyAdmin can't do it, you may need your host to do it for you. Hope this helps...
-
I'll have to admit that I didn't know what you were talking about when you said: Digging around in the PHP documentation, I found a link to a page that explained the difference between event-based and DOM methods for reading XML documents pretty well (see the first 2 paragraphs). My first thought was that if you were wanting to ditch the PEAR class you're using, maybe you could use PHP's XML Parser Functions. But in reading the PHP documentation and the page I linked above, I realized that PHP's XML parser functions use an event-based parser. Searching again through the PHP documentation, I found PHP's DOM XML Functions. I don't know if you can make use of these, but it looks like they could do what you're looking for. Hope this helps...
-
Are we talking about the same kind of aggregator? What I mean by RSS aggregator is a client application that reads RSS feeds from multiple weblogs. It sounds to me like you're asking for a light weight XML parser - a library that you can use in your own script to read XML files. Am I understanding correctly?
-
Basically, yes. I have RSS/XML feeds on my MT weblog. The templates for these feeds are pretty much as you describe - they lay out XML structure and have MT-specific templates tags in them that tell MT where to insert data and content taken from the database. After the template is processed, the resulting XML page is simply written to a .xml file (which can then be read by an RSS aggregator).
-
The issue you're talking about is indeed a bug in MT 3.16, but it is only supposed to affect users who install MT to the root directory of their domain (the /public_html directory). If you installed MT 3.16 to a subdirectory below your public_html directory, you should not need this fix. This issue has been documented in the recently created Known Issues forum at the MT Forums site.
-
I tried creating sub-folders in SquirrelMail on my account, and this does not appear to work. When you go to the Folders page, type a name in the box and click "Create", the new folder created can only contain messages. I could not find any way to configure the new folder to allow creating sub-folders under the new folder. Under "Help" in SquirrelMail, topic 6.3 in "Folders" says the following: I do not see the "Let this folder contain subfolders." option in my SquirrelMail, so it would seem that you can only create top-level folder that contain only messages from within SquirrelMail. I did a little experimenting, and this process seems to allow creating folders that allow sub-folders: 1) Log out of SquirrelMail. 2) Log into your account with an FTP program, or log into your CPanel and go into File Manager. 3) Browse into the "mail" directory. 4) Within the "mail" directory, create a new directory with the name you want to use for the new top-level folder in SquirrelMail (such as "Saved Mail"). 5) Log out of your FTP program, or exit the CPanel File Manager. 6) Log back into SquirrelMail, and click on the "Folders" link. 7) At the bottom of the page, under "Unsubscribe/Subscribe", you should see the name of the new directory you created in the right column. Click on the name to select it, then click the "Subscribe" button. 8) Click the "refresh folder list" link to refresh the list of folders in the left column. The new top-level folder should now appear in the list. 9) Now if you type a name in the "Create Folder" box, the new top-level folder can be selected in the "as a subfolder of" drop-down box, and clicking "Create" will create the new message folder as a subfolder of the top-level folder. Hope this helps...
-
It does block all bots from reading those directories (if the bot does not have a specific section elsewhere in the robots.txt that applies to it), but only if they access those pages through your main domain. It won't block any bots going through a subdomain if you also have a subdomain set up for those directories. For each directory in the first list above that is also a subdomain, you should add a robots.txt file in the subdomain's directory that contains just the following: ># Disallow spidering of subdomain User-agent: * Disallow: /
-
Welcome to the forums, Oliver!
-
Descrepency In File Transfer To Domain
TweezerMan replied to queenpictoria's topic in CPanel and Site Maintenance
Actually, what's happening is that the files in question are probably being uploaded in ASCII mode, and during the transfer, Windows line ending characters (CR+LF) are converted to Linux line ending characters (just LF). The result is that one character is removed from every line in the file when it is uploaded. The file size in bytes on the Linux server will be smaller than the file size on Windows by the number of CR characters removed. Assuming the files in question are supposed to be uploaded in ASCII mode (like .html files, .php files, etc.), yes, this is natural and it is supposed to happen so the server can properly read the uploaded files. -
This is what I'm seeing in your current robots.txt file: ># Disallow directories User-agent: * Disallow: /blog/ Disallow: /guestbook/ Disallow: /momblog/ Disallow: /kathieblog/ Disallow: /shrinkydink/ Disallow: /webcam/ Disallow: /christmas/ Disallow: /myblog/ Disallow: /mompics/ User-agent: msnbot Disallow: / *.php User-agent: Slurp Disallow: / *.php User-agent: googlebot Disallow: / *.php Disallow: / *.jpg Disallow: /myblog/ # Disallow BecomeBot User-agent: BecomeBot Disallow: / User-agent: psbot Disallow: / This is what I would suggest changing: 1) I don't know if it is case-sensitive, but from what I've read, the user-agent for Google's bot is Googlebot, not googlebot, and probably should be specified that way in your robots.txt file: >User-agent: Googlebot 2) To block Googlebot from spidering php and jpg files, you shouldn't have a space between the "/' and the "*". I'd suggest using the following (taken from Google's web site): >Disallow: /*.php$ Disallow: /*.jpg$ The is above is an extension to the robots.txt file standard. Google understands it, and I believe msnbot does also, so I'd change the msnbot section to the following: >User-agent: msnbot Disallow: /*.php$ I do not know if Yahoo's bot (Slurp) understands this or not. Assuming it does, you'd need to change it's Disallow line like the above examples. If it does not, the line will probably have no effect, as wildcards are not a part of the robots.txt specification for Disallow directives. I'm not sure exactly what directories you want to ban which bots from spidering. As your robots.txt file currently is: - Yahoo's Slurp bot is not prevented from spidering any files or directories. If the Slurp bot understands "Disallow: /*.php$", it would not spider files ending in .php, but still not be prevented from spidering any specific directories. - Googlebot is currently prevented from spidering only the /myblog/ directory, and files ending in .php and .jpg (after you've made the changes I've specified above). - BecomeBot is correctly prevented from spidering any files or directories. - msnbot is prevented from spidering only files ending in .php (after you've made the change I specified above). msnbot is not prevented from spidering any specific directories. When a bot reads your robots.txt, it only looks at the section that applies to it if there is one there; otherwise, it looks at the "User-agent: *" section. A bot won't look at two sections of the robots.txt to figure out what it can and cannot spider. If you want specific bots to stay out of directories that you've specified in the "User-agent: *" section, these directories must be specified again in each bot's separate section. For example, msnbot, Slurp, and Googlebot are all free to spider the /blog/ directory of your web site. Yes, you do. If you don't have one in them, and the bots access your pages through the subdomain, there's nothing to prevent them from crawling the entire subdomain. Take your /myblog/ directory, for example, which you have set up as a subdomain. If a bot want to crawl your weblog through your main domain, it would do so with this URL: >http://www.gryfalia.com/myblog/ ...and it would try to read a robots.txt file from here, at the root of the domain: >http://www.gryfalia.com/robots.txt If the bot crawls your weblog through your subdomain instead, it would do so with this URL: >http://myblog.gryfalia.com/ ...and it would try to read a robots.txt file from here, at the root of the subdomain: >http://myblog.gryfalia.com/robots.txt To block Googlebot from spidering your /myblog/ directory through your main domain, you'd want to have the following in the robots.txt file in your public_html directory (which you currently have): >User-agent: Googlebot Disallow: /myblog/ And to block Googlebot from spidering your /myblog/ directory through your subdomain, you need to have the following in the robots.txt file in the /myblog/ subdomain directory: >User-agent: Googlebot Disallow: / Hope this helps...
-
Welcome to the forums, KyanVrezpor! You don't have to go through all of the subdirectories to set them to "No Index". Setting "No Index" in a parent directory automatically applies to all subdirectories (even though the Index Manager doesn't show you that or tell you).
-
GET makes a web page request through the web server, just like a browser does, and whatever the web server sends back is returned to the command. In a cron job, any output by a command is interpreted to be an error and e-mailed to the user. The "> /dev/null" discards the output from the GET command, so cron won't be triggered into sending an e-mail when you don't want it to. (Yes, it is probably needed.) Not too long ago, I tried using GET in a cron job on my account and it did not work. I had to use an alternate form of the GET command to get it working: >lwp-request -m GET http://www.my-TCH-site.com/path/to/file.php > /dev/null Instead of using GET, you might want to try the following in your cron job instead: >php -q /home/cpanelName/path/to/file.php This will work if the file has a shebang line for the first line of the file. Without it, a cron job can't run the script file directly. A PHP script would need the following as the first line in order to be run directly in a cron job: >#!/usr/bin/php