Ошибка в браузере «Не удалось загрузить плагин». Способы устранения. Устранение ошибки «Плагин загружен, но не создаются объекты й способ. Повторная установка Adobe Flash Player

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

В WordPress существует фиксированная процедура инициализации. При реализации жизненного цикла страницы платформа WordPress запускает массу действий, многие из которых были раскрыты нами ранее. В системе существует набор инициализационных хуков, которые используются для инициализации приложения перед выполнением его базовой функциональности.

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

В данной статье мы раскроем всю важность хуков инициализации в WordPress, а также покажем, как использовать их в различных ситуациях.

Введение в хуки инициализации

WordPress предлагает широкий спектр хуков, которые могут использоваться в разработке плагинов и тем.

В случае типичного запроса страницы все хуки действий выполняются в определенном порядке. Вообще, все хуки выполняются после того, как базовое приложение WordPress завершит свою загрузку.

Таким образом, хуки инициализации в основном используются для того, чтобы, как вы могли догадаться, инициализировать процесс их работы в плагинах и темах. Давайте взглянем на доступные init-хуки в WordPress в порядке их выполнения:

• Init запускается после того, как WordPress закончит свою загрузку, но до того, как будут переданы какие-либо хэдеры. Вообще, этот хук используется плагинами для инициализации процесса их работы.
• widgets_init используется для регистрации виджетов приложения в сайдбаре. Функция register_widget выполняется в пределах данного хука.
• admin_init выполняется в качестве первого действия после того, как пользователь получил доступ к панели администрирования WordPress. В целом, он используется для того, чтобы инициализировать параметры, специфичные для области администратора.

Помимо этих трех хуков, в WordPress также существует еще один хук под названием admin_bar_init, который выполняется после того, как админ-бар был инициализирован. WordPress Codex не содержит в себе описание данного хука, однако он используется лишь небольшим числом плагинов.

Вы можете изучить полный процесс выполнения хуков действий в WordPress в кодексе .

WordPress выполняет каждый хук в определенном порядке (который описан в кодексе). Также важно рассмотреть порядок появления событий в каждом хуке действий. Давайте рассмотрим следующие ситуации, чтобы понять разницу.

Определяем admin_init внутри хука init

Если нам требуется, мы можем определить хуки WordPress в пределах других хуков. В типичном запросе хук init выполняется перед хуком admin_init. Давайте попробуем что-либо вывести на экран, разместив admin_init внутри хука init:

Add_action("init", "test_init"); function test_init(){ add_action("admin_init", "test_admin_init"); } function test_admin_init() { echo "Admin Init Inside Init"; }

После выполнения этого кода мы получим желаемый вывод посредством оператора echo.

Определяем init внутри хука admin_init

Давайте посмотрим на код и вывод сценария, когда более ранний хук определен в хуке, который идет позже в порядке выполнения.

Add_action("admin_init", "test_admin_init"); function test_admin_init() { add_action("init", "test_init"); } function test_init() { echo "Init Inside Admin Init"; }

В данном случае мы не получим никакого вывода – как и ожидалось – поскольку хук init выполняется перед хуком admin_init, а это недопустимо после определения хука admin_init.

Как вы можете видеть, очень важно понимать процедуру выполнения хуков для создания успешных плагинов. Порядок появления событий важен для всех хуков WordPress.

Исследуем хуки init и admin_init

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

Также мы посмотрим на функциональность хуков init и admin_init.

Хук init выполняется при каждом запросе как для фронтэнда, так и для бэкэнда сайта WordPress.

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

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

Как использовать init хуки

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

WordPress не указывает нам на то, что именно мы должны, а что не должны подключать; поэтому разработчики могут допускать незначительные ошибки, которые, в свою очередь, способны приводить к заметному снижению производительности. В данной секции мы покажем вам, как эффективно использовать хуки init и admin_init.

Давайте взглянем на самые лучшие практики использования инициализационных хуков:

Хук init

