Cannot redeclare class view, updating to PHP5.5

UPDATE: DON'T USE THE SOLUTION ABOVE, READ BELOW.

This has nothing to do with PHP 5.5. It's not valid to include a class twice in any version of PHP.

This has to do with somehow having two separate copies of Views being invoked in a way that shouldn't be possible. It's not really up to Views to defend against this stuff; it's a bug in whatever is including the second copy of Views.

PLEASE DO NOT USE the solution in the initial post, you'll just be patching a symptom. As merlinofchaos stated, it is not Views' responsibility to make sure that a particular php file is included only once.

If you're getting this error make sure that you've resolved any error reported by watchdog first and then errors in your server's logs. I went through all my logs and config files and was able to figure out the problem. In my case Drupal was getting stuck trying to write a file to the /tmp directory and for some reason would include views.inc again.

Thanks Merlin!
-G

Also, check your APC or Xcache configs--start by disabling them to see if they are the culprits.

Added error log line for 7.x version

I get the described behaviour on a fresh installation of drupal, with ctools and views installed and nothing else. So whatever is causing the error, it must be within the ctools/views sphere. I would therefore ask for the issue to be reopened.
For what it's worth, the error appears when I enable views-ui.

Configuration:
Apache: 2.4.6 (Ubuntu)
php: 5.5.3-1ubuntu2.1
drupal 7.25
views 7.x-3.7

I have this same issue,
clean install and these versions:

http://pastebin.com/1MrKRiJh

opcache.enable=0 in php.ini fixed this for me,
so it is a server configuration problem.

Same as #7, never ever had a problem with xcache until I got bit by this. The built-in opcache included in php + xcache must be why there is a fatal can't redeclare(cached in both).

I am using an opcache_blacklist now
[PATH TO YOUR SITE]/views/includes/view.inc

http://www.php.net/manual/en/opcache.configuration.php#ini.opcache.black...

Hi
i had this same problem,
i only disable php5-xcache and the site return to normal.
haa also stopped with error!

I got the same problem and disabling xcache makes the site go back to normal.

Could it be a bug in the implementation of require_once() in X-Cache? Darn... sites are going to be slow without it...

I got the same problem after installing php5-xcache.

PHP Fatal error: Cannot redeclare class view in ...

After digging for possible solution I found out that the problem is due to the value set in xcache.mmap_path. I changed it to /tmp/xcache and it works as intended.

Steps I did in my Ubuntu machine:
1. Increased the size of xcache.size to 120M in /etc/php5/mods-available/xcache.ini.
2. sudo service apache2 reload

See the attached screenshot.

My xcache.ini:

; configuration for php Xcache module

[xcache-common]
;; non-Windows example:
extension = xcache.so
;; Windows example:
; extension = php_xcache.dll

[xcache.admin]
xcache.admin.enable_auth = On
; Configure this to use admin pages
xcache.admin.user = "root"
; xcache.admin.pass = md5($your_password)
xcache.admin.pass = "5f4dcc3b5aa765d61d8327deb882cf99"

[xcache]
; ini only settings, all the values here is default unless explained

; select low level shm implemenation
xcache.shm_scheme =        "mmap"
; to disable: xcache.size=0
; to enable : xcache.size=64M etc (any size > 0) and your system mmap allows
xcache.size  =               120M
; set to cpu count (cat /proc/cpuinfo |grep -c processor)
xcache.count =                 1
; just a hash hints, you can always store count(items) > slots
xcache.slots =                8K
; ttl of the cache item, 0=forever
xcache.ttl   =                 0
; interval of gc scanning expired items, 0=no scan, other values is in seconds
xcache.gc_interval =           0

; same as aboves but for variable cache
xcache.var_size  =            4M
xcache.var_count =             1
xcache.var_slots =            8K
; default value for $ttl parameter of xcache_*() functions
xcache.var_ttl   =             0
; hard limit ttl that cannot be exceed by xcache_*() functions. 0=unlimited
xcache.var_maxttl   =          0
xcache.var_gc_interval =     300

; mode:0, const string specified by xcache.var_namespace
; mode:1, $_SERVER[xcache.var_namespace]
; mode:2, uid or gid (specified by xcache.var_namespace)
xcache.var_namespace_mode =    0
xcache.var_namespace =        ""

; N/A for /dev/zero
xcache.readonly_protection = Off
; for *nix, xcache.mmap_path is a file path, not directory. (auto create/overwrite)
; Use something like "/tmp/xcache" instead of "/dev/*" if you want to turn on ReadonlyProtection
; different process group of php won't share the same /tmp/xcache
; for win32, xcache.mmap_path=anonymous map name, not file path
xcache.mmap_path =    "/dev/zero"
;xcache.mmap_path =    "/tmp/xcache"


; Useful when XCache crash. leave it blank(disabled) or "/tmp/phpcore/" (writable by php)
xcache.coredump_directory =   ""
; Windows only. leave it as 0 (default) until you're told by XCache dev
xcache.coredump_type =         0

; disable cache after crash
xcache.disable_on_crash =    Off

; enable experimental documented features for each release if available
xcache.experimental =        Off

