I'm fairly new to Drupal (Drupal 8) and OPcode caching.

I hate to have warnings, and checked with my hosting provider who assured me that OPcode caching was enabled.
I configured my php.ini with the necessary information, and checked that my cache folder was indeed filling up with information from people visiting my site.

Yet the warning:
PHP OPcode caching Not enabled
PHP OPcode caching can improve your site's performance considerably. It is highly recommended to have OPcache installed on your server.

Still persists.

I have also checked my phpinfo from the status report, and it states (at the bottom):
This program makes use of the Zend Scripting Language Engine:
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

Why am I still getting a warning?

Comments

krishnakrgupta’s picture

Please add this line into your php.ini file location

[opcache]
zend_extension=php_opcache.dll
;Determines if Zend OPCache in enabled
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1

Tharick’s picture

its working for me, thanks

lolhonk’s picture

Thank u very much! That worked for me too!

sprite’s picture

On a Linux machine change the .dll to .so as in the following example:


zend_extension=php_opcache.so
;Determines if Zend OPCache in enabled
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1


spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...

Christopher James Francis Rodgers’s picture

Potential respondents:

Especially for the benefit of day-one Drupal users, and other newbies like me, and because this page is the first drupal.org page from a Google search of 'PHP OPcode caching', I am hoping to get further clarification before I start hacking, to spare myself the all-too-familiar time/torture of trial-and-error Drupal solution attempts. Thanking you in advance from myself, and from the thousands of others who are likely to visit this page.

===

Current PHP version of my webhosting account (on a UNIX server):

I have the option in my webhosting Control Panel to set the version of PHP that is used across the entire account for all sites:

Hosting 'CPanel' > heading "programming" > icon "PHP Config"

Currently is it set on "PHP 5.6 (FastCGI)", and works fine for my Drupal 7 sites, which are each in a separate subfolder of 'public_html'.

I just installed my first Drupal 8.3 site, and it gave the error this page attends to, but I completed the installation anyway, by clicking the text-link reading something similar to, "Continue anyway".

Note to newbies:
When the PHP option is changed in the webhost Control Panel, the files "php.ini", and ".htaccess" in the account's root folder at "public_html/php.ini", and "public_html/.htaccess" are automatically updated (or are created in the rare case they are not existing). Also, a backup copy of the former files (as applicable) are also generated, time-stamped (of sorts, Eg.: ".htaccess.bak.1495181202"), and are placed in the same folder.

Other current webhosting PHP options include:
- "PHP 7.0 [Beta, ..."
- "PHP 7.0 (Single php.ini) [Beta, ..."
- "PHP 7.0 (FastCGI) [Beta, ..."

Because the drupal.org issue "Fully support PHP 7 in Drupal 7" (https://www.drupal.org/node/2656548) is still Not fully resolved, I am hesitant to change my webhost account to using PHP 7 for fear that it will adversely affect my D7 live 'production' sites, particularly since that might be in ways that are not immediately apparent to me.

I vaguely recall reading somewhere that 'OPcode caching' is already suppported in PHP 5.6.

---

Question 1:

Are the code recommendations above intended for sites running PHP 5.6, or for PHP 7.0, or for both?

...assuming that your solutions are designed to correct situations where the PHP configuration, of the version(s) you are targeting, simply does(do) not have 'OPcache' enabled by default. Or can OPcache generally be expected to be enabled by default with PHP 7.0?

Questions 2:

*.dll vs *.so

Am I correct in my assumption that the line of code in the first example above, zend_extension=php_opcache.dll is intended for Windows servers only, and that I should instead use the second example above with the code zend_extension=php_opcache.so given that I am using an online shared webhosting account on a UNIX server? And, as an aside, if you know, is it possible that the *.dll might work for some people using UNIX?

Question 3:

[opcache]

I notice that the first example uses the code [opcache], whereas the second example does not.

Is that 'optional', 'actually required', or 'a problem if included'?

Questions 4:

What php.ini file?

Noting again that each of my D7 and D8 sites are all in separate unique subfolders of 'public_html':

Can your code be used in the existing PHP 5.6 php.ini file at "public_html/php.ini", without fear of it adversely affecting my D7 sites, and without adversely affecting other Drupal administrators who are running additional non-Drupal applications at their webhosts?

Or, does your code need to go into a php.ini file in the root of the D8 site at "[d8-root]/php.ini" (in a php.ini file of our creation, given that the default D8 'completed' installation does not include a php.ini file)?

And if your code can be, or were to be, used in "[d8-root]/php.ini", will it automatically be seen and used, or does the php.ini file then require being linked to by another file, as for example, the "[D8-root]/.htaccess" file?

Questions 5:

Where 'within' existing php.ini file?

Can your code be placed 'anywhere' in an existing 'php.ini' file (if and when it is pre-existing), or does it necessarily have to follow (or precede) certain other specific code declarations that a user may be using in their 'php.ini' file; and if so, what are those specific other code statements to be aware of, and should your solution precede or follow each of those fragments we should 'look out for'?

Question 6:

'Local' considerations

What other considerations, details, and specific instructions might you have for users who are developing 'locally'? ('locally': sites on a computer, instead of online at webhost)

Question 7:

Since I cannot restart my online server, as I have seen recommended/required for 'local' servers, what do I need to do instead, if anything, for my online situation?

Question 8:

On the Drupal 8 "Reports" > "Status report" page ([D8-root]/admin/reports/status) under the heading "Warnings found": "PHP OPcode caching", there is a link to the page "PHP:Installation - Manual" at php.net (http://php.net/manual/en/opcache.installation.php).

On that page under the heading "Recommended php.ini settings", the block of 'recommended' code includes one line at the bottom which is Not in the examples above:

opcache.enable_cli=1

Can anyone who speaks PHP tell us lay-persons the relative benefits of using, vs. not using, that code.

===

Thanking you kindly in advance for your attention, time, patience, and help, and welcoming your answer to even a single question, if that is all you know, or if that is all you have the time for 'registering' and 'answering' here at drupal.org.


All the best; intended.
-Chris (great-grandpa.com)
___
"The number one stated objective for Drupal is improving usability." ~Dries Buytaert *

s427’s picture

Also, please note that the opcache.revalidate_freq=60 directive can cause your PHP code to be put in cache for 60 seconds, which can be annoying if you're working on other (simpler) PHP projects. If a PHP file has been cached and you make changes to it, you won't see the changes in the browser for the next 60 seconds; very annoying if you're constantly moving back and forth between your PHP code and the browser.

I'm not sure why 60 is suggested as a value for this directive, but I've changed it to 1 so I don't have this problem when working on smaller project (on my development machine, of course).

Christopher James Francis Rodgers’s picture

This is strictly in reference to online Drupal 7, and 8 sites,
at a webhost (bluehost.com) that uses a third party Control Panel,
which might be the exact same Control Panel used by your webhost,
or, if nothing else, might use the same tool to modifify
the version of PHP used on your account.

---

Trials

I 'unsuccessfully' tried using the code above
at the bottom of my "public_html/php.ini" file;
and in a newly created php.ini file in the root folder
of my Drupal 8 site.

It did Not help to run 'update.php' or 'Clear all caches'
or 'Run cron'.

I switched my webhost account to
"PHP 7.0 (FastCGI) [Beta, ..."
at:

Hosting 'CPanel' > heading "programming" > icon "PHP Config"

It may take you a few minutes for the change to PHP 7.0
to take affect, but, in my case, the affect was immediate.

---

Panic

My freshly installed Drupal 8 site was rendered unusable,
and displayed the error:

Fatal error: Undefined class constant 'MYSQL_ATTR_USE_BUFFERED_QUERY' in /home2/greatgs5/public_html/[*SUBFOLDER*]/[*DRUPAL_8_ROOT*]/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php on line 134

My Drupal 7 sites were also broken, displaying the error:

Fatal error: Undefined class constant 'MYSQL_ATTR_USE_BUFFERED_QUERY' in /home2/greatgs5/public_html/[*SUBFOLDER*]/[*DRUPAL_7_ROOT*]/includes/database/mysql/database.inc on line 56

---

Back-track

At my webhost Control Panel, I set my PHP version
back to what it had been:

"PHP 5.6 (FastCGI)"

---

More panic

My Drupal 7 and 8 site remained broken with the same error,
and running 'update.php' did Not help the D7, or D8 sites.

Note:
Having repeated this entire nightmare again,
just to make sure-- before I post this tale--
I now believe that if I had waited a few minutes longer,
(the first time around)
a few minutes more, that is, than I already had,
the problem may have resolved itself,
but what I did next (the first time around)
seemed to immediately resolve the 'dead sites' issue.

---

Sites recovered

I deleted the webhost root 'php.ini' file at
"public_html/php.ini".

At the webhost Control Panel 'PHP Configuration' page,
I again selected the radio-button "PHP 5.6 (FastCGI)",
and again clicked the page-bottom button
"SAVE CHANGES".

My Drupal 7 and 8 sites immediately came back to life
as normal.

---

OPcache [Solved]

I opened the "public_html/php.ini" file
in the online 'Control Panel' 'File Manager' editor,
(though I could have edited it locally, and then uploaded it)
and I noticed that the very last line was:

;zend_extension=/usr/php/[*ARBITRARY-NUMBER*]/usr/lib64/php/modules/opcache.so

I removed the ";" from the beginning of that line of code,
since the ";" is the character used at the beginning
of a PHP line of code to have it commented-out/ignored.

Success...

My Drupal 8 site no longer displays the 'Status report' warning
"PHP OPcode caching not enabled";
and, to repeat, my webhost account is now set at:
"PHP 5.6 (FastCGI)".

###


All the best; intended.
-Chris (great-grandpa.com)
___
"The number one stated objective for Drupal is improving usability." ~Dries Buytaert *

ravimane’s picture

working for me