• Регистрация произвольных типов записей – разработчики WordPress рекомендуют использовать хук init для регистрации новых произвольных типов записей.
• Инициализация конфигурации и настроек плагина – параметры настройки и конфигурации плагина необходимо определить для каждого запроса, а значит, хорошая практика заключается в том, чтобы поместить их внутри этого хука.
• Доступ к отправленным пользовательским данным (используя $_GET и $_POST) – мы можем перехватить переданные пользовательские данные без использования любых действий, однако в этом случае рекомендуется использовать init хук, поскольку он гарантирует выполнение для каждого запроса.
• Добавление новых правил перезаписи – мы можем задавать новые правила перезаписи, используя хук init, однако они будут работать только после сброса.
• Добавление или удаление произвольных действий – плагины содержат в себе много произвольных действий для расширения функциональности. Могут возникнуть ситуации, когда нам понадобится добавить новые действия или удалить старые. В таких случаях важно применить эти действия в хуке init.
• Загрузка текстового домена плагина – WordPress поддерживает многочисленные языки, и таким образом, мы можем загружать файл, содержащий переведенные строки. Это должно делаться тоже в хуке init.

Хук admin_init

• Управление доступом – важно проверить права доступа вошедших в систему пользователей перед тем, как разрешить пользовательский доступ к определенному набору особенностей и функциональности. admin_init – первое действие, которое будет выполняться в области администратора, поэтому мы можем использовать его для управления доступом.
• Добавление новых параметров – мы можем использовать этот хук для добавления новых страниц настроек или параметров в существующую область параметров WordPress.

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

Общие ошибки использования хуков инициализации

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

Давайте определим частые ошибки, а также способы их обхода:

• Обновление правил перезаписи – это очень ресурсоемкая операция, в процессе которой все правила перезаписи обновляются и переупорядочиваются для добавления новых или удаления старых нетребуемых правил. Многие разработчики обновляют правила перезаписи внутри init-действий. Это приводит к тому, что возникают ненужные затраты в плане производительности в каждом запросе. Мы должны определить способ ручного обновления правил перезаписи с помощью кнопок или обновления правил для редких действий, как, к примеру, сохранение настроек плагина.

• Доступ к базе данных – для реализации различной функциональности должен иметься доступ к базе данных, однако важно также предотвратить ненужные обращения к базе данных внутри инициализационных хуков, поскольку они выполняются при каждом запросе. Для данной цели идеальным решением будет привязать хуки базы данных к хукам с определенной функциональностью, избежав массивных затрат производительности.

• Выполнение процедур обновления – плагины должны включать в себя процедуры обновления, чтобы обновлять свои возможности в новых версиях. Обычно разработчики используют хуки инициализации для проверки версии плагина и существующих параметров перед выполнением процесса обновления. Мы можем предложить пользователям обновлять плагин на отдельном экране вместо того, чтобы автоматически совершать проверки при каждом запросе.

• Использование хуков инициализации вместо хуков для определенной функциональности – это самая распространенная ошибка, которая совершается многочисленными разработчиками. В WordPress существует широкий спектр хуков, связанных с уникальной функциональностью. Очень важно использовать функциональные хуки, чтобы обойти конфликты и сделать код расширяемым. Хуки, такие как init и admin_init, могут использоваться вместо специфичных хуков, поэтому многие разработчики склонны обращаться к ним, не понимая того, какой разрушительный эффект это несет.

Примеры распространенных сценариев использования хуков init и admin_init разработчиками вместо рекомендуемых хуков:

• admin_menu – мы можем добавлять страницы меню с помощью функции add_menu_page. Для создания страниц в меню администратора рекомендуют использовать хук admin_menu. Однако многие разработчики используют хук admin_init, поскольку он выполняется после хука admin_menu.
• wp_enqueue_scripts – рекомендуемый способ добавления стилей и скриптов состоит в использовании хука wp_enqueue_scripts. Однако многие разработчики используют wp_enqueue_script внутри хука init для загрузки скриптов и стилей.

