Ошибка error displaying the error page application instantiation error could not connect to mysql

Из этого туториала вы узнаете, как исправить ошибки подключения к базе данных, которые могут возникнуть в процессе установки шаблона или движка Joomla.

Решение ошибок в Joomla. Как исправить ошибки подключения к базе данных

Чаще всего, если вы видите на сайте сообщение «Проблема подключения к базе данных (2): невозможно подключиться к mysql (Database connection error (2): could not connect to mysql)», то в файле configuration.php , что отвечает за настройку параметров Joomla неверно указано название базы данных или же пользователя базы. Для того, чтобы исправить эту ошибку, проверьте, правильно ли указаны данные в файле configuration.php, такие, как имя пользователя MySQL и пароль. Пожалуйста, следуйте этой пошаговой инструкции:

1. Соединитесь с FTP или откройте менеджер файлов в панели управления хостинга. В корневой папке Joomla найдите файл configuration.php.

2. Откройте этот файл с помощью любого текстового редактора и проверьте детали доступа к базе данных. Они указаны в файле следующим образом:

   	public $user = 'amina';
   	public $password = '784512';
   

3. Пожалуйста, сравните указанные детали с теми, которые использовались при установке шаблона, они должны совпадать. Если они отличаются, исправьте данные, указанные в файле configuration.php. Обязательно сохраните изменения.

   Если же вы уверены, что все настройки заданы правильно, рекомендуется сбросить пароль пользователя базы данных и указать в файле configuration.php новый пароль. Так вы убедитесь, что в файле указан правильный пароль для доступа к базе данных.

4. Обновите страницу и проверьте сайт, теперь он должен отображаться правильно.

Если на сайте вы видите сообщение «Проблема подключения к базе данных (3): невозможно подключиться к базе данных (Database connection error (3): Could not connect to database)», это значит, что сайт пытается подключиться к неправильному серверу базы данных. В большинстве установок Joomla, файлы Joomla и база данных соединяются с одним и тем же сервером. В таком случае, в качестве сервера базы данных надо указывать «localhost«.

Для исправления ошибки проверьте настройки в файле configuration.php и убедитесь, что сервер базы данных указан, как «localhost». Если же это не помогает, можно проверить правильный адрес сервера базы данных в панели phpMyAdmin над меню. На скриншоте ниже представлен пример:

1. Синим обозначено адрес сервера базы данных.

2. Зеленым обозначено название базы данных.

Вы также можете столкнуться с сообщением «Проблема отображения страницы ошибок: Ошибка Создания примера приложения: Не удается подключиться к MySQL (Error displaying the error page: Application Instantiation Error: Could not connect to MySQL)». В этом случае надо проверять все детали базы данных, указанные в файле configuration.php: пользователя базы данных, пароль доступа к базе данных, название базы данных и адрес сервера базы данных. Детально описано на скриншоте:

Это конец туториала. Теперь вы знаете, как исправить ошибки подключения к базе данных.

Также воспользуйтесь детальным видео-туториалом:

Решение ошибок в Joomla. Как исправить ошибки подключения к базе данных

Господа, не парьтесь, я Вам объясню что происходит. Я пять лет веду сайты, но прозрел только сейчас. Дело не в посетителях и ботах, а в самой структуре сайта. Если сайт не большой, то и проблема не проявляется, если же у Вас много модулей и элементов для кэширования, то в них и подвох. Хостер видимо Вам, как и мне, ответил, что одновременное обращение с 10 запросами, или что-то вроде этого, к базе данных ее блокирует и это нормальное ограничение. Вы подумали боты? Нифига. Это Ваши клоны модулей скорее всего обратились к базе данных за обновлением кэша, ведь у вас поди стоит в общих настройках обновлять кэш каждые, ну скажем, 15 минут, а этот параметр по умолчанию распространяет этот режим обновление кэша на всю требуху Вашего сайта, где Вы руками не выставили что-то иное, где выставить можно конечно. Вот и получается, что Ваш же сайт, его составляющие, каждые, ну скажем, те же 15 минут просто дают пинка между ног процессору и базе данных и запрос в базу идет от одного как бы посетителя Вашего сайта и имя этому посетителю ваш сайт, а если кэш обновлять еще чаще. то вообще можно процессор сервера ввести в резонанс. Какой выход? Заходить и ручками прописывать обновления кэша в каждый модуль, особенно одного типа, и выставлять там совершенно разные значения, чтобы не было в какой-то момент несколько десятков одних и тех же запросов к базе данных на обновление данных в кэше. И не стесняйтесь ставить обновление кэша сутки и более на те элементы, которые у Вас на сайте не обновляются вовсе, или днями, неделями и месяцами. Не надо никакого шаманства с кодом, обращений к хостеру с просьбами, мне кажется этот метод у Вас сразу разгрузит систему и для хостера Вы уйдете в подполье…

↑ Note the change of topic subject above.

