Support

Hi Tim,

You are restoring to a temporary URL, not a real domain. This makes your .htaccess Maker setup incompatible with this temporary URL. Just rename your .htaccess file to something like htaccess.bak and when your site is ready to go live, go to .htaccess Maker, update the System Configuration settings and click on Save and Create .htaccess.

Hi Tim,

The first issue seems to be related with Joomla!'s cache, not server setup. When you assign a module suffix, this is tucked to the CSS class used in that module. If you have Joomla!'s cache enabled, the resulting HTML is cached and any change in the module suffix won't be reflected in the HTML output of your site unless the cache expires, you clean it manually or you disable it.

Regarding the second issue, Admin Tools can not block this function - but your host can! Ask your host what are the disabled_functions in their PHP setup. If they have included phpinfo in the list, then this page of Joomla! won't work, as the phpinfo() method used to produce the PHP information is no longer available.

You're welcome :)

Normally, if the cache is really operational, it will cause the same problem independent of the server environment it's running on. That's the purpose of the cache: to store the HTML output for a specific time in order to not have to generate it from scratch on every request, leading to considerable CPU usage reduction and, as a result, a faster loading site. My guess is that the cache wasn't really working on your old server.

Hi Tim,

I don't really know much about JomSocial, so I may be of limited help here. First, make sure that it's not Admin Tools blocking the request by taking a look at WAF's Security Exceptions Log and making sure there is no entry there.

If it's not WAF, I've seen a lot of servers with Apache mod_security2 installed which throw such error pages when you have a password with special characters (anything except numbers and letters). In this case, try using a simple password consisting of only numbers and letters. Does that work?

Hi Tim,

YOu are using a temporary URL (the one with ~username in it). .htaccess files generally do not play very well on those temporary URLs. I would suggest you to keep the .htaccess file turned off until when you launch the site. Then just go to .htaccess Maker, make sure the System Settings correspond to your new domain name and click on Save and Create .htaccess.

If you still have the same problem despite turning off the .htaccess file, please note that this means that you have a server issue. It could be something as simple as a conflict with the temporary URL you're using for your site, or a server-side protection kicking in as I explained in my last email. In both cases, only your host can help you out with that.

Hi Tim,

Admin Tools DOES NOT automatically create a .htaccess file for you. There is exactly one way to create a .htaccess file using Admin Tools and that is by using the .htaccess Maker page. There is also exactly one place where the domain name and directory is configured in .htaccess Maker, in the System Configuration pane. The first two options there need your domain name without the the http:// or https:// prefix and the last option needs the subdirectory, or / in the typical case where Joomla! is installed on the site's root.

The only other place where you might find a reference to an old domain name is the SEO and Link Tools page, but this domain name is used to redirect from, not redirect to, the old domain name.

Regarding the IP addresses you see in the query, this is the IP address of the user currently accessing the site, not the site's IP. Look at the query. It's checking to see if you're on a blacklist. How this IP ended up there? Well, you access your site from this IP, this IP is reported to the web server, the web server reports it to PHP and PHP reports it to Admin Tools.

Overall, I am convinced that your problems have nothing to do with Admin Tools but have everything to do with the use of a temporary URL which, as I have said a gazillion times, is known to cause issues. Redirections rarely work with a temporary URL and, guess what, Joomla! uses a ton of redirections, after each data modification step. Likewise for POST requests. Moreover, a temporary URL does not allow the web server to report the correct domain name and path to Joomla!, therefore you must edit your configuration.php file and set the $live_site parameter to your temporary URL, i.e. http://72.52.155.159/~fusworg in your case. Let me reiterate this: temporary URLs and Joomla! don't mix very well. Every time I've tried it, I've had huge issues. When activating the regular domain name on the host, all those weird problems ceased. My advice is to have a "spare" domain name and attach it to your in-development site instead of using a temporary URL. When you're done developing, attach the regular domain name to your site and you're done. Trust me, it will save your sanity.

Hi Tim,

Yeah, the temporary domain name is what most likely will do the trick. Temporary URLs are full of pitfalls :) Please let me know how it goes!

Hi Tim,

The password protection you get is most likely due to the .htaccess file inside your administrator directory. You seem to have used Admin Tools' "Administrator password protection" feature. You can either use that again to disable the password protection, or remove the .htaccess and .htpasswd files from the Administrator directory.

The 403 error is coming from Admin Tools. I will know exactly what happens once you do this:
- Trigger the 403
- Go to your site's back-end, Components, Admin Tools, Web Application Firewall, Security Exception Log. Take a look at the topmost row on the table. What is the Reason mentioned?

Hi Tim,

As mentioned in the documentation:

When enabled, Admin tools will try to detect common cross-site scripting (XSS) attacks and block them. The filtering is able to detect many such attacks, comprising of malicious Javascript and PHP code, but it can not be exhaustive. Hackers find new types of attack every day. You are advised to follow sane security practices (like updating all of your extensions and templates to their latest releases immediately) on top of using this feature.

If you're wondering what a cross-site scripting (XSS) attack may be, I recommend starting by reading the Wikipedia entry for XSS.

That said, no automatic XSS filtering is perfect. All XSS filters, including Admin Tools' XSSShield, are either incomplete or operate on a hairline trigger. I chose the latter approach, but it throws a lot of false positives - more so if you have a forum. Practically, I'd say that it's not even required. The architecturally correct solution to XSS is extensions escaping their user-originating output and all current versions of extensions coming from reputable developers do that. For example, I have turned it off on this site without any adverse effects.