Существует масса подобных ситуаций, когда разработчики используют общий хук init вместо специального хука для определенной функциональности, и от такого подхода необходимо по возможности отказаться.

Заключение

Хуки инициализации WordPress играют жизненно важную роль в разработке плагинов и тем. Многие разработчики неправильно используют хуки, создавая лишнюю нагрузку на производительность. В данной статье мы обсудили правильное использование этих хуков, а также общие ошибки их применения и способы их обхода.

Теперь мы можем применить те же самые методики к хукам, используемым в плагинах. Многие разработчики плагинов используют свои собственные хуки действий, чтобы сделать плагины расширяемыми. Для таких плагинов мы можем определить специфичные для плагина хуки инициализации, чтобы позволить разработчикам «повесить» задачи инициализации на предопределенные хуки.

Posted on 03.02.2016 in

Общие сведения

Программный интерфейс плагина предполагает вызов асинхронных операций, реализованных на основе объектов promise. Подробнее про использованную в реализации плагина спецификацию можно прочитать . На promise необходимо устанавливать обработчики двух типов:

• onFulfilled – срабатывают, когда promise в состоянии «выполнен успешно»;
• onRejected – срабатывают, когда promise в состоянии «завершен с ошибкой».

Инициализация плагина

Для работы с плагином необходимо вызвать функцию инициализации PKCS#11-компонента plugin.initPKCS11 . Данная функция в качестве параметров принимает перечень названий модулей (в виде массива). Перечень предусмотренных модулей можно посмотреть . Если модули не указаны, то плагин произведет инициирование всех модулей.
При необходимости указать, какие именно криптопровайдеры следует использовать при работе модуля capi, следует использовать следующий формат записи:

Capi:{prov1},{mode}:{prov2},{mode}

В этой записи:

• prov1, prov2 – название криптопровайдера. В настоящее время поддерживаются следующие значения:
• Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider;
• Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider;
• Crypto-Pro GOST R 34.10-2012 Strong Cryptographic Service Provider;
• Signal-COM CPGOST Cryptographic Provider;
• Signal-COM GOST R 34.10-2012 (256) Cryptographic Provider;
• Signal-COM GOST R 34.10-2012 (512) Cryptographic Provider;
• Infotecs Cryptographic Service Provider.
• mode – режим отображения окна ввода пин-кода. Может принимать следующие значения:

• 0 – режим по умолчанию, предусмотренный криптопровайдером;
• 1 – отображение нативного окна криптопровайдера.
  Примечание: при работе с Crypto-Pro в Linux отображение нативного окна криптопровайдера недоступно.
• 2 – отображение окна в интерфейсе плагина.
  Примечание: при работе с Signal-COM отображение окна в интерфейсе плагина недоступно.

Для получения ключей из системного хранилища Windows следует в качестве провайдера указать , а в качестве режима — My.
Пример инициирования всех модулей:

Plugin.initPKCS11(["ISBC ESMART", "Aladdin R.D. Unified JaCarta", "Rutoken", "SafeNet", "capi:Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider,0:Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider,0:Crypto-Pro GOST R 34.10-2012 Strong Cryptographic Service Provider,0:Signal-COM CPGOST Cryptographic Provider,0:Signal-COM GOST R 34.10-2012 (256) Cryptographic Provider,0:Signal-COM GOST R 34.10-2012 (512) Cryptographic Provider,0:Infotecs Cryptographic Service Provider,0:,My"])

Пример инициирования модуля для получения ключей из системного хранилища Windows:

Plugin.initPKCS11(["capi:,My"])

При успешной инициализации функция возвращает объект (здесь и далее – с помощью механизма promise), имеющий функции modules и getCertsForSign .

Просмотр перечня модулей и их состояния

Для просмотра перечня модулей и их состояния необходимо вызвать функцию modules .
Пример запроса:

Pkcs11.modules.then(onFulfilled, onRejected);

Пример ответа функции (разрывы даны для удобства чтения):

[ { "enable": true, "name": "Aladdin R.D. Unified JaCarta" }, { "enable": true, "name": "Rutoken ECP" }, { "enable": false, "error": "100:failed to load p11 module", "name": "ISBC ESMART" } ]