Thank you, @jasper_coetzee, for your replies and informing us that:

1. you have succeeded in disabling the Official Facebook Pixel plugin that you installed—you will find the installation files in the folder ../plugins/system/officialfacebookpixel; and
2. installing this plugin has nothing to do with the database connection error.

jasper_coetzee wrote: ↑

Thu Sep 02, 2021 10:31 am

My reason for the old Joomla version is simply that I did not think it matters that much.

If that were the case then there would be little activity on this forum! There’s an old saying in our industry: if builders built buildings the way programmers write software then the first woodpecker that came along would destroy civilisation as we know it!

Having been in the IT industry for over 50 years, I know from experience that software unreliability grows exponentially longer over time. (By the same token, the software reliability does not necessarily improve when new versions are released!)

As I informed you in my previous post, there have been over 70 new versions of J! released since J! 3.4.3. At this point, however, that’s a minor issue because the website is now dead. The site is dead not because of installing a plugin [that has been disavowed by the Joomla Extensions Directory]; the site is dead because the CMS is unable to connect to the database.

It’s possible, but not without some technical skill, to point the CMS at the database—in theory you can point any J! website at any database—if you know

1. the SQL username and its password;
2. the host-name where the SQL database exists; and
3. the DB name; and
4. the DB table prefix used with that site.

These values are stored in plain text in the file ../configuration.php:

.
.
.
	public $db = 'xxxxx';		// DB name
	public $dbprefix = 'xxxxx_';	// DB table prefix
.
.
.
	public $host = 'xxxxx';		// DB host-name (e.g. localhost)
.
.
.
	public $password = 'xxxxx';	// SQL user password (can be an empty string)
.
.
.
	public $user = 'xxxxx';		// SQL username (e.g. root)
.
.
.

These matters however do not address why you «did not get any result» when you tried to run the Forum Post Assistant:

jasper_coetzee wrote: ↑

Wed Sep 01, 2021 1:38 pm

I followed the advice of @Webdongle to download the Forum Post Assistant, but after installing the fpa-en.php and running it, I did not get any result. The feedback was «This page isn’t working; am-tech.co.za is currently unable to handle this request; HTTP ERROR 500.

The only thing that message tells us is that your website has some undiagnosed HTTP 500 Internal Server error. We may not be able to get to the bottom of the mystery if we can’t see what the FPA report generates.

In that situation, the person who created that topic had installed a different product—also been disavowed by the JED—which, as it now turns out, was a bit of a red herring. Sure, the plugin is incompatible with J! 3.4.3 but it’s not the cause of the database connection error.

The real problem is that the website is unable to connect to the database: this could be the result of changing the SQL username, its password, the SQL database host, the DB name, and/or the DB table prefix used with that site; this could be further compounded if the connection method is unsupported by the version of PHP used in this situation. This begs the question: what version of PHP is used by the website? (The FPA report, if it ran, would tell us that.)

It may help if you can run the FPA report against your working website (assuming the website that continues to work is located within the same hosting environment as the broken one). It won’t help to see the FPA report for the working website if the broken one resides in a different hosting environment.

I can’t advise you better without knowing more about the environment. Yes, there are lessons for us to learn from this case: (a) keep your websites updated; (b) don’t install questionable software products; and (c) perform regular (i.e. once a month, at least) site inspections, audits and general maintenance … and, especially, make backups that and store them off-site.

jasper_coetzee wrote: ↑

Thu Sep 02, 2021 1:02 pm

So, something else must have gone wrong as well.

Yup!

This article describes how to update database configuration settings in Joomla. You may need to do this if Joomla cannot connect to the database.

For example, if you migrate a Joomla site from another host, the database username is often different. By following the procedures described below, you can restore database access to your site.

Problem

When you try to view a Joomla site, you may receive the following error message:

Error displaying the error page: Application Instantiation Error: Could not connect to MySQL.

Alternatively, you may receive an error message that resembles the following:

Error displaying the error page: Application Instantiation Error: SQL=SELECT `session_id` FROM `jos_session` WHERE `session_id` = 'ca3v…34' LIMIT 0, 1

These errors occur when Joomla is unable to connect to the specified database in its configuration settings. This usually occurs because the database configuration settings in the configuration.php file are incorrect. For example, an account migration or Joomla database import can cause the database specified in the configuration.php file and the actual database to differ.

Resolution

To resolve this problem, first determine the correct MySQL database settings. Then you can update the Joomla configuration.php file with the correct database settings. To do this, follow the procedures below.

Step 1: Determine the correct MySQL database settings

To determine the correct MySQL database settings, follow these steps:

1. Log in to cPanel.

   If you do not know how to log in to your cPanel account, please see this article.

2. In the DATABASES section of the cPanel home screen, click phpMyAdmin:

   

   The phpMyAdmin administration page appears in a new window.