; per request settings. can ini_set, .htaccess etc
xcache.cacher =               On
xcache.stat   =               On
xcache.optimizer =           Off

[xcache.coverager]
; enabling this feature will impact performance
; enabled only if xcache.coverager == On && xcache.coveragedump_directory == "non-empty-value"

; per request settings. can ini_set, .htaccess etc
; enable coverage data collecting and xcache_coverager_start/stop/get/clean() functions
xcache.coverager =          Off
xcache.coverager_autostart =  On

; set in php ini file only
; make sure it's readable (open_basedir is checked) by coverage viewer script
xcache.coveragedump_directory = ""

Not sure if this is the real cause of the problem.

UPDATE:

After several reload I'm again experiencing the WSOD. I manually clear the cache in Xcache admin and then reload the pages again and this time it is working fine.

so whats the point of having both xcache and zend opcache enabled? disable one of them and error goes away.
zend opcache in in php core since 5.5 so i would disable xcache. here is a quick way to do this in .htaccess

<IfModule mod_php5.c>
  php_value xcache.cacher Off
  php_value xcache.size 0
  php_value xcache.stat Off
</IfModule>

sorry didnt mean to change status. this is not a views problem

Same as #7, thx, for the hint, Daniel!!

edit /etc/php5/apache2/php.ini
-> opcache.enable=0

#7 worked for us too, thanks

#7 is not a fix, it is a work arround.
Beter use #9

Still a work around but less cache destructive.

@danielbeeke actually it was a fix in our case as we accidentally had opcache AND xcache turned on, there for #7 was the right solution. Blacklisting a single class would've just made other classes throw the same errors.

In order to fix this issue with php 5.5 fpm you have to set this opcache variable:
opcache.dups_fix=1

See: http://php.net/manual/en/opcache.configuration.php#ini.opcache.dups-fix

#19 worked for me in .htaccess:
php_flag opcache.dups_fix TRUE
EDIT:
The error now comes 5 % of the time...
So used #13 instead. No problems.

I was having this problem after moving from CentOS 5.11 (PHP 5.2.10, Zend v2.2.0) to Ubuntu 14.04.1 LTS (PHP 5.5.9, Zend v2.5.0).

Without doing my homework, I decided to install XCache also.

Since PHP 5.5 comes with Zend OPcache, I ended up with both enabled.

It looked like this:
PHP 5.5.9-1ubuntu4.5 (cli) (built: Oct 29 2014 11:59:10)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with XCache v3.1.0, Copyright (c) 2005-2013, by mOo
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
with XCache Optimizer v3.1.0, Copyright (c) 2005-2013, by mOo
with XCache Cacher v3.1.0, Copyright (c) 2005-2013, by mOo
with XCache Coverager v3.1.0, Copyright (c) 2005-2013, by mOo

After some research, it seems that Zend OPcache provides the best performance between all of the PHP Cache options available, so I removed XCache and am using OPcache now and everything is working perfectly.

php -v now looks like this:
PHP 5.5.9-1ubuntu4.5 (cli) (built: Oct 29 2014 11:59:10)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies

Here's a comparison of OPcache, XCache and No-Caching:
http://massivescale.blogspot.com/2013/06/php-55-zend-optimiser-opcache-v...

after half of my day digging between zend xcache apache2 and php config files i found this post and reply in #7 save my night thanks a lot
i try #13 and it works to

imkael

#13 worked for me as I didn't have any access to php.ini, so I had to modify the .htaccess.

# 13 saved my day, or should we say my Days. I have had terrible problems for a long period of time and as the problem has come and gone it has been a hassel to figure out what it was about. There have been no leads in the logs and today for the first time the error code put into index.php gave a clear answer and that took me to this discussion.

I use Xcache for Prestashop so I wanted to keep it so the solution in #13 is perfect for me, just to add it to .htaccess.

Many big thanks too all of you, but mostly to ParisLiakos !!!

Hans

#13 solves this issue!

Please see #13.

I had the site problem white blank page regardless of any address or url, a long time ago when enabling "php5-xcache" for ubuntu server. The site used to work fine just before enabling the php5-xcache, so disabling the xcache just fixed the problem for good.

Today with a new server config I totally forgot about the xcache thing and installed fresh new drupal dev site for some testing, and facing this problem I found this forum, reminding me of the previous trouble I faced before.

Though the problem is less than before - at least apparently the site seems working except not updating and clearing caches and not doing cron jobs etc... So, If someone is on a ubuntu server with this same issue, if any better solution is not avail, just get rid of the xcache,

What I just did on the ubuntu server = In the terminal, just type and entered:
==> sudo apt-get --purge autoremove php5-xcache
After that I made apache server to restart (or not working or showing the result until the server restart)
==> service apache2 restart

You may have other better solutions not disabling this xcache, but I just wanted never have another same issue with drupal for good at least till the thing gets better working with drupal.

Here is my php.ini info for blacklisting fix in #9 which is a workaround for now. Thxs, danielbeeke

[opcache]
; Determines if Zend OPCache is enabled
;opcache.enable=0

; Determines if Zend OPCache is enabled for the CLI version of PHP
;opcache.enable_cli=0