Просмотр перечня сертификатов

Для просмотра перечня обнаруженных сертификатов необходимо вызвать функцию getCertsForSign . В качестве параметра вызова функции необходимо указать, следует ли использовать параллельный режим опроса инициализированных PKCS#11 модулей:

• true – параллельное обращение к модулям (рекомендуемый режим);
• false – последовательное обращение к модулям.

Просмотр данных о конкретном сертификате

Для просмотра данных о конкретном сертификате необходимо вызвать свойство full_info , возвращающее сведения о сертификате в виде json-объекта. Он включает в себя следующие параметры:

• sn – серийный номер сертификата;
• subject – данные о субъекте, которому выдан данный сертификат электронной подписи. Возвращается в виде json в формате «параметр: значение», где параметр – это название соответствующего объектного идентификатора (OID). Всем стандартным объектным идентификаторам даны общепринятые обозначения, например, CN (Common Name).
• issuer – данные об издателе сертификата ключа электронной подписи. Возвращается в виде json в формате «параметр: значение», где параметр – это название соответствующего объектного идентификатора (OID). Всем стандартным объектным идентификаторам даны общепринятые обозначения;
• not_before – время начала действия сертификата (тип данных – строка в формате ASN1_TIME);
• not_after – время окончания действия сертификата (тип данных – строка в формате ASN1_TIME);
• key_usage – информация о назначении ключа, возвращается в виде массива.

Просмотр данных о ключе электронной подписи

Для просмотра данных о конкретном ключе электронной подписи сертификата необходимо вызвать метод token_info . Метод возвращает json-объект со следующими данными:

• label – имя ключевого контейнера средства электронной подписи;
• manufacturerID – идентификатор производителя средства электронной подписи;
• model – модель средства электронной подписи;
• serialNumber – серийный номер средства электронной подписи.

Операция подписания с помощью выбранного сертификата

Простой режим подписания

Для подписания строки с помощью выбранного сертификата необходимо вызвать функцию cms_sign_on_it , принимающую следующие входные параметры:

• строка для подписи;
• тип подписи — является ли подпись присоединенной (необходимо передавать значение true) или отсоединенной (false).

Расширенный режим подписания

Расширенный режим позволяет:

• подписывать данные большого объема, например, файлы;
• подписывать несколько файлов без повторного запроса пин-кода.

Для подписания данных с помощью выбранного сертификата необходимо предварительно инициализировать объект signer с помощью функции start_signing на объекте сертификата. Параметры функции:

• тип подписи — является ли подпись присоединенной (необходимо передавать значение true) или отсоединенной (false);
• количество попыток ввода пин-кода (например, значение «1» означает, что у пользователя имеется только одна попытка, после чего функция возвращает ошибку).

На объекте signer будут доступны методы:

• add_data_in_hex(hexDataString) — принимает на вход данные в виде hex строки;
• add_data_in_base64(base64DataString) — принимает на вход данные в виде base64 строки;
• add_data_in_string(stringData) — принимает на вход данные в виде utf-8 строки;
• free() — возвращает значение true/false , что позволяет проверить, что сертификат готов к подписанию. Требуется использовать для случая, когда несколько итераций подписи осуществляются на разных сертификатах. Иными словами, если осуществляется последовательное подписание на нескольких сертификатах, то перед подписанием необходимо вызвать этот метод и убедиться, что он вернул true ;
• finish() — финализирует подпись и возвращает ее в формате CAdES-BES / PKCS#7.

Подписание строки

Пример команды, позволяющей подписать строку:

Signer.add_data_in_string("1234").then(function(res){ return signer.finish();}).then(function(cms){console.log(cms)});

В данной команде «1234» — это строка, которую необходимо подписать.

Установка нескольких подписей

После финализации подписи объект signer возвращается в исходное состояние. В рамках сессии его можно использовать повторно для подписания других данных, например, нового файла. В этом случае пин-код не будет запрошен повторно.