3. In the left-hand pane of phpMyAdmin, note the name of the Joomla database that you want to use.

   Typically, the Joomla database is username_joomXXX, where username represents your cPanel username, and XXX is a three-digit number. However, if your account was recently migrated (for example, from another hosting provider), the database name may be in a different format.

4. Click the name of the Joomla database that you want to use. A list of tables in the database appears.

5. In the Table column, note the table prefix that is used in the table names.

   Typically, the Joomla database table prefix is jos_. However, if your account was recently migrated (for example, from another hosting provider), the table prefix may be different, or even nonexistent.

6. In the DATABASES section of the cPanel home screen, click MySQL® Databases:

   

7. Under Current Databases, locate the database that you noted in step 3.

8. Note the database username for the database.

   If you do not know the password for this database user, you should reset it now.

Step 2: Update the configuration.php file

After you have determined the correct database settings, you are ready to update the configuration.php file. To do this, follow these steps:

1. In the FILES section of the cPanel home screen, click File Manager:

   

2. Navigate to the directory where Joomla is installed.

   Typically, Joomla is installed in the public_html (document root) directory. However, if you installed Joomla in a subdirectory, navigate to that directory instead.

3. Right-click the configuration.php file, and then click .

4. Locate the $db variable, and then replace the value with the name of the Joomla database that you obtained in the previous procedure. For example, if your database name is username_joom123, modify the text as follows:

   public $db = 'username_joom123';

5. Locate the $user variable, and then replace the value with the database username that you obtained in the previous procedure. For example, if your database username is username_joomuser, modify the text as follows:

   public $user = 'username_joomuser';

6. Locate the $password variable, and then replace the value with the database user’s password. For example, if your database user’s password is example_password, modify the text as follows:

   public $password = 'example_password';

   It should go without saying that you should not use example_password as a password on a real installation!

7. Locate the $dbprefix variable, and then replace the value with the database table prefix that you obtained in the previous procedure. For example, if the database table prefix is jos_, modify the text as follows:

   public $dbprefix = 'jos_';

   If your database does not use a table prefix, modify the text as follows:

   public $dbprefix = '';

8. Confirm that the $host variable is set to localhost as follows:

   public $host = 'localhost';

9. Click Save Changes.
10. Use your web browser to go to the Joomla site’s URL. The site should load.

При работе с Joomla и попытке установить шаблон или сам движок есть вероятность столкнуться с проблемами, возникающими в момент соединения с базой данных. В результате сайт перестает отображаться. Сегодня я расскажу, как исправить одну из таких ошибок, с текстом «Error displaying the error page: Application Instantiation Error.».

Почему возникает ошибка в Джумла

При некорректной настройке файла configuration.php в Joomla отобразится приведённое выше сообщение об ошибке, которое в переводе выглядит как “Проблема отображения страницы ошибок: ошибка создания примера приложения”. Но, что интересно, данная проблема может возникать и при правильной настройке информации, используемой для соединения с базами данных. Перед тем, как что-то предпринимать, проведите проверку файла configuration.php:

• отыщите строку public $dbtype = ‘mysql’ (информация в этой строке сообщает Joomla, какой тип базы данных используется при подключении);
• удостоверьтесь, что указанный в данной строке тип базы данных соответствует вашему;
• при необходимости проконсультируйтесь с компанией, предоставляющей веб-хостинг.

После этого можно предпринимать дальнейшие шаги по восстановлению работоспособности сайта.

Как исправить ошибку Error displaying the error page

Существует несколько способов решения ошибки. Рассмотрим их по порядку.

Проверка файла configuration.php

Просмотрите файл configuration.php и удостоверьтесь, что имя хоста и пользователя, а также имя базы данных и пароль от нее соответствуют тем, что были использованы при настройке вашей учетной записи.

Исправление ошибки из бэкенда Joomla

Еще одна из причин ошибки – повреждение в базе данных – легко исправляется из бэкенда Joomla. Если вы не имеете доступа к серверу, пропустите это решение и переходите к следующему. Если же доступ есть, то:

• войдите на проблемный сайт;
• перейдите “Расширения”→”Менеджер расширений”;
• в списке слева найдите database – “База данных”;
• нажмите fix – “исправить”.

Если дисфункция появлялась из-за повреждения в базе данных, то все будет исправлено.

Использование своей учетной записи для устранения ошибки

Войдите в свою учетную запись. Так как вы, скорее всего, являетесь единственным пользователем сайта Joomla, просмотрите, имеются ли в базе данных такие разрешения, как delete table data “Удалить данные таблицы” и create table “Создать таблицу”. После клика мышкой на панели слева к просмотру будут доступны все таблицы из главной панели phpmyadmin. Внизу таблицы выделите базу данных и активируйте кнопку check all – “Проверить все”. В выпавшем справа списке выберите пункт repair table – “Восстановить таблицы”. Данный вариант исправления ошибки отлично подходит тем, кто не имеет доступа к серверу Joomla.

Удалите ошибку из учётной записи

Среди причин ошибки Error displaying the error page пользователи называют и нехватку памяти, выделенной для учетной записи на сервере. Обратитесь к своему провайдеру, предоставляющему хостинг, уточните данный момент, и, если дело действительно в этом, попросите увеличить память. Также возможно, что проблемы существуют на сервере. В этом случае установите самостоятельно или при помощи хостера предыдущий бэкап базы данных.

Какое-либо из описанных решений поможет вам справиться с рассмотренной в статье ошибкой.

Источник

Error displaying the error page: Application Instantiation Error: Error initialising the session. #11350

Hi when I transfered my site online, after 1day working normaly appeared following error:
Error displaying the error page: Application Instantiation Error: Error initialising the session.
And I have to transfer again for it starts working
Help me please .

Expected result

Site [http://takfa-as.co.nf] works fine with and without login

Actual result

Actually I added following code into the file in libraries/cms/application/cms.php

jimport(‘joomla.log.log’);
JLog::addLogger(array(‘text_file’ => ‘session_errors.php’));
JLog::add(
JText::_(‘JERROR_SESSION_STARTUP’).
‘ Session State: ‘.$session->getState().
‘ Sql Error: ‘.$db->getErrorMsg()
);

And as a resultat in session_errors.php file displayed

Date: 2016-07-29 11:54:17 UTC

Software: Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT

Fields: datetime priority clientip category message

2016-07-29T11:54:17+00:00 WARNING 78.193.156.57 deprecated JDatabase::getErrorMsg() is deprecated, use exception handling instead.
2016-07-29T11:54:17+00:00 INFO 78.193.156.57 — Error initialising the session. Session State: active Sql Error: INSERT command denied to user ‘2174879_takfaas’@’83.125.22.218’ for table ‘#__session’ SQL=INSERT INTO #__session
( session_id , client_id , time ) VALUES
(‘2efe7a20d731859f3c55e2f2ec7c17fb’, 0, ‘1469793257’)
2016-07-29T11:54:18+00:00 WARNING 78.193.156.57 deprecated JDatabase::getErrorMsg() is deprecated, use exception handling instead.
2016-07-29T11:54:18+00:00 INFO 78.193.156.57 — Error initialising the session. Session State: active Sql Error: INSERT command denied to user ‘2174879_takfaas’@’83.125.22.218’ for table ‘#__session’ SQL=INSERT INTO #__session
( session_id , client_id , time ) VALUES
(‘2efe7a20d731859f3c55e2f2ec7c17fb’, 0, ‘1469793258’)
2016-07-29T11:54:19+00:00 WARNING 78.193.156.57 deprecated JDatabase::getErrorMsg() is deprecated, use exception handling instead.
2016-07-29T11:54:19+00:00 INFO 78.193.156.57 — Error initialising the session. Session State: active Sql Error: INSERT command denied to user ‘2174879_takfaas’@’83.125.22.218’ for table ‘#__session’ SQL=INSERT INTO #__session
( session_id , client_id , time ) VALUES
(‘2efe7a20d731859f3c55e2f2ec7c17fb’, 0, ‘1469793259’)
2016-07-29T11:54:20+00:00 WARNING 78.193.156.57 deprecated JDatabase::getErrorMsg() is deprecated, use exception handling instead.
2016-07-29T11:54:20+00:00 INFO 78.193.156.57 — Error initialising the session. Session State: active Sql Error: INSERT command denied to user ‘2174879_takfaas’@’83.125.22.218’ for table ‘#__session’ SQL=INSERT INTO #__session
( session_id , client_id , time ) VALUES
(‘2efe7a20d731859f3c55e2f2ec7c17fb’, 0, ‘1469793260’)
2016-07-29T11:56:44+00:00 WARNING 78.193.156.57 deprecated JDatabase::getErrorMsg() is deprecated, use exception handling instead.
2016-07-29T11:56:44+00:00 INFO 78.193.156.57 — Error initialising the session. Session State: active Sql Error: INSERT command denied to user ‘2174879_takfaas’@’83.125.22.218’ for table ‘#__session’ SQL=INSERT INTO #__session
( session_id , client_id , time ) VALUES
(‘2efe7a20d731859f3c55e2f2ec7c17fb’, 0, ‘1469793404’)

System information (as much as possible)

PHP Version 5.5.38
System Linux f15.runhosting.com 4.4.15nopreempt #1 SMP Wed Jul 13 17:10:30 EEST 2016 x86_64

Help me please .

The text was updated successfully, but these errors were encountered:

Источник

“Application Instantiation Error: Table ‘db.#__session’ doesn’t exist” Error in Joomla: 5 Possible Reasons

Note: You must replace #__ in the post below with your database alias which is the value of the variable $dbprefix that is defined in the configuration.php file of your Joomla website.

Another note: Always backup your Joomla database before making any modifications to it.

A not so uncommon fatal error on Joomla websites is the following error:

Application Instantiation Error: Table ‘db.#__session’ doesn’t exist

What the above error essentially means that Joomla is unable to read/write to the critical session table. This can be caused by one of the following (the below are listed in order of occurrences):

The session table is corrupted: The most common reason of the Table ‘db.#__session’ doesn’t exist error is corruption in the #__session table, this is especially the case when the table is using the MyISAM database storage engine (which is infamous for causing table corruption). If this is the case, then you should repair the table, which can be done by issuing the following query in phpMyAdmin:

REPAIR TABLE `#__session`

The above query should be sufficient to repair the table. If it doesn’t work, then you may need to reconstruct the table from scratch, which is described in the following section.

Note: We recommend switching the database engine of the #__session table to InnoDB or to MEMORY as MyISAM is a very flimsy database engine.

The session table was deleted: One some occasions, the cause of the problem is a deleted #__session table. In this case, you will need to reconstruct the table. Reconstructing the table also works if the table is corrupted but cannot be repaired using the REPAIR syntax. Reconstruction of the #__session table is a safe process because the information in the #__session table is meant to be volatile and can be safely deleted at anytime.

To reconstruct the table, you will need to run the following queries in phpMyAdmin (the following is compatible with Joomla 3.x):

The above code should drop your #__session table and then reconstruct it.

The database user doesn’t have full read/write control over the session table: A not so uncommon cause of the problem is a user which doesn’t have full privileges over the #__session table. This is likely to happen when the Joomla database is managed at a granular level, and not through a mainstream system (like WHM). Fixing the problem is usually done by granting full read/write permissions on the #__session table (this is typically done by a system administrator).

The database is empty: Last week, we had the Table ‘db.#__session’ doesn’t exist problem on a website, and it turned out that the database was empty. It didn’t have a single table, not one. The database did exist and the connection parameters were correct, but it was empty (if the database didn’t exist, or if we had the wrong database credentials in the configuration.php file, then we would have seen the Application Instantiation Error fatal error instead). We fixed this problem by reverting to an old backup. The backup didn’t contain the most up-to-date data, but it was much better than nothing.

The configuration file is pointing to a different database: On some instances, we have seen a configuration.php file where the database parameters are pointing to an existing database, but not to the Joomla database. This is not common but it can happen, and it is usually caused by a human error: for example, the system administrator copied the content of the Joomla database to another database, emptied the original database (and used it for a different purpose), but did not update the parameters in the configuration.php file to point to the new database. Fixing the problem simply consists of updating the database parameters in the configuration.php file to point to the actual database.

We hope that you found our post useful and that it helped you solve your problem. If it didn’t, then you can always contact us. We are always happy to serve, our prices are super cheap, and we really love to have you as a client and a friend!

No comments yet.

At itoctopus, we’re here to help you with your business! That’s our promise to you. Whether you’re looking for urgent programming help in the middle of the night, or you need help expanding your website, or you need to claim your projects for R&D, then you’re at the right place. We have served a lot of customers since 2001, and we’ll be happy to serve you!

If you want to fix an urgent issue (for example, your website is down), then give us a call at 514 961 2804, this line is at your service 24/7/365!

Call Now: 514 933 8036

Just give us a call if you need help on your website, and you’ll be surprised how friendly, efficient, and fast we are! Oh, and we genuinely care about your business! (International clients please call +1 514 933 8036)

Источник

The Joomla! Forum™

Application Instantiation Error: Could not connect to MySQL Topic is solved

Application Instantiation Error: Could not connect to MySQL

Post by jasper_coetzee » Wed Sep 01, 2021 1:38 pm

I installed the facebook pixel plugin on my site (am-tech.co.za). Everything was still working fine, but the moment that I activated the plugin, the site stopped working. Initially it just gave a blank screen, but now it reports «Error displaying the error page: Application Instantiation Error: Could not connect to MySQL.» I have been Googling, and got to the post «viewtopic.php?t=971497», where a person had the same problem.

I followed the advice of @Webdongle to download the Forum Post Assistant, but after installing the fpa-en.php and running it, I did not get any result. The feedback was «This page isn’t working; am-tech.co.za is currently unable to handle this request; HTTP ERROR 500.

I also tried the method that the originator @terciodejesus found to work, but with no result.

Problem is that I do not have a backup. Stupid, I know.

Please help.

Re: Database connection error after plugin activate

Post by jasper_coetzee » Wed Sep 01, 2021 1:43 pm

Re: J! 3.4.3 Database connection error after plugin activate

Post by sozzled » Wed Sep 01, 2021 8:01 pm

Why are you using an old, outdated version of J! 3.x (J! 3.4.3 was released 7½ years ago) on the target website? What version(s) of J! are you using on the other J! 3. x website?

What is the name of the «Facebook pixel» plugin that you are using? Maybe you should unistall it?

Re: Database connection error after plugin activate

Post by jasper_coetzee » Thu Sep 02, 2021 8:13 am

Thank you for reaching out to me.

Your question about the Joomla version is a good one to which I do not have a proper answer. The other site was recently updated to version 3.9.28.

The plugin’s full name is facebook-pixel-for-joomla-pixel-914037906211194.zip.

I will gladly uninstall the plugin if I can get into the website’s back end, but I cannot. Is there a way to get in which I do not know?

I am going to list the last lines of the error log here (I found out about this on another post).

[31-Aug-2021 12:28:25 UTC] PHP Fatal error: Call to undefined method JApplicationAdministrator::isClient() in /home/kigtkyoe/public_html/plugins/system/officialfacebookpixel/officialfacebookpixel.php on line 36

I copied the code in the officialfacebookpixel.php from line 33 to 52:

33 public function onBeforeCompileHead() <
34 $app = JFactory::getApplication();
35
36 if ($app->isClient(‘administrator’)) <
37 return true;
38 >
39
40 if ($this->params->get(‘pixel_id’, false)) <
41 $pixel_id = $this->params->get(‘pixel_id’);
42 $this->injectPixelBaseCode($pixel_id);
43 >
44
45 $is_form_submitted = $app->getUserState(FacebookPluginConfig::SUBMIT_JOOMLA_CONTACT_FORM, false);
46 if ($is_form_submitted) <
47 // Reset the user state
48 $app->setUserState(FacebookPluginConfig::SUBMIT_JOOMLA_CONTACT_FORM, false);
49
50 $script = Pixel::getPixelTrackLeadCode(array(), true);
51 $this->injectPixelTrackCode($script);
52 >

I hope this will shed light on the issue.

Re: Database connection error after plugin activate

Post by sozzled » Thu Sep 02, 2021 8:51 am

I’m guessing that this plugin is Official Facebook Pixel which was de-listed from the JED for a «General Guideline Violation» (whatever that means).

So, we don’t know if this plugin is compatible with J! 3.4.3 (and you still haven’t offered an explanation about why you’re running an unsupported version of J! that’s 6 years or 71 releases older than the latest one). We guess that this plugin is causing a database connection error.

You can disable the plugin by going into the filesystem and renaming the PHP file. I don’t know what kind of plugin this and so I can’t tell you exactly where to look.

Another way of disabling the plugin is to make a small change in the database. You want to look at the _extensions table, locate the record corresponding to that plugin and change the value in the enabled column from 1 to 0.

It’s usually easy enough to find the version of J! installed on a domain unless the site owner protects the file that contains the information. If you, too, would like to know how to do find this information you can do what I did and ask Google.

Re: Database connection error after plugin activate

Post by sozzled » Thu Sep 02, 2021 8:54 am

Re: Database connection error after plugin activate

Post by jasper_coetzee » Thu Sep 02, 2021 10:31 am

My reason for the old Joomla version is simply that I did not think it matters that much. However, when I get the site working I will immediately arrange for my upwork man to update the site.

I tried renaming the php file, but it did not work.

I exported the database, and will try that solution.

I will report back. Thank you very much so far. It gives me hope.

Re: Database connection error after plugin activate

Post by jasper_coetzee » Thu Sep 02, 2021 10:40 am

Is this where I need to make the change in the database?

Re: Database connection error after plugin activate

Post by jasper_coetzee » Thu Sep 02, 2021 10:40 am

Is this where I need to make the change in the database?

Re: Database connection error after plugin activate

Post by jasper_coetzee » Thu Sep 02, 2021 10:50 am

Re: Database connection error after plugin activate

Post by jasper_coetzee » Thu Sep 02, 2021 10:50 am

Re: Database connection error after plugin activate

Post by jasper_coetzee » Thu Sep 02, 2021 1:02 pm

I did edit the facebookpixel database record, and it is now not enabled. But the site still gives the same message: «Error displaying the error page: Application Instantiation Error: Could not connect to MySQL.»

So, something else must have gone wrong as well. I yesterday found a site that assists with that. I checked the site’s configuration.php against the database record in cpanel for the four quantities:
public $host = ‘your-database-host’;
public $user = ‘your-database-user-name’;
public $password = ‘your-database-user-password’;
public $db = ‘your-database’;

All of that was fine. I even re-input the password per the configuration.php.

Now I don’t know what.

Error displaying the error page: Application Instantiation Error: Could not connect to MySQL.

Post by sozzled » Thu Sep 02, 2021 7:18 pm

↑ Note the change of topic subject above.

Thank you, @jasper_coetzee, for your replies and informing us that:

1. you have succeeded in disabling the Official Facebook Pixel plugin that you installed—you will find the installation files in the folder ../plugins/system/officialfacebookpixel; and
2. installing this plugin has nothing to do with the database connection error.

If that were the case then there would be little activity on this forum! There’s an old saying in our industry: if builders built buildings the way programmers write software then the first woodpecker that came along would destroy civilisation as we know it!

Having been in the IT industry for over 50 years, I know from experience that software unreliability grows exponentially longer over time. (By the same token, the software reliability does not necessarily improve when new versions are released!)

As I informed you in my previous post, there have been over 70 new versions of J! released since J! 3.4.3. At this point, however, that’s a minor issue because the website is now dead. The site is dead not because of installing a plugin [that has been disavowed by the Joomla Extensions Directory]; the site is dead because the CMS is unable to connect to the database.

It’s possible, but not without some technical skill, to point the CMS at the database—in theory you can point any J! website at any database—if you know

1. the SQL username and its password;
2. the host-name where the SQL database exists; and
3. the DB name; and
4. the DB table prefix used with that site.

These values are stored in plain text in the file ../configuration.php:

The only thing that message tells us is that your website has some undiagnosed HTTP 500 Internal Server error. We may not be able to get to the bottom of the mystery if we can’t see what the FPA report generates.

In that situation, the person who created that topic had installed a different product—also been disavowed by the JED—which, as it now turns out, was a bit of a red herring. Sure, the plugin is incompatible with J! 3.4.3 but it’s not the cause of the database connection error.

The real problem is that the website is unable to connect to the database: this could be the result of changing the SQL username, its password, the SQL database host, the DB name, and/or the DB table prefix used with that site; this could be further compounded if the connection method is unsupported by the version of PHP used in this situation. This begs the question: what version of PHP is used by the website? (The FPA report, if it ran, would tell us that.)

It may help if you can run the FPA report against your working website (assuming the website that continues to work is located within the same hosting environment as the broken one). It won’t help to see the FPA report for the working website if the broken one resides in a different hosting environment.

I can’t advise you better without knowing more about the environment. Yes, there are lessons for us to learn from this case: (a) keep your websites updated; (b) don’t install questionable software products; and (c) perform regular (i.e. once a month, at least) site inspections, audits and general maintenance . and, especially, make backups that and store them off-site.

Re: Application Instantiation Error: Could not connect to MySQL

Post by jasper_coetzee » Fri Sep 03, 2021 2:51 pm

I now rowed with this for some hours again. But, no luck. The database and the configuration.php settings are the same. I even tried some changes (completely changed the password on both sides, changed the host from ‘127.0.0.1’ to ‘localhost’ and back), but nothing.

I now wrote the hosting company as follows:
«Hello Cybersmart,

I really went far with this issue over the last few days. Joomla Forum, etc. So, the original problem occurred after I installed the facebook-pixel plugin (the installation did nothing, but when I enabled it the website went blank). And then some time after that the «Could not connect to MySQL» error came up. Now, I disabled the plugin in the MySQL database, but the connection error persists. And everything in the configuration.php matches the actual database settings. I have now rowed with this issue for 3 days.

Now my question is: you do not perhaps have a recent backup of the server (newer than say 2 months) which you can restore?

Otherwise, I will probably have to find someone more savvy than me to try and sort this out. Or, alternatively, I will have to restore a backup made 18 months ago — that would be very sad indeed!»

I am not someone that gives up easily, but the logics of the sittuation says that there must be something else that causes the problem. I even now went and changed the name of the facebookpixel again. But, no luck.

I can tell you one thing. I will abide by your rules for site updates in future! I have learnt my lesson.

By the way, I developed the site based on a template bought from template monster. The original site, which I carried over to the company’s host, is still up and running at https://www.m-tech-consult.co.za/joomla30/.

I want to thank you for all the trouble you have gone to in this process. I really appreciate it much more than you can imagine.

Источник

Dear Mr. Babker,

Nice, and tolerable enough, that you began to pour something more constructive than blatantly blocking and closing this feature request.

Joomla supports sessions stored to the filesystem, or several other storage mechanisms that are not a RDBMS

In fact on CodeIgnitor docs pages, they want its users to prefer storing file based instead of databased. I learned from that its advantages too.

But, to know what template should be used for rendering the page, it has to be able to connect to the database.

The «Connectionless page» could be generated based on a naming of a directory — for e.g. — «default». So all files under the default dir under /public_html/templates/default/* and /public_html/administrator/templates/default/* could be served. With this system, every user is guaranteed to have a webpage to be displayed under all circumstances, regardless of if there is no connection to database or if the connection parameters are wrong.

Dear Mr. Babker, what happens during the installation, when there is no database connection and is yet to be fulfilled? The admin gets a page generated or not? In my system of having /public_html/templates/default/*, a user could even configure a default template that will be generated when such an error is triggered, or 404 is generated, etc.

Joomla must offer the same features across all supported platforms.

Joomla portal claims to have two million websites here:

https://www.joomla.org/core-features.html

I refer to the «Usage of web servers for websites» published here:

https://w3techs.com/technologies/overview/web_server/all

The statistics declares:

A)
Apache 45.6% means 912000 thousand Joomla websites
Nginx 39.6% means 792000 thousand Joomla websites

Apache and Nginx together becomes 1,704 Million Joomla websites

B)
Microsoft-IIS 9.4% means 188000 thousand Joomla websites
Litespeed 3.4% means 68000 thousand Joomla websites

Microsoft-IIS and Litespeed together becomes 0,25 Million Joomla websites

C)
None other of above is irrelevant.

Based on above statistics, we are talking about one Group of (Apache and Nginx) 1,704 Million Joomla users against 0,25 Million Joomla users.

Dear Mr. Babker, do you mean to place a counter argument that 1,7 Million up to ca. ONE MILLION USERS users should accept all disadvantages, because they use Apache/Nginx, simply because there are 0,25 Million Joomla users, who could not use this solution?

Thats not how a developer may evaluate a concept. The majority comes first in the priority and one should not block very important development work because of minority. I do not say that one should neglect the other. I say that one should find a way out. I myself use Apache under localhost and Nginx as proxy. This is kind of a very good combination for various reasons. Many servers use this configuration.

If one excludes Nginx from 1.7 Million users above, still there would be majority using Apache, like about ONE MILLION USERS.

So the strategy — according to me — would be to follow and apply more focus on one million users and thereafter try to apply all changes to other technologies «as best as one can». I have not known a single developer in the last twenty five years, who thought otherwise.

Relying ONLY on .htaccess authentication as a security mechanism is not platform portable and a security risk on environments where .htaccess configuration is limited or not available at all.

This is a restrictive thinking. Why provide in the first step something that has nothing to do with that platform? One could make things possible where it is required and needed to be. If there is some kind of detection mechanism of OS and services, then one could change the installer to offer htaccess configuration on systems using Apache services and allow configuration of htaccess. On other systems, where it is not applicable, this option may not even be displayed.

Don’t we know how this works and how to modify the installer on «case: apache2», «case: iis», etc?

Like this, a new window of work will be instantly available for ONE MILLION USERS.

I have never ever mentioned about creating a flat file CMS. The idea was simply to have a possibility to have a basic creation of a Connectionless view as a basic feature embedded into the core.

Once this functionality is embedded in the Framework, there may be many extensions cropping up and will begin to use this functionality, like repairing tables, changing prefixes, etc. This could not be done now without from Joomla framework as it requires a connection. There will crop up some more extensions for a better security too working with htaccess, etc. and other features.

It simply opens a new door to multiple advantages for ONE MILLION USERS.

About ONE MILLION USERS of Joomla installations will be compelled to create a htaccess file during installation — first step and secure their /administrator/ directory, if Joomla detects Apache on the server and ask to insert the htpass on that page where admin enters its password and username.

Once this fundamental area is decided and implemented, it would not be too far to identify some other techniques for users of Joomla running on other services like Microsoft-IIS, Litespeed, etc. There would be definitely something that would help to create some access of a similar kind without major modification or work.

From the claim by Joomla portal, there are «Over 9% of all known business websites». This means that there are 180000 thousand users.

From ca. 2.000.000 business users, I am more-or-less sure that there are more than one hundred thousand business users, who would be «extremely interested» in having this multisite feature. According to me, there may be at least another two hundred thousand users from other groups, who may want to have multisite feature.

If I were to give a priority to my own feature request by myself, I would spend more time on multisite feature and provide little by little functionality of multisite feature to a QUARTER MILLION JOOMLA USERS.

If users may not know about this functionality, then this number be less. Once this functionality is embedded, one may see a rapid growth in its use. I even could stretch this argument and say that there may be at least ONE HUNDRED THOUSAND USERS who may want to change from other CMS to Joomla because of multisite feature. Summing up, I am looking at about half a MILLION USERS FOR MULTISITE feature.

Not implementing the multisite feature is more than stupid and less than foolish, and nothing in between, upon neglecting such an important demands in the industry, specifically after Joomla core has achieved to be one of the finest and most stable. Mind you all, I criticize this severely and harshly, not because I am an enemy of Joomla or any one of you but, on the contrary, as a lover of Joomla, who has followed its growth since it was a child nicked as Mambo.

Developers of this kind of a quality, level, popularity and stability in a framework, like Joomla as already achieved since version 3 was born, have no right to remain blind to such a demand.

And there are not many other than CMS 7 Frameworks other than a few ones, like Laravel, CodeIgnitor, Drupal, etc. Against these ones, Joomla has a terrific built-in advantage and highest potential, although I would choose CodeIgnitor or Symfony, when it may come to multisite built upon a framework. However, none of these frameworks have a variety of extensions, plug-ins, modules and templates, which Joomla has. Consequently, Joomla wins. I do have some reasons to argue in favour of Joomla for multisite and, thus, placed a request here to support A QUARTER MILLION USERS to avail multisite function under top priority.