Well I did not find all dependencies in rh-php, maybe a test on real wordpress would be nice, for example does wordpress can send email when a comment is made
php-simplepie.noarch : Simple RSS Library in PHP
php-getid3.noarch : The PHP media file parser
php-fedora-autoloader.noarch : Fedora Autoloader
php-PHPMailer.noarch : PHP email transport class with a lot of features
php-IDNA_Convert.noarch : Provides conversion of internationalized strings to UTF8
these dependencies are needed by the wordpress rpm of epel
thinking on the future of wordpress, the version of epel will stick on the version 5.1.1 I think, the requirement now of wordpress is php56, maybe it is time to start our folk of wordpress
I can build my version, what I hope is to let the wordpress auto update feature workable.
you will install wordpress 5.2.3, you can autoupdate with the internal wordpress update manager, still don’t know what is the best, release each month a new version or let the sysadmin auto update his web application
I just installed this latest itteration in a VM, It installs great.
IMO it would be preferable if an in-application update can be conducted, even though it is (very) different from the normal NethServer way.
Ok, now I produced two rpms to obsolete wordpress and replace it by the fork wordpress-AutoUpdater with rh-php72
the advantages
We could update wordpress by the internal updater
We are not stick anymore on the version 5.1 due to the centos7 php version limitation
Because we have obsoleted wordpress, even a new version cannot breaks my update
uhm… am I missing something? You say to remove wordpress-AutoUpdater: yum remove wordpress-AutoUpdater
gives me this:
[root@ns7 ~]# yum remove wordpress-AutoUpdater
Loaded plugins: changelog, fastestmirror, nethserver_events
No Match for argument: wordpress-AutoUpdater
No Packages marked for removal
Anyway, I reverted to an earlier state and now installed this latest itteration… testing as we speak
wordpress-AutoUpdater is what I would like to test, I think if you upgrade an existing installation, we do not modify files nor mysql databse, so we could downgrade if you want to go back with wordpress 5.1.1. However the wordpress-AutoUpdater will conflict with worpdress because they use the same path to files, so you must remove it manually then downgrade to the nethserver-wordpress of my repository
so in short after tested the new wordpress-AutoUpdater, if you want to downgrade
thanks for the reminder, I still have to find the best approach to maintain two versions of wordpress, indeed I am worry to release a force pushed update to leave the epel version…
keep two branches in my git repository
keep one branch, but build two rpms like we do for nethserver-mail
go to two git repositories
the coding season is coming in my country, I think I could find time