IndexU Support

Lately there have been a whole host of customers saying their mod_rewrite no longer works. Here, for the record, is how to ensure your mod_rewrite is functioning and enabled.

Please Login or Register to read the rest of this content.

That is the complete process. If something doesn’t work after that it’s because you missed a step.

Remember that mod_rewrite does not work on IIS based servers. Yes mod_rewrite will work on a Windows server with apache, but NOT with IIS. This is a limitation of IIS and has nothing to do with IndexU.

Over the last month I’ve had reports from two users about this error

PHP Warning: readfile (themes/cleandex/images/pr///www.google.com/terms_of_service.html)

They did not know what the error meant. Well it’s quite obvious that their site has been banned from accessing Google (by domain name from what I can tell). The error message may vary slightly due to what theme you’re using, but it still ends with www.google.com/terms_of_service.html

The users had set their Pagerank Cache at a very low number (they did not tell me what they used) and their site literally abused Google and they were banned.

Lets look at an example. If you had 5000 visitors a day and had the cache set to 0 and those visitors looked at 10 pages each that would mean you’d be making 50,000 requests a day to Google.

That’s nothing but a denial of service attack!

Leave this setting at a minimum of 30. If you have a large amount of traffic you might even want to increase that number to lower your number of requests over a period of time.

It’s a known fact that Page Rank does not update once a month, so a setting of 30 is already low. If you’re desperate to update your PR numbers you can always flush the PR table in the database and then change your settings to a realistic number like 30 or 45.

Many users like to create custom fields as they add large amounts of functionality to your IndexU site.

But it’s a pain adding a lot of custom fields because the IndexU interface requires you to create them one by one.

What if I told you I know a way to add 5 or 50 or even 500 custom fields in less than five seconds? Would that save you a bunch of time? You bet it would!

I figured out this system when I had to modify 150 IndexU sites to upload custom databases to each one. Figuring that adding the custom fields manually to each one would take hours and hours I figured out how IndexU adds the fields to the database and was able to add the custom fields to all 150 sites in less than one hour total.

Please Login or Register to read the rest of this content.

One of the most commonly asked questions is how to edit the templates that come with IndexU. While this is really basic stuff some users just don’t know where to look or what to do to edit them.

The editing of template files does not need to be done via FTP, they can all be done in the admin panel providing your installed and setup your IndexU properly.

If you receive an error when saving these files that says anything about fwrite or fopen then you have not setup IndexU properly and you need to go back to the Install Guide and search for CHMOD

Please Login or Register to read the rest of this content.

This post shouldn’t really need to happen, but since I do support and see dozens of requests come in for help and the amount of sites that use simple passwords is amazing.

Let me give you an example of a few, without actually using their passwords. Yes some of these may be valid passwords for someone’s site but not to current knowledge any site that I have ever worked on.

First the username. By default the IndexU username is “admin” without the quotes. But this can be changed easily. How many sites have I worked on for customers that did NOT use admin as the username? One.

Seriously, just one.

Passwords are a different story. I have no idea how many times I’ve seen passwords set to simple words that are in pretty much every brute force directory that exists. Passwords like

• Passw0rd
• the site owners city name
• the site owners first name
• the site owners last name
• paperclip (I guess there were some nearby and it was something to type in)
• 1111111111 (not kidding on that one, 8-10 characters, all the same)
• the sites domain name (seriously!)

Of course you do realize, that if you use your name or city or address as your password, that information is usually public in your Whois record.

If you really want to keep your information and site secure then please use a strong password of at least 8 characters that uses a mixture of uppercase and lowercase letters, numbers and special characters (like $, %, ^, &, # etc). It’s combinations like those that make it MUCH harder to crack a sites password.

Remember that once a user has figured out your password and is in your admin panel the possibility that they now know your cpanel (or worse, WHM) password is greatly increased because most users use the same password for everything.

Now all they need to do is check your whois, see what your email address is, and try to log into your webmail account. Once there they can try to transfer your domains.

It’s not worth it to be lazy. If you really need to, write that password down on a piece of paper or a business card and place it in your wallet or in a CD case next to your computer. Heck you could write it on a cd and people might think it’s a CD Key for some program and not your password for your email or website.

My customers get assigned passwords, and most of them like it. The ones that don’t like it ask to have it changed and I flat out say no. It’s for my security as well. If someone is hosted on my server and gets hacked and their domain is suddenly trying to send out 50,000 emails per hour (wouldn’t happen due to limits, but it’s possible on some machines) then it would make me look bad, and could get my whole server blacklisted which would suck big time.

Take your time, and learn about what you’re doing. And if you need it, ask for help.

Some users may experience an issue when they or their host upgrades to the newest version(s) of PHP5.

The error should be obvious and state that there are issues in some files located in the ADODB folder.

The fix is quite simple

Please Login or Register to read the rest of this content.

So this is more of a rant than a tip, but believe it or not it comes up VERY often with users that are new to directory software like IndexU.

A user pays $99 for a copy of IndexU and another $65 for a copy of the Extreme DMOZ Extractor and since they CAN extract all of DMOZ they do.

Then they somehow manage to find a way to upload some of that data to their server and it dies, badly.

The complaints after that are “It’s IndexU’s fault because of this or that” and they blame it on various things.

The issue is not whether IndexU can handle the data, rather it’s can your server handle the data?

I don’t give a hoot if you have a dual Xeon with 4GB of ram and a 300GB hard drive. There is a LOT more to webhosting than just space.

These issues are things like disk performance, I/O, optimization and throughput. You cannot honestly expect a webserver (lets be honest, it’s almost the same as a PC) to run one million queries in less than a second so you can update your site quickly.

I don’t care what you think, it’s not possible because of the HARDWARE. Anyone who thinks they can run a mirror of DMOZ just because they have a hosting account or a dedicated server is just fooling themselves and proves that they know absolutely nothing about what they are doing.

Add to the fact that DMOZ already exists, and most major search engines use the DMOZ data anyways. You would be doing nothing more than getting yourself banned from search engines for duplicate content while adding your nightmares to my support tickets and emails.

Forget mirroring DMOZ, and make something unique.

No, I don’t like Mac’s, but recently two seperate users had the same issue with a Mac OS “feature”.

This tip is brought to you by Brad at communityseo.com and is basically a copy of his post there. I don’t claim credit for the post, only credit for finding the post.

Files which have the prefix of “.” are treated as core system files, because that’s how they’re named in Mac. So by default, Finder hides all these files completely - you can’t find them unless you have some knowledge of the Terminal. So, if you want to be able to grab your. htaccess file, follow these steps:

Please Login or Register to read the rest of this content.

Whatever you do, don’t reply to this post and try and convince me Mac’s are good.

Recently a customer installed IndexU on their host and received an error after installation. The error was

Unexpected character in input: ‘\’ (ASCII=92) state=1 in
/lib/link.class.php on line 1209

Parse error: syntax error, unexpected T_STRING in
/lib/link.class.php on line 1209

The issue was due to the hosts PHP configuration and the solution was to add the following Please Login or Register to read the rest of this content.

Thanks to Dody for providing this fix

I’m sure many of you have seen the “Spam Links” link in the admin panel and wondered how to use it. Unfortunately this is a poorly implimented feature due to where the links needed appear in the admin panel.

I have tested this for the title, url and description fields and it catches the keywords in every field.

Please Login or Register to read the rest of this content.

Hope you love this tip and it kicks some serious spam butt! If this tip helps to save you a lot of trouble please link to IndexUSupport.com.