Чтобы произвести подписание на другом сертификате, необходимо очистить объект signer . В большинстве браузеров этот объект очищается автоматически, когда он покидает область видимости (scope). Однако в Internet Explorer возможны ситуации, когда очищение signer не происходит, что приводит к ошибке. Для избегания ошибки рекомендуется явно очищать signer.free() . Данную операцию можно проводить во всех браузерах, чтобы унифицировать код. Пример подписи на сертификате с очисткой объекта signer:

Function sign(cert, info) { function successCms(signature) { alert(signature); } cert.start_signing(false, 3) .then(function(signer) { signer.add_data_in_base64("MTIzNDU2") .then(function() { var data = signer.finish(); var free = signer.free(); return data; }, e) .then(successCms, e); }, e); }

Подписание файла большого объема

Function readFileByChunk(file, cbToRead, cbToFinish) { var fileSize = file.size; var chunkSize = 1024*1024; // bytes var offset = 0; var chunkReaderBlock = null; var self = this; var readEventHandler = function(evt) { if (evt.target.error == null) { cbToRead(evt.target.result, offset, fileSize); offset += evt.target.result.byteLength; } else { console.error("Read error: " + evt.target.error); showError("Ошибка чтения файла: " + evt.target.error); return; } if (offset >= fileSize) { cbToFinish() return; } // to the next chunk chunkReaderBlock(offset, chunkSize, file); } chunkReaderBlock = function(_offset, _chunkSize, _file) { var r = new FileReader(); if (_file.slice) { var blob = _file.slice(_offset, _chunkSize + _offset); } else if (_file.webkitSlice) { var blob = _file.webkitSlice(_offset, _chunkSize + _offset); } else if (_file.mozSlice) { var blob = _file.mozSlice(_offset, _chunkSize + _offset); } r.onload = readEventHandler; r.readAsArrayBuffer(blob); } // start reading the first block chunkReaderBlock(offset, chunkSize, file); }

Следует учесть, что поскольку подписание выполняется локально, то для последующей передачи выбранного пользователем файла и подписи на сервер необходимо реализовать соответствующую логику на стороне веб-страницы.

Правила установки плагина КриптоПро CSP в Mozilla Firefox отличаются в зависимости от версии браузера - 52 и выше, либо более старая.

Mozilla Firefox версии ниже 52

Чтобы подписывать документы в Mozilla Firefox:

• Отключите автоматическое обновление. Для этого перейдите в «Меню» ⇒ «Настройки» ⇒ «Дополнительные» ⇒ «Обновления» (Рис. 1).

• Установите версию 51.0.1 с официального сайта Mozilla Firefox .

Для установки КриптоПро Browser plug-in необходимо выполнить действия:

1. Скачайте программу установки с официального сайта компании «Крипто-Про» www.cryptopro.ru/products/cades/plugin и запустите исполняемый файл.

2. В окне установки КриптоПро Browser plug-in нажмите кнопку «Да» (Рис. 2-а).

3. Дождитесь завершения установки (Рис. 2-б).

4. Нажмите кнопку «Ок» и перезапустите интернет-браузер (Рис. 2-в).

Важно

После установки КриптоПро Browser plug - in необходимо проверить, установлено ли в браузере дополнение для работы с электронной подписью КриптоПро ЭЦП Browser plug-in для браузеров.

5. Откройте браузер, нажмите кнопку «Меню браузера», выберите раздел «Дополнения» (Рис. 3).

6. Откройте вкладку «Плагины». Напротив плагина «CryptoPro CAdES NPAPI Browser Plug-in» в выпадающем меню выберите опцию «Всегда включать» (Рис. 4).

7. Перезапустите браузер.

Mozilla Firefox версии 52 и выше

Для установки КриптоПро Browser plug-in выполните действия:

1. Перейдите по ссылке www.cryptopro.ru/products/cades/plugin , затем выберите «расширение для браузера» (Рис. 5).

Рис. 5. Сайт КриптоПро

2. Нажмите «Разрешить» (Рис. 6).

Рис. 6. Разрешение запроса

3. Нажмите «Добавить» (Рис. 7).

На некоторых сайтах приходится иметь дело с сертификатами и электронными ключами, и поначалу приходится решать разные проблемы, чтобы всё заработало. В этой статье речь пойдёт об ошибке работы CAdES plugin’а, когда он загружен, а объекты не создаются.

Решение проблемы с плагином

Как и следует из содержания ошибки, сам по себе CAdES plugin вроде бы как загружен, т.е. он есть в системе, однако что-то мешает его работе. Обычно проблема возникает в старых версиях Firefox вплоть до версии 51 (в более новых плагин просто не работает). В данной статье в качестве примера взята электронная торговая площадка, и есть три способа, как можно решить проблему.

Способ 1: Включить плагин для текущего сайта

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

Способ 2: Включить плагин для всех сайтов

Если вопрос безопасности не сильно беспокоит, т.к. компьютер используется исключительно для работы на нескольких сайтах, можно включить CAdES plugin для всех сайтов. Тогда он будет работать сразу же после загрузки страницы. Это может помочь и в том случае, когда невозможно найти тёмно-серый квадрат для включения плагина.

Способ 3: Использование другого браузера

По каким-то непредвиденным причинам CAdES plugin всё равно может отказываться работать. Поэтому ещё один способ устранить ошибку — использовать другой браузер. Большинство браузеров основано на движке Chromium, они все чем-то похожи, поэтому рассмотрим на примере Google Chrome.

Заключение

Как видно, существует несколько способов решить проблему с некорректной работой плагина. В зависимости от предпочтений и обстоятельств, можно выбрать для себя тот, который больше всего подходит.

Всем привет! Наверняка, многие пользователи могли наблюдать на своем экране монитора ошибку «Не удалось загрузить плагин» при воспроизведении онлайн аудио, видео либо при попытке запустить какую нибудь флеш-анимацию (игру, баннер, приложение и пр.). Если Вы попали на эту страницу, то вероятнее всего Вы увидели похожую ошибку. Сегодня в этой небольшой инструкции мы с Вами устраним ошибку «Не удалось загрузить плагин » в браузере быстро и легко.

Сперва, друзья, давайте разберемся, что вообще такое плагин в браузере. Плагин – это другими словами дополнение, которое расширяет возможности интернет-браузера. Плагинов на сегодняшний день огромное количество, и все они разного направления. В любом браузере установлены базовые плагины, дабы правильно отображать веб-ресурсы. Если в браузере появилось сообщение о том, что не удалось загрузить плагин, то, скорее всего, проблема в Flash Player. Ниже мы с Вами рассмотрим несколько способов, благодаря которым можно исправить данную ошибку.

1-й способ. Обновляем интернет-браузер

2-й способ. Чистим историю в браузере

Cache – временные файлы браузера, которые хранят в себе все веб-компоненты просмотренных ресурсов (изображения, страницы, видеофайлы, дизайн и пр.). Благодаря КЭШу браузер быстро загружает страницы ранее посещаемых сайтов, так как загрузка компонентов ресурса осуществляется не через интернет, а с локального диска компьютера.

Cookie – также временные файлы, в которых хранится персональные данные юзера (логины, пароли, настройки сайтов и пр.). При переходе на какую либо страницу все эти данные браузер отсылает на сервер, и поэтому мы можем заходить на любой ресурс, не вбивая заново логин и пароль для авторизации.

Итак, давайте же очистим Cache и Cookie в своем браузере, дабы попытаться устранить ошибку. Идем в меню, выбираем «История».

3-й способ. Отключаем лишние плагины

Если используете Chrome, то вбивайте в адресной строке chrome://plugins
Если используете Yandex, то вбивайте в адресной строке browser://plugins
Если используете Opera, то вбивайте в адресной строке opera://plugins
Если используете Firefox, то вбивайте в адресной строке аbout:plugins

4-й способ. Повторная установка Adobe Flash Player