A while ago I already posted an article about problems getting SEF URL's work on 1&1-s servers and thought I know how to deal with the idiosyncrasies of 1&1's (very unprofessional) server settings. I was wrong...

After solving couple of times the "500 Internal Server Error" problem as described in a previous post, I received another complaint from one of my clients I host:

"I also cannot save the articles and here is the error I got
500 - An error has occurred!"

Easy cake - I was thinking, but after checking his account, discovered, that all settings described on that article (namely the collation settings in database) where correct.

Okay, you've installed your Joomla site, and want to began to master it. You click on the administrator link in the frontend and instantly hit the wall: a blank page is showing up. What's the deal? The cause is generally simple: This is happening almost always because your 'live-site' setting in your configuration.php file doesn't correspond with your Administration URL. You either have a www in your live-site setting in your configuration.php file and you are accessing your administration backend without the www or vice versa. It's highly recommended to correct this, the problem can impact even your site's Google rating.

Baba Yaga is an entity that haunts the dreams of children and a common threat that parents use when their children misbehave in Slavic countries across Eastern Europe.

But in the world of malware, BabaYaga is a form of malware that can update itself, use antivirus functionality and more. Much like the mythical creature, BabaYaga malware has the potential to haunt Joomla/WordPress or, in fact any PHP site administrators and IT support staff.

If you search on Google for the term "joomla can't login after moving to new server" - or something similar, you will get more, than 1 million hits for most of the combinations.

So, you aren't alone. And there are plenty of suggestions, on what might gone wrong and how you might find that, and there are verious fixes. But what if you moved the site to another domain? From development server to it's final place? This is a subject wich is rarely touched by those advices.

This warning message is produced by PHP if a program attempts to send an additional HTTP header after the separator (and hence all the headers) has already been sent. In the HTTP protocol a server response consists of a group of headers followed by a body, separated by a single blank line (i.e. a line containing only a carriage-return).

By comparing infected files with known good files (from official sources or reliably clean backups) you can identify and remove malicious changes.

Caution

To manually remove a malware infection from your Joomla! files:

1. Log into your server via SFTP or SSH.

2. Create a backup of the site files before making changes.

3. Search your files for reference to malicious domains or payloads you noted.

4. Identify recently changed files and confirm whether they are legitimate.

5. Review files flagged by the diff command during the core file integrity check.

6. Restore or compare suspicious files with clean backups or official sources.

7. Remove any suspicious or unfamiliar code from your custom files.

8. Test to verify the site is still operational after changes.

If you can't find the malicious content, try searching the web for malicious content, payloads, and domain names that you found in the first step. Chances are that someone else has already figured out how those domain names are involved in the hack you are attempting to clean.

Diff tools to compare suspicious files with known-good copies:

• DiffNow
• Diff (bash command)
• DiffChecker

Today one of my clients called me with this problem:

Was a weird call, and proven to be a difficult problem

You just finished a development of a new component/module/plugin, which has multilanguage support, or just finished a translation of such a Joomla addon and want to doublecheck the result, and don't know how to do it? Don't look further, Joomla supports some useful debugging mechanisms that can make it easier to locate untranslated strings and diagnose problems with language translations in installed extensions.

If your read this, then you might have playing with some code already - and as you know, nobody is perfect... all we make mistakes. But how you can find yours?

Do you have some old Joomla site (pre Joomla 1.5.6)? then is very likely you will got - or already have - a site running only halfway, full of errors saying

or

Yeah, you might allready guessed it, the PHP 4.* end of life-cycle is wreaking havoc in Joomla 1.0 sites and some early Joomla 1.5 implementations - or even newer sites, having badly coded third party extensions installed.

In another post about Function eregi() deprecated I provided some readily fixed Joomla 1.0 files to overcome issues related with upgrading to PHP 5.3 for Joomla 1.0 sites. But since a Joomla site is not built only from the core code, but there are other third party add-ons too, not only these older Joomla sites can be plagued by bad coding practices. The most problematic issues are related with templates. Most of the addons are fixed already, but you might have templates with unsupported functions. Here are couple of tricks wich might help you fix them!

Do you are an early adopter and you upgraded to Joomla 1.0.13? And you have Community Builder, VirtueMart or SMF Bridge...and you cant' login right now, and/or your users are complaining about the same problem. We're sorry for you... Do you have a backup? Then is simple, restore the Joomla 1.0.12 files, overwriting the actual files with those from the official distribution package and restore the jos_users or similar (or at least the passwords column from that).

Do you have backup, don't you? No??? Ouch... humm, then the job is a bit harder, but can be done!

So, still you can do the file restore? Good, do it. Then read below!

Since the release of Joomla 2.5 there has been a particularly annoying “duplicate template” bug that becomes clearly evident when you install or update a template. This has caused a great deal of confusion and consternation among Joomla users, but nobody offered an easy to use fix until recently. As anyone else in this business I hit the wall with this bug, until I found a cure for it on RocketTheme's blog.

Today I had a big surprise, several of my sites went out of business with the "Error: 500 - String could not be parsed as XML" message. I checked everything, and found no clues what can be happened. the sites weren't hacked, files or database has no signs to being tampered width or being damaged.

And usual bug-hunting tactics as unpublishing modules for example revealed also nothing.

Today I had to upgrade an old, Joomla 2.5.7 site to latest Joomla, everything went out fine until I had to do the first critical step - the upgrade from Joomla 2.5.28 to Joomla 3.51. Did I mentioned that server has PHP 5.6.25 withouth possibility to upgrade - at least not on short term?

OK, so, wasn't the best setup condition available, but usually this is not a dealbreaker.

And BUMM, I have seen an old "friend", a popup saying:

ERROR: Invalid login

Sometimes, if more people work on the site, you can get locked out of a certain module or article because the site thinks someone else is still editing that item. When opened, each Joomla item is checked out, this way Joomla protects each editable item from being edited by two separate users at the same itme, and this way avoiding potential confusion and other obvious problems.

A while ago I wrote a tip about problems geting SEF URL's work on 1&1-s servers. Back then I didn't realized, that the problem is the same - or at least fairly similar - on GoDaddy's servers too. Not everywhere, I have a site running on GoDaddy with sh404SEF without any need of tweaking the .htaccess file, but recently I had issues with another site.

So, the trick above solves the problem, but what is the cause?

Beginning with Joomla 1.6 it's possible to lock anyone out of the back end of the website — including Super Users with Admin permissions — by setting the Site Admin permission to Deny. And this is something you can do accidentally against yourself by playing with the permissions without knowing how exactly these settings are working. That can have unpleasant side effects especially at the Super User group or at the Manager or Administrator group level. If Manager or Administrator is set to Deny, the Super User would inherit Deny from these groups, even if the Super User group is set to Allow.

Anyone who maintained/developed something with or for Joomla, or needed to troubleshoot something on a misbehaving Joomla site knows the feeling: something does not working, and the available error messages aren't showing enough information to help you track down the root of the issue.

Any extra bit of info can help, so here is a tip for Joomla 1.7 which might help you got that.