442GlenwoodAvenue

Seventeen years now, still no price increase. You're starting to make me feel guilty. What in the world were you thinking with a business model that rewards loyalty. One might think you actually want people to stay with you.

OK, I've updated to https. That seems to have taken care of the issue. Should have done that a long time ago. It used to be more complicated a few years ago when I looked into it. It's gotten easier over the years.

Thanks, I will look into this a little further. May have to finally get https.

Any idea why I would get this error message (Chrome only) when accessing the home page of my website? And there is no "default.html" file in the public directory (I've checked). Error doesn't appear when using Firefox or Edge. This is when only entering only hydroxystudy.info Sure, if I enter www.hydroxystudy.info it works. But not everyone will do this. Upon further testing, it appears the problem is related to Chrome automatically redirecting to https (secure). Firefox and Edge don't do that. However, there seems to be some interaction with TCM as well - such that the error message would be displayed.

Thanks, I will turn in a ticket if they mange to hack it again. For now, I've re-installed my website using iThemes backup buddy (a great program), which didn't take long. Before doing that, I deleted every single file in the public_html folder to make sure a backdoor wasn't left behind. And of course, I changed by username and password again. Once my website was re-installed, I increased security even more. Below is the logs from this morning. They are scanning for xmlrpc.php holes. I've now disabled xmlrpc in iThemes Security. I've also increased the 404 error setting to one try (before their IP is banned permanently), forcing them to use a different IP everytime. You can also see they are also looking for plugin weaknesses. 404 Error 2017-02-22 15:14:54 105.101.253.141 /xmlrpc.php Details 404 Error 2017-02-22 14:20:36 151.54.110.228 /xmlrpc.php Details 404 Error 2017-02-22 13:54:34 73.156.99.48 /xmlrpc.php Details 404 Error 2017-02-22 13:14:08 70.123.197.115 /xmlrpc.php Details 404 Error 2017-02-22 13:12:14 49.149.40.237 /xmlrpc.php Details 404 Error 2017-02-22 13:09:49 84.122.157.63 /xmlrpc.php Details 404 Error 2017-02-22 12:47:26 180.191.138.122 /xmlrpc.php Details 404 Error 2017-02-22 12:25:01 89.203.249.166 /xmlrpc.php Details 404 Error 2017-02-22 12:09:31 187.154.193.188 /xmlrpc.php Details 404 Error 2017-02-22 11:54:19 49.148.93.0 /xmlrpc.php Details 404 Error 2017-02-22 11:34:00 46.177.16.147 /xmlrpc.php Details 404 Error 2017-02-22 10:46:03 93.149.251.212 /xmlrpc.php Details 404 Error 2017-02-22 10:28:39 166.62.90.110 /wp-content/plugins/cherry-plugin/admin/import-export/wp-xml.php Details 404 Error 2017-02-22 10:20:49 116.44.82.81 /xmlrpc.php Details 404 Error 2017-02-22 10:02:56 114.76.133.108 /xmlrpc.php Details 404 Error 2017-02-22 09:46:57 104.131.54.177 /index_old.php Details 404 Error 2017-02-22 09:44:36 203.215.33.62 /xmlrpc.php Details 404 Error 2017-02-22 09:44:14 104.131.54.177 /database.php Details 404 Error 2017-02-22 09:43:11 104.131.54.177 /include.class.php Details 404 Error 2017-02-22 09:25:32 202.46.3.26 /xmlrpc.php

Well, someone has been trying to hack two of my Wordpress sites for several weeks. I was getting several notices from iThemes Security. They could never get even close to the username and password. IP location showed multiple places around the world. Over the last couple of days, they started some sort of scanning for vulnerable files - again I was notified by iThemes Security. I had security set pretty high, even one 404 and they would get locked out permanently. Even two wrong guesses on username and password, and they were locked out permanently. None the less, they somehow got in this morning at www.doman1.com and www.domain2.com. Fortunately, I had everything backed up with iThemes Backup Buddy (including data base), and I was back up within an hour (for one site). Problem is - if i don't know exactly how they got in, I don't know that they can't hack my site again. Therefore, I don't know where to go from here - to avoid it again? The message left on my main page (both sites)

Thanks for NOT having those! I don't think you've raised the price on my re-seller account in over ten years.

Turned in ticket. OK, didn't realize I was the one who controls this through my WHM account (reseller account). Problem solved.

I've used Wordpress on two of my sites and wanted to use WordPress on a third. Cpanel says I've used all my MySQL databases. Did I only get two? If I need another, what are my options?

Never mind, I found a work-around that gets around this file limit issue. I learned how to use one of the audio player plugins. I created an 'audio' folder on the server (per the plugin instructions), upload the audio file to that folder via ftp, and the plugin knows how to find it. Then, insert the following code into the Wordpress page, and everything is OK. [audio:yoursite.com/audio/yourfile.mp3]

Support changed to php.ini file limit to 20meg. I changed it to 80meg. I'm trying to upload a 36 meg file via the Wordpress 'media' link. Oddly, the Wordpress media link has now gone from a 2meg limit to an 8meg limit, even thought the php file limit was first changed to 20meg (via the support change), and then 80 meg (by me). I still can't upload a 36meg file. I tried a 1 meg file, and Wordpress took it. Why is there such a small limit to begin with? I can easily upload a 1gigabyte file via ftp. I tried using ftp to upload the 36meg mp3 file to the Wordpress 'uploads' folder, where all my other uploads are. The file is now there, but Wordpress doesn't recognize the file from inside the 'media' function. I'm trying to imbed an audio player, and I'm thinking the work-around it to upload the 36meg file onto one of my other sites, and then link to it.

As someone who is new to Wordpress, I'm getting this error message with relatively small files when uploading. All the solutions seem to point to the web host's php.ini file, which I can't find. I don't really understand why there is a limit to begin with. I can upload large files directly via FTP, so why is Wordpress affected? Can any wordpress experts enlighten me to the solution to this?

Headline from ICANN: Biggest Expansion to Internet in Forty Years Approved for Implementation http://www.icann.org/en/announcements/anno...-26jun08-en.htm

Wow, I wasn't expecting to get an answer from the mystery artist herself. Yes Natalie it was you. Mystery solved. I still listen to those mp3s around this time of the year. Glad to see you're still here. Thanks.

About four years ago, there was a female member who gave a link to some of her mp3 Christmas music. Normally you had to pay for her music, but she posted the link as a favor to this board. She had a nice voice and had a Christmas CD - and a website for fans. I've still got one of those Christmas mp3s, but have forgotten who she was. I'm sure someone will remember her name?

That fixed it, thanks.

I'll stick with http, since that seems to work OK. Now a new problem has occurred. The frontpage publish function uploads about 80% of my website and then fails with the following message: ================= 406 Not Acceptable Not Acceptable An appropriate representation of the requested resource /_vti_bin/_vti_aut/author.exe could not be found on this server. ================= I checked that folder, there is no "author.exe" file there. I re-installed frontpage extensions from cpanel, that file still isn't there. Is this something I can fix, or do I need a help ticket?

OK, that was an easy fix, thanks (changed it to http - yes, it was publishing to ftp).

I have several websites created in Frontpage - and all but one always publishes to the correct "public_html" folder on the tch server. But one website has suddenly started publishing to the root folder for that website. I can't find a setting in Frontpage 2002 that tells the publish function what server folder it's supposed to send the files to.

This is what Bob Parsons (godaddy) said about the issue on is web blog HERE

I have two .us domains registered privately through godaddy, and domains by proxy. Just checked - the whois info still shows it's private. Wonder what will happen in the future with this though. . . .

Tend to read more magazines than books: Popular Science, Popular Mechanics, Guideposts, Readers Digest, Prevention, PC World, Business Week, Digital Photography, Bowling This Month. Haven’t read books with a real story in over 30 years. Most books I’ve read recently have to do with nutrition or psychology. On the other hand, book with a story are about the ONLY thing my wife reads (romance novels).

Was just wondering how they disabled the ability to print the website below, from a browser. Print preview in IE 6.0 and Netscape 4.7 both show nothing but the web address at the bottom of the page - and if I try to print - nothing shows up but the page title and url at the bottom. http://www.digitalfaq.com/media/dvdmedia.htm OK, well actually the website tries to explain it, even though it's somewhat cryptic. They also give the work-around by allowing you to print via PDF. http://www.digitalfaq.com/howtoprint.htm But suppose they didn't give you the PDF way to print? That could be a intersting way to disable easy printing. It just seems strange that a web browser can't print what it is actually showing on your monitor. Has anyone seen anything like this before? 442

Well now, I see my "simple" reseller account just about doubled in space and bandwidth. Thanks. Scrubjayphotos.com

Turns out that the "default" address on one account was not set to my cpanel username. It was set to the default username that the web hosting manager uses with a new account. Thing is, I changed that - to a format I use for all my reseller accounts. Double checked it from my web hosting manager, it was set to what I changed it to. But somehow the web hosting manager default name stuck in my cpanel e-mail account. So, I changed the default e-mail address to match my cpanel name. NOW both accounts work the same (accept just about anything without bouncing). It appears this is the rule: If the default e-mail account is set to your cpanel name, it will accept anything until you set up filters. If the default e-mail is NOT the same as your cpanel name, it will bounce almost everything - until you add accounts. Well, that's what seems to be the case for now - after much experimenting.