I have installed this extension and PHP status page shows the extension.
However I am unable to use the Project installer - this is the message as below:
Sorry, it seems that the PHP .zip extension is not loaded on your server. You will not be able to download any projects using Project Installer until this is fixed. Please contact your website administrator.
Curiously, the status page does not show zip . . .
What am I missing?
Hmmm . . after posting this, I ran update.php script for the site I was having trouble with - although I am not sure I understand why this was necessary as the extension is to PHP and update.php is to just one of my sites on the server - "wheird"), but just for S's & G's, (Sh**s & Grins), I ran it anyway - and the problem has resolved.
Hmmm . . after posting this, I ran update.php script for the site I was having trouble with - although I am not sure I understand why this was necessary as the extension is to PHP and update.php is to just one of my sites on the server - "wheird"), but just for S's & G's, (Sh**s & Grins), I ran it anyway - and the problem has resolved.
Thanks for the follow-up @abqgman! That is a strange problem. I wonder, when you ran update.php were there updates that were needed for your system? Or did the updater tell you that no updates were necessary?
If the latter, then what Backdrop needed was to have it's caches cleared - as those are cleared automatically when visiting update.php.
This was actually a brand new BD install. What was peculiar is that the BD PHP status page showed the extension installed when viewing at admin/reports/status/php, but viewing admin/reports/status/ does not. Your assessment iseems correct - seems like a cache thing.
The next time I do a BD install, I'll be on the lookout for the behavior and update here with my exact steps if I am able to reproduce. Thanks for the reply.
I have same issue with new backdrop install
php-zip seems good
$ php -m
[PHP Modules]
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
readline
Reflection
session
shmop
SimpleXML
sockets
sodium
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib
[Zend Modules]
Zend OPcache
ls -l /etc/php/7.3/apache2/conf.d/20-zip.ini
lrwxrwxrwx 1 root root 35 Aug 13 12:29 /etc/php/7.3/apache2/conf.d/20-zip.ini -> /etc/php
# php --ini
Configuration File (php.ini) Path: /etc/php/7.3/cli
Loaded Configuration File: /etc/php/7.3/cli/php.ini
Scan for additional .ini files in: /etc/php/7.3/cli/conf.d
Additional .ini files parsed: /etc/php/7.3/cli/conf.d/10-mysqlnd.ini,
/etc/php/7.3/cli/conf.d/10-opcache.ini,
/etc/php/7.3/cli/conf.d/10-pdo.ini,
/etc/php/7.3/cli/conf.d/15-xml.ini,
/etc/php/7.3/cli/conf.d/20-calendar.ini,
/etc/php/7.3/cli/conf.d/20-ctype.ini,
/etc/php/7.3/cli/conf.d/20-curl.ini,
/etc/php/7.3/cli/conf.d/20-dom.ini,
/etc/php/7.3/cli/conf.d/20-exif.ini,
/etc/php/7.3/cli/conf.d/20-fileinfo.ini,
/etc/php/7.3/cli/conf.d/20-ftp.ini,
/etc/php/7.3/cli/conf.d/20-gd.ini,
/etc/php/7.3/cli/conf.d/20-gettext.ini,
/etc/php/7.3/cli/conf.d/20-iconv.ini,
/etc/php/7.3/cli/conf.d/20-json.ini,
/etc/php/7.3/cli/conf.d/20-mbstring.ini,
/etc/php/7.3/cli/conf.d/20-mysqli.ini,
/etc/php/7.3/cli/conf.d/20-pdo_mysql.ini,
/etc/php/7.3/cli/conf.d/20-phar.ini,
/etc/php/7.3/cli/conf.d/20-posix.ini,
/etc/php/7.3/cli/conf.d/20-readline.ini,
/etc/php/7.3/cli/conf.d/20-shmop.ini,
/etc/php/7.3/cli/conf.d/20-simplexml.ini,
/etc/php/7.3/cli/conf.d/20-sockets.ini,
/etc/php/7.3/cli/conf.d/20-sysvmsg.ini,
/etc/php/7.3/cli/conf.d/20-sysvsem.ini,
/etc/php/7.3/cli/conf.d/20-sysvshm.ini,
/etc/php/7.3/cli/conf.d/20-tokenizer.ini,
/etc/php/7.3/cli/conf.d/20-wddx.ini,
/etc/php/7.3/cli/conf.d/20-xmlreader.ini,
/etc/php/7.3/cli/conf.d/20-xmlwriter.ini,
/etc/php/7.3/cli/conf.d/20-xsl.ini,
/etc/php/7.3/cli/conf.d/20-zip.ini
and my report from
Backdrop CMS 1.13.3 Base de données SQL MySQL, MariaDB, or equivalent version 5.5.5-10.3.15-MariaDB-1 php Version 7.3.4-2 (information PHP) Prise en chage de MySQL Database 4-byte UTF-8 Non activé more Serveur web Apache/2.4.38 (Debian) Accès à update.php Protégé Affichage des messages d'erreur désactivé more Bibliothèque Unicode Extension PHP mbstring Droits d'accès au nœud désactivé (Reconstruire les droits d'accès) more Effets de rotation et de désaturation de la bibliothèque GD 2.2.5 Extensions PHP Activées : date, dom, filter, gd, hash, json, pcre, pdo, session, SimpleXML, SPL, xml
Hi everyone,
It looks like we have some problems relating to the php zip extension, so I have opened a core issue to get it fixed: https://github.com/backdrop/backdrop-issues/issues/3978
Please feel free to weigh in there if you believe there is anything I've missed or if you have something else that the core team should know.
Hi Backdrop team!
Well, after a couple of COVID years focusing on datacenter solutions; we're moving work back into the software solutions side of the business, so last week I spun-up another BackdropCMS instance to begin work porting over from Drupal 7. I can confirm the original issue I reported in 2018 is still a problem, but I can also confirm that the workaround solution suggested ( I think by herbdool?) to run update.php also, still works.
How do I know this - I had long forgotton the issue, so when I ran into again, I googled it and came to my own BackdropCMS forum post. Duh!
Just an FYI - I wanted to keep the issue alive - like Sam Walton's dog - "Gone, but not forgotten".
Members of the core team are asking for any additional information or if possible step to reproduce the problem. If you are experiencing this problem, please take a look at this issue in Github and if possible provide us with additional information.
Hi stpaultim,
Running update.php does indeed fix the problem. Perhaps that is a result of that script clearing caches as "drop" reported above?
When I install a new BD, I generally install many commonly used modules and a theme at the same time without running update.php.
When I installed BD this time (by the way, we do this in a Hyper-V VM):
As for why only a couple of us have ever reported the problem, perhaps it is simply a procedural thing in that I don't think about running update.php after a clean install of BD, or when using the BD module installer.
If I remember correctly, with Drupal, it was recommended to run update.php after every module install, but using the BD module installer, I just assumed update.php was being run, so I no longer do that - perhaps that's a clue?
Hopefully, this helps, I would have to setup another BD instance to get more detail, I wasn't paying that close attention at the time I did this one.
PHP Extension not loading/showing in Backdrop CMS
This is a LAMP problem that affects how Backdrop CMS "sees" the LAMP stack.
If the LAMP stack (running in memory) doesn't reflect the reality of the LAMP stack (as installed on disk) Backdrop CMS going to reflect that disconnect.
Let me explain. I had the same situation occur with a fresh Backdrop CMS install on Tiny Core Linux, which features a version of PHP that has only a very tiny amount of compiled-in extensions. If you run Tiny Core, you are expected to extend PHP with loadable modules (i.e. ZIP and MySQL).
With respect to enabling PDO (a MySQL database abstraction extension for PHP), the issue went away when I :
The re-start of the Apache server forced the LAMP stack (running in memory) to reflect the reality of the LAMP stack (as installed on disk).
This, in turn, enabled Backdrop CMS to "see" the installed extensions.
g.
----
Let me quickly paste here what I've just posted on https://github.com/backdrop/backdrop-issues/issues/3978#issuecomment-242...
I've hit the same problem today, found https://forum.backdropcms.org/forum-topic/php-zip-extension-issue-192 and then this issue. My conclusion is the problem is not related to specifically PHP zip extension, but site cache. Site cache needs to be cleared at certain point for it to see newly installed PHP extensions.
Hello @alanmels,
tl;dr
Run update.php:
http://{www.mysite.com}/update.php
Then restart Apache
$ sudo service apache2 restart
$ sudo service httpd restart
Long explanation:
I am not certain that even clearing the Backdrop CMS site cache is going to get you over the goal line when it comes to enabling a PHP extension.
Remember, Backdrop CMS is a Web Application written in PHP. The changes being discussed here are occurring out of scope of Backdrop CMS; they are actually happening at the PHP layer of the LAMP stack. Actually, in this context, it may be more appropriate to call it a LAMPB stack, where B stands for "Backdrop CMS."
There's an order of precedence at play.
From your perspective, things look like this:
Backdrop (not working) -> "THE SYSTEM"
What's really going on is:
Backdrop -> PHP/MySQL -> Apache -> Linux
(the architecture is very similar for MAMP, XAMP, etc...)
Here's one way to understand how things are hooked together:
Run the following command:
$ sudo apachectl -M
Loaded Modules:
php7_module (shared)
Then look in:
/etc/apache2/mods-enabled
My installation lists the following:
php7.3.conf
php7.3.load
When Apache2 loads those php.* extensions, they look for an .ini file to figure out how PHP has been configured on the system.
My installation uses the following php.ini:
/etc/php/7.3/apache2/php.ini
The contents of that file, in turn, controls how PHP is configured.
The relevant section of php.ini looks like this:
;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;
; If you wish to have an extension loaded automatically, use the following
; syntax:
;
; extension=modulename
;
; For example:
;
; extension=mysqli
;
; When the extension library to load is not located in the default extension
; directory, You may specify an absolute path to the library file:
;
; extension=/path/to/extension/mysqli.so
;
; Note : The syntax used in previous PHP versions ('extension=<ext>.so' and
; 'extension='php_<ext>.dll') is supported for legacy reasons and may be
; deprecated in a future PHP major version. So, when it is possible, please
; move to the new ('extension=<ext>) syntax.
;
; Notes for Windows environments :
;
; - Many DLL files are located in the extensions/ (PHP 4) or ext/ (PHP 5+)
; extension folders as well as the separate PECL DLL download (PHP 5+).
; Be sure to appropriately set the extension_dir directive.
;
;extension=bz2
;extension=curl
;extension=fileinfo
;extension=gd2
;extension=gettext
;extension=gmp
;extension=intl
;extension=imap
;extension=interbase
;extension=ldap
;extension=mbstring
;extension=exif ; Must be after mbstring as it depends on it
;extension=mysqli
;extension=oci8_12c ; Use with Oracle Database 12c Instant Client
;extension=odbc
;extension=openssl
;extension=pdo_firebird
;extension=pdo_mysql
;extension=pdo_oci
;extension=pdo_odbc
;extension=pdo_pgsql
;extension=pdo_sqlite
;extension=pgsql
;extension=shmop
; The MIBS data available in the PHP distribution must be installed.
; See http://www.php.net/manual/en/snmp.installation.php
;extension=snmp
;extension=soap
;extension=sockets
;extension=sodium
;extension=sqlite3
;extension=tidy
;extension=xmlrpc
;extension=xsl
If you install an extension, you usually do so at the L layer of the LAMP stack using an Operating System level command line or GUI tool. You then typically use L layer tools (CLI or GUI) to adjust the configuration files at the A layer (and sometimes at the P layer).
You are not done yet. To improve performance, the designers of the LAMP stack wrote things so that (as much as possible) the LAMP stack is running in memory.
This is the "cache" that you need to restart, because (post-configuration changes) the in-memory instances of the LAMP stack are running on stale configuration information. They need to reload their configuration files.
To synchronize everything, you can
Restarting Apache2 is simple:
$ sudo service apache2 restart
When you restart the A layer, all of its dependent layers also restart (MPB).
If everything along the LAMPB cascade has been configured properly, your new PHP extension should reveal itself in Backdrop CMS.
There are some exceptions to this model (of course) but this is generally how things work. Exceptions include:
Finally, whenever you mess with modules in Backdrop CMS, you really should run update.php:
http://{www.mysite.com}/update.php
g.
----
It my case, Apache was restarted a few times without having no effect. Only clearing the cache helped.
No doubt.
The question is which cache needed to be reset.
Now that we have the vocabulary, we can talk about it more meaningfully.
There are several caches running on a well-stocked LAMPB server:
Was it the Backdrop CMS proprietary cache you needed to reset by:
Click the "CLEAR ALL CACHES" button
At:
admin/config/development/performance
g.
----
@alanmels,
Running update.php should reveal new functionality, whatever it is, given there are no pending Backdrop CMS updates to perform.
There is only instance of backdrop_flush_all_caches() in:
/core/update.php
As:
if (empty($count)) {
backdrop_set_message(t('No pending updates.'));
unset($form);
$form['links'] = array(
'#theme' => 'links',
'#links' => update_helpful_links(),
);
// No updates to run, so caches won't get flushed later. Clear them now.
backdrop_flush_all_caches();
}
else {
$form['help'] = array(
'#type' => 'help',
'#markup' => 'Updates have been found that need to be applied. You may review the updates below before executing them.',
'#weight' => -5,
);
if ($incompatible_count) {
$form['start']['#title'] = format_plural(
$count,
'1 pending update (@number_applied to be applied, @number_incompatible skipped)',
'@count pending updates (@number_applied to be applied, @number_incompatible skipped)',
array('@number_applied' => $count - $incompatible_count, '@number_incompatible' => $incompatible_count)
);
}
else {
$form['start']['#title'] = format_plural($count, '1 pending update', '@count pending updates');
}
$form['actions'] = array('#type' => 'actions');
$form['actions']['submit'] = array(
'#type' => 'submit',
'#value' => t('Apply pending updates'),
);
$form['actions']['cancel'] = array(
'#type' => 'link',
'#href' => '<front>',
'#title' => t('Cancel'),
);
}
return $form;
}
To me, it seems that update.php only clears cache if everything has already been done in good order to settle in Backdrop CMS updates, whatever they entailed, which is indicated by an empty issues $count:
if (empty($count)) {
Only then would you want to "refresh" the system's impression of itself via:
backdrop_flush_all_caches();
We almost never use UI working mostly on CLI, and running bee updb did not trigger anything, so the problem was gone after clearing cache.
Hello,
For anyone "coming from the future".
Issue resolved via clearing Backdrop CMS proprietary cache via the following BCMS specialized tool:
https://backdropcms.org/project/bee
Bee is a command line utility for Backdrop CMS. It includes commands that allow developers to interact with Backdrop sites, performing actions like:
See the Release notes and the Changelog for details of changes between versions.
g.
----
@alanmels,
bee updb
Does not contain any calls to clear cache, leading to this process (not logical or technical) error. You can see for yourself in:
bee/commands/update.bee.inc
@all,
When using bee, this Systems Administrator did not know that activating a module may sometimes require a step beyond (A) Installation; and (B) Database maintenance. In this case, a cache reset was also required to "bed in" the new functionality.
backdrop_flush_all_caches();
g.
----
Thanks for the follow-up @abqgman! That is a strange problem. I wonder, when you ran update.php were there updates that were needed for your system? Or did the updater tell you that no updates were necessary?
If the latter, then what Backdrop needed was to have it's caches cleared - as those are cleared automatically when visiting
update.php.