Jump to content

TweezerMan

Members
  • Posts

    1,763
  • Joined

  • Last visited

Everything posted by TweezerMan

  1. Yes, the script automatically does weekly (and monthly) backups. When the script runs each day, it checks today's day of the week to see if a weekly backup needs to be made, and it checks the day of the month to see if a monthly backup needs to be made (they're done on the 1st of each month).
  2. Minhea, you almost had it! The time offset you're trying to add needs to be inside the outermost parenthesis: >echo date($format, strtotime($entry['date'])+3600*6);
  3. The script should be set up in a cron job to run once per day. The only config option I see relating to time is the DOWEEKLY option, which tells the script what day of the week it should make weekly backups.
  4. Welcome to the forums, trefilov22!
  5. It looks to me like you've configured the MAILCONTENT option to "log" so the script would e-mail you the backup log. I'd recommend changing this option to "stdout" instead and let cron e-mail the log file to you.
  6. You shouldn't need to change any permissions settings. The problem is that the BACKUPDIR option in the script is not configured correctly. Whatever directory you store the backups in must be below your home directory on the server (/home/cpanelName - where 'cpanelName' is your CPanel username). If you wanted the backups to actually go into a "backups" directory, edit the script to the following: >BACKUPDIR="/home/cpanelName/backups" ...and change 'cpanelName' to your actual CPanel username. Hope this helps...
  7. There is a short tutorial about file permssions on the TCH Help web site. You might also read this forum topic on "File/folder Permissions" as well.
  8. a) Yes, you'd need a cron job to run the script normally. The cron job is what will run your script automatically on the day(s) and time you specify in the cron job. b) You'd specify the full server path to the script as the command to run. Example: >/home/cpanelName/public_html/automysqlbackup.sh I'd recommend setting the permissions on automysqlbackup.sh to 0744 so it's executable only by you.
  9. Welcome to the forums, Bob!
  10. The forums moderators here do not have the ability to access customer accounts, so you'd need to submit a ticket to the Help Desk.
  11. 1) Yes, you should remove the '.2.2' from the file name after uploading the script to the server. 2) You'd test it by setting up a cron job to run the script, wait for the cron job to run, then see if the script does what you configured it to do.
  12. You've got a couple of things not working in your favor at the moment: 1) Your Wordpress permalinks are not being generated correctly. Example: The entry that is linked with this URL: >http://www.chroniker.net/?p=70 ...is actually at this URL: >http://www.chroniker.net/blog/?p=70 2) Your permalinks are using an entry ID number for the link instead of the entry title. This makes it difficult to set up redirects from MT archive pages to Wordpress archive pages, as the entry ID numbers are not the same. Example: Entry #79 in MT is entry #70 in Wordpress. The redirects need to redirect from your actual MT archive URLs to the equivalent Wordpress archive URL. Example: >Redirect Permanent /mt/archives/2005/07/comment_spam.php http://www.chroniker.net/blog/?p=70 If you use an MT template to generate the MT archive URLs to be redirected from, you'll need to use the following snippet of template code to get the actual URL: >/mt/archives/<$MTEntryDate format="%Y/%m"$>/<$MTEntryBasename$>.php As your Wordpress links currently are, you'd need to use the following snippet of code to generate a dummy Wordpress URL: >http://www.chroniker.net/blog/?p=nn After you've generated the list of redirects, you'd have to look up the Wordpress entry ID numbers and replace the "nn" in each directive with the correct Wordpress entry ID number. The full code to generate the redirects would look like this: ><MTEntries lastn="999999"> Redirect Permanent /mt/archives/<$MTEntryDate format="%Y/%m"$>/<$MTEntryBasename$>.php http://www.chroniker.net/blog/?p=nn </MTEntries> Now I don't use Wordpress, but I read somewhere that you could change the format of your permalinks to use the entry title instead of the entry ID number if you wished. Both Matt's code, and Alex's templates, assume your Wordpress installation is indeed using permalinks in the format of /blog/archives/yyyy/mm/dd/entry-title/, and if you're not, you have to edit the code for the actual format of your links (like I did above with Matt's code). Once you have your list of redirects, they have to be placed in an .htaccess file that is in the directory path to the MT archive files. With your MT archives starting in the /public_html/mt/archives directory, the .htaccess file with the redirects could be placed in the /public_html, /public_html/mt, or /public_html/mt/archives directories. I'd recommend putting the .htaccess file in the /public_html directory. Take what I've written here with a grain of salt - as a non-Wordpress user, this is what looks like needs to happen from my point of view. Someone who actually knows Wordpress may be able to offer some better advice.
  13. I would suggest examining the .htaccess file and see if the code I posted above is in the file, and if it is, the easiest solution would be to delete the .htaccess file. It should be recreated when you run checksetup.pl again. Is it possible? Yes. Would I recommend it? Probably not. Anyone from the Help Desk who runs the checksetup.pl script for you will be running it as 'root'. Running as 'root', the script can set things that you may be prevented from changing or even accessing. One example is the .htaccess file discussed above. When you run checksetup.pl, the .htaccess file created will be owned by you, and you will have permission to edit it. Running as 'root', the .htaccess file will be owned by 'root' and you will not be able to modify it at all. I don't know what all the script does, but I would not be comfortable executing that script as 'root', knowing that I'm supposed to subsequently run Bugzilla without root privileges at all.
  14. I don't think what you're asking is possible. I think if you want your web images to be viewable by everyone, you'd need to place them in an unprotected directory.
  15. The checksetup.pl script writes an .htaccess file in the main Bugzilla directory to prevent others from doing what you're trying to do - run the script in a browser. From what I can tell, this is what would prevent you from running the script a second time in your browser: ><FilesMatch ^(.*\.pl|.*localconfig.*|runtests.sh)$> deny from all </FilesMatch> Among other things, it prevents any file ending in .pl from being called in a browser (including checksetup.pl).
  16. Glad to hear you got it working!
  17. Close your browser, restart the browser, then try browsing to a page in the protected directory. If you're prompted to enter a username and password, it's protected. If you're not prompted, it's not.
  18. Here's some more suggestions for you: 1) Remove the <center> and </center> tags from your code. They're not helping here. Whatever you're wanting to do, there's probably a better way to do it. 2) I realized that you don't have to unfloat the "side" div. Put the float back (float: right;), then add this code just before the last div (the "contain" div) in your HTML: ><br clear="both" /> 3) Set the left margin on the "side" div so that it clears the "blog" div: >margin-left: 450px;
  19. I see the issue in Firefox, but not IE. It looks to me the issue is caused by the fact that the "contain" div only contains "floated" divs. The "blog" div is floated left, and the "side" div is floated right. Floating a div removes it from what's known as the "text flow". Firefox is only using text that is part of the text flow to determine the height of the "contain" div, and there is no text within the "contain" div that is a part of its text flow. There's more to the page that you'll have to fix, but basically you need to "unfloat" the "side" div. Hope this helps...
  20. You might take at this thread, where this subject was discussed before.
  21. Another possible reason for an upload failure is that you've run out of disk space on your account.
  22. Welcome to the forums, PCWizard70!
  23. Welcome to the forums, atikal!
  24. Welcome to the forums, Jonas! The tutorial you're referring to was removed as the user who created the tutorial is no longer hosted here, and while the instructions were good for some, they did not work for everyone.
  25. Welcome to the forums, programthisweb!
×
×
  • Create New...