; The OPcache shared memory storage size.
opcache.memory_consumption=128

; The amount of memory for interned strings in Mbytes.
;opcache.interned_strings_buffer=4

; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 100000 are allowed.
;opcache.max_accelerated_files=2000

; The maximum percentage of "wasted" memory until a restart is scheduled.
;opcache.max_wasted_percentage=5

; When this directive is enabled, the OPcache appends the current working
; directory to the script key, thus eliminating possible collisions between
; files with the same name (basename). Disabling the directive improves
; performance, but may break existing applications.
;opcache.use_cwd=1

; When disabled, you must reset the OPcache manually or restart the
; webserver for changes to the filesystem to take effect.
;opcache.validate_timestamps=1

; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
;opcache.revalidate_freq=2

; Enables or disables file search in include_path optimization
;opcache.revalidate_path=0

; If disabled, all PHPDoc comments are dropped from the code to reduce the
; size of the optimized code.
;opcache.save_comments=1

; If disabled, PHPDoc comments are not loaded from SHM, so "Doc Comments"
; may be always stored (save_comments=1), but not loaded by applications
; that don't need them anyway.
;opcache.load_comments=1

; If enabled, a fast shutdown sequence is used for the accelerated code
opcache.fast_shutdown=1

; Allow file existence override (file_exists, etc.) performance feature.
;opcache.enable_file_override=0

; A bitmask, where each bit enables or disables the appropriate OPcache
; passes
;opcache.optimization_level=0xffffffff

;opcache.inherited_hack=1
;opcache.dups_fix=0

; The location of the OPcache blacklist file (wildcards allowed).
; Each OPcache blacklist file is a text file that holds the names of files
; that should not be accelerated. The file format is to add each filename
; to a new line. The filename may be a full path or just a file prefix
; (i.e., /var/www/x  blacklists all the files and directories in /var/www
; that start with 'x'). Line starting with a ; are ignored (comments).
opcache.blacklist_filename=/var/www/memcahe_blacklist.txt

; Allows exclusion of large files from being cached. By default all files
; are cached.
;opcache.max_file_size=0

; Check the cache checksum each N requests.
; The default value of "0" means that the checks are disabled.
;opcache.consistency_checks=0

; How long to wait (in seconds) for a scheduled restart to begin if the cache
; is not being accessed.
opcache.force_restart_timeout=180

; OPcache error_log file name. Empty string assumes "stderr".
;opcache.error_log=

; All OPcache errors go to the Web server log.
; By default, only fatal errors (level 0) or errors (level 1) are logged.
; You can also enable warnings (level 2), info messages (level 3) or
; debug messages (level 4).
;opcache.log_verbosity_level=1

; Preferred Shared Memory back-end. Leave empty and let the system decide.
;opcache.preferred_memory_model=

; Protect the shared memory from unexpected writing during script execution.
; Useful for internal debugging only.
;opcache.protect_memory=0

and blacklist file is simply:
/var/www/drupal/sites/all/modules/contrib/views/includes/view.inc

I also changed a few other things from defaults including memory. Basically everything that is no longer commented out.

Same as #7,

edit /etc/php5/apache2/php.ini
-> opcache.enable=0

We had this same issue after upgrading to PHP 5.6. The solution, which most have already discovered, was that we had two opcode caches running (Zend and XCache) by accident. Apparently an old xcache config sneaked back into our configuration during the upgrade (it had previously been disabled). Removing XCache solved the issue.

#13 is not help for me :( and #7 -> opcache.enable=0 is a very drastic solution I think, because if we have another webpages on the server it will be very slow, and as I heard, if we turn off opcache on the server for all webpages, the Drupal 8 will be not running. :(

So I think the best solution is to put: php_flag opcache.enable Off|| line in the .htaccess file only for the webpage which is not running with opcache. This is help for me!

I was getting this error sporadically on various pages of my org's website. A few weeks ago, we switched from using Xcache to OPcache, so I had disabled Xcache for the VPS through the Dreamhost panel. However, looking at the phprc file saved on our VPS server (Dreamhost doesn't allow VPS users to manipulate the system php.ini file directly), this was at the bottom of the file twice:

extension=xcache.so

Deleting those lines in the phprc file seem to have fixed the problem.

opcache.enable=0 in php.ini fixed this for me,

I have experienced the same problem and disable the opcache it's not a good solution because you are worsening the performance.

In my case this error is caused by a bad module upgrade process in the past. When we update a module normally simply drop the new files in the module folder, this is fine for new and updated files but if the new version have deleted an old file with this process removed files will remain, normally this unused files are hamless, just junk... but with opcache sometimes cause errors.

So, I have solved the problem simply with this steps:

1. Completly remove the views module folder in your server
2. Download the last version from Drupal site
3. Unzip and upload the new module folder
4. Run update.php

#19 fixed my problem.

See php opcache official docs: http://php.net/manual/en/opcache.configuration.php#ini.opcache.dups-fix

#35 worked for me. Thanks pdxgimlet!

#35 also worked for me! (I'm also a Dreamhost user). Thanks pdxgimlet!