Hi !
This morning, I had a blank page to my WordPress instance.
I don't have saw other issues about this.

In nginx error log :

2021/01/07 10:04:12 [error] 12228#12228: *38434 FastCGI sent in stderr: "PHP message: PHP Warning:  require_once(/var/www/wordpress/wp-config.php): failed to open stream: Permission denied in /var/www/wordpress/wp-load.php on line 37PHP message: PHP Fatal error:  require_once(): Failed opening required '/var/www/wordpress/wp-config.php' (include_path='.:/usr/share/php') in /var/www/wordpress/wp-load.php on line 37" while reading response header from upstream, client: <IP>, server: <subdomain>.<hostname>.fr, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.3-fpm-wordpress.sock:", host: "<subdomain>.<hostname>.fr"

perms for wp-config.php :

-rw------- 1 root root 3046 Dec 29 10:09 wp-config.php

Temporary fix :
I have changed file mode to 640 and group to the user of WordPress for wp-config.php file

Should I put this change in the install / upgrade script or isn't the source of the problem this?

Thanks !

Hello there,

When attempting to install Wordpress to the latest Yunohost-Unstable On Debian Buster, the installation fails with an error related to an incorrect integer value. It ran on a fresh install on a brand new VPS and on my main domain.

Here are the logs :

Yunohost Diagnostics
Wordpress Installation logs

I used the following curl/install link to setup my whole instance :
curl https://raw.githubusercontent.com/YunoHost/install_script/buster-unstable/install_yunohost | bash

During installation, if you answer "No" to "Is it a public website ?" question, your WordPress blog is only visible for YunoHost users.

Few days after installation, you got this message on WordPress panel:

L’évènement planifié wp_scheduled_delete a échoué. Votre site fonctionne toujours, mais cela pourrait indiquer que les publications planifiées ou les mises à jour automatiques ne fonctionnent pas comme elles le devraient.

The cron job installed on YunoHost server doesn't run correctly each night at 03:00 because website is not reachable without a YunoHost authentication:

# Reach everyday wp-cron.php?doing_wp_cron to trig the internal wordpress cron.
0 3  *  *  * root wget -q -O - https://domain.fr/blog/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Hello,

I have an error while I do the upgrade in line 143 et 203.

My upgrade log is available here : https://paste.yunohost.org/uyabajehaq.diff

Could be based on this current helper and inspired by this website.

During installation, if you answer "No" to "Is it a public website ?" question, your WordPress blog is only visible for YunoHost users.

Few days after installation, you got this message on WordPress panel:

L’évènement planifié wp_scheduled_delete a échoué. Votre site fonctionne toujours, mais cela pourrait indiquer que les publications planifiées ou les mises à jour automatiques ne fonctionnent pas comme elles le devraient.

The cron job installed on YunoHost server doesn't run correctly each night at 03:00 because website is not reachable without a YunoHost authentication:

# Reach everyday wp-cron.php?doing_wp_cron to trig the internal wordpress cron.
0 3  *  *  * root wget -q -O - https://domain.fr/blog/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Hi,

Got this error while trying to install phpmyadmin from the master or testing branch.
`Error: This url is not available or conflicts with the already installed app(s):

• sante0naturel.bio/ → La sante Oh! naturelle (wordpress)`

The completed terminal output is:
`root@srv-web-idlas:/usr/lib/moulinette/yunohost# yunohost app install https://github.com/YunoHost-Apps/phpmyadmin_ynh.git
WARNING! Installing 3rd party applications may compromise the integrity and security of your system. You should probably NOT install it unless you know what you are doing. Are you willing to take that risk? [Y/N] : Y
Available domains:

• sante0naturel.bio
  Choose a domain for phpMyAdmin (default: sante0naturel.bio):
  Choose a path for phpMyAdmin (default: /phpmyadmin):
  Available users:
• phlip
  Choose the only allowed admin user: phlip
  Error: This url is not available or conflicts with the already installed app(s):

• sante0naturel.bio/ → La sante Oh! naturelle (wordpress)
  root@srv-web-idlas:/usr/lib/moulinette/yunohost# `

Thanks for your support, help, advices, comments.

This issue is related to that one, but also contain specificity from the wordpress app setup I think.
I noticed that any user of yunohost can not only login in wordpress but is also automatically an administrator of the root/main page. I would expect only the wordpress administrator to automatically administer the root page.

There is a workaround, but it's kind of time consuming: when you add a new yunohost user, you must login as this user into wordpress, which will automatically generate this user in wordpress and add it to the admins of the root page, and then you remove administration rights.

Testing wordpress_ynh on a buster install (cf YunoHost/issues#1255 )

I can't install wordpress and get the following : https://paste.yunohost.org/raw/unoreregew

possible problem :

[snip]
2020-02-24 15:04:02,061: WARNING - ERROR 1366 (22007) at line 1: Incorrect integer value: '' for column `wordpress`.`wp_options`.`option_id` at row 1
[snip]
2020-02-24 15:04:02,779: ERROR - Could not install wordpress: An error occurred inside the app installation script
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/moulinette/interfaces/api.py", line 333, in wrapper
    curr_v = params[k]
KeyError: 'label'

cc @alexAubin who is working on the buster branches for yunohost.

Bonjour,

Wordpress recommande d'utiliser au moins la version 7.4 de php. Ci-dessous l'explication fournie par Wordpress:

PHP est le langage de programmation utilisé pour construire et maintenir WordPress. Les nouvelles versions de PHP sont plus rapides et plus sécurisées, de sorte que rester à jour aidera les performances globales et la sécurité de votre site. La version minimale recommandée de PHP est 7.4.

Bon courage!

Received following error while installing the wordpress in yunohost in a cloud server.

Action
POST /apps
{"locale":"en","app":"wordpress","args":"domain=subdomain.testdomain.com&path=%2Ftestdomain&admin=testadmin&language=en_US&is_public=1&multisite=0","label":"testdomain"}
Traceback
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/moulinette/interfaces/api.py", line 406, in process
ret = self.actionsmap.process(arguments, timeout=30, route=_route)
File "/usr/lib/python2.7/dist-packages/moulinette/actionsmap.py", line 498, in process
return func(**arguments)
File "/usr/lib/moulinette/yunohost/app.py", line 794, in app_install
app_ssowatconf(auth)
File "/usr/lib/moulinette/yunohost/app.py", line 1272, in app_ssowatconf
users[username] = app_map(user=username)
File "/usr/lib/moulinette/yunohost/app.py", line 420, in app_map
result[domain + path] = app_settings['label']
TypeError: cannot concatenate 'str' and 'NoneType' objects

Any clue on the cause for a resolution.

After entering site address, username, and passwork, in the Android app, I receive the helpful error: "Error while adding site. Error code: GENERIC_ERROR". Not sure what the source of the error could be, but I wonder if there is a default setting in the server configuration if that might prohibit Wordpress's Android app from connecting.

In debug mod I have this error message

Undefined variable: version in /var/www/wordpress/wp-content/plugins/simple-ldap-login/Simple-LDAP-Login.php on line 54

But WordPress is running normally

https://wordpress.org/latest.tar.gz

Hi
As Wordpress can not be installed on the Yunohost main domian (in most cases it would be domain.tld), the ideal condition would be to install Wordpress on the subdomain (that would be www.domian.tld in most of the cases).
But installing on the subdomain raises a condition where the domian.tld should redirect to www.domian.tld excluding the links to domian.tld/yunohost/sso and for the app installed on the main domian for eg. domain.tld/webmail would be liking to roundcube.
This require changes in the nginx to work properly.
Can you please provide me with an example for the nginx config files so that domain.tld should redirect to www.domain.tld(assuming wordpress is installed on the www.domain.tld) and on particular unique links like domian.tld/yunohost/sso and domain.tld/webapp could be redirected to the Yunohost login and the apps.
It would also helpful if the www.domain.tld/yunohost/sso could redirect to domian.tld/yunohost/sso.
Thats a lot of configuration to do ,but it would be helpful if someone can give an example of the workaround.
Thanks in advance :)

In php-fpm.conf for this application memory_limit is fixed at 30M but somes plugin like nexttgen-gellery requiert more (32M for it) else if wont be run.

Please update php-fpm.conf to increase the value of memory_limit.

Hi

Following that announce, https://forum.yunohost.org/t/about-the-end-of-official-apps-in-yunohost/10530, this app won't be official anymore.
This app currently has the tag high_quality as a former official app. As this status will be dropped, to keep this tag, the maintainer of this app has to officially ask for the tag.
To do so, please follow those instructions.

In order to improve security, it would be nice to limit access to http://domain.com/blog/wp-login.php only to YunoHost users logged through portal.

Hello,

While trying to use the plugin Wordpress ActivityPub, I'm in trouble with the redirection to .well-known and nginx config. See Automattic/wordpress-activitypub#37

My wordpress is in a subfolder (let's call it subdirectory). So I tried to add rewrite ^/.well-known/ ^/subdirectory/.well-known/ last; in /etc/nginx/conf.d/domain.tld.conf.

A webfinger test (https://client.webfinger.net/lookup?) show me that it returns a text/html file. I'm pretty sure it's yunohost SSO page.

Should I exclude it from SSO ? How can I do that ?

Previously, my WordPress installation was on a shared host. When I started my YunoHost server, I installed wordpress_ynh and then copied the database over from my shared host. This included copying my user table.

Because wordpress_ynh includes a single sign-on (SSO) plugin, every time I update wordpress_ynh via the YunoHost admin panel, it re-establishes my YunoHost user as the user for WordPress. But this doesn't match my users table, and even if it did, I don't want to use that account anyway. I have an established user on my WordPress installation that predates my YunoHost server. I don't want to create a new user account on WordPress.

Additionally, because of this user issue, whenever I update wordpress_ynh via the YunoHost admin panel, I am locked out of my admin panel until I SSH into my server and delete/rename the SSO plugin.

I know how to disable and uninstall plugins from within WordPress, but every time I update wordpress_ynh via YunoHost, the SSO plugin is reinstalled and re-enabled. How can I stop this behavior? I have no need for SSO.

Thank you.

Hello,
I tried to update wordpress from the cli and it failed. The backup could not be restore after this first failure.
Then I tried a few things and manage to restore the pre-update-bakcup.
But I had a 502 Bad Gateway error.
I solved the error changing a line in :
/etc/php/7.0/fpm/pool.d/wordpress__2.conf
From :
listen = /var/run/php5-fpm-wordpress__2.sock
To :
listen = /run/php/php7.0-fpm-wordpress__2.sock

So my problem seems to be solved. But I think this should be handled by the install, update, restore scripts.

My server is a kimsufi VPS. I was running this version before trying to update apps.

yunohost:  
    repo: stable  
    version: 3.1.0
yunohost-admin:  
    repo: stable  
    version: 3.1.0
moulinette:  
    repo: stable  
    version: 3.1.0
ssowat:  
    repo: stable  
    version: 3.1.0

Last week my WordPress was running fine, but now I have this message: Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 7.2.0". You are running 7.0.33[…]
I did not make any upgrade, and I don't think I received a message about any automatic update.

How can I solve this issue ? Will Yunohost package switch to another php version ?

edit: upgrade fails too because of that error

When you installed Wordpress 5.4, Site Health status report a possible improvement:

Warning The optional module, imagick, is not installed, or has been disabled.

It seems that php7.0-imagick is not installed as a WordPress dependency.

As explain here we should improve the security of wordpress_ynh specifically.
https://forum.yunohost.org/t/virus-qui-envoie-des-mails-en-masse-spam/3330/5?u=ljf

I suggest to add a owner iptable rules to avoid the user $app to be able to open a port outside. If we don't, a wordpress could send mass mail (like with the perl virus discovered on tomdereub instance).

Hello,

TL;DR: we need to keep upgrade process before #119 with a better explanation to users on how to proceed.

I'm using 5.6~ynh1. I recently upgraded to this version and noticed behavior described on the forum by @maniackcrudelis:

If you upgrade your YunoHost Wordpress app from 5.4 to 5.6, you need to manually upgrade WordPress to 5.6 using WordPress web admin. Otherwise, minor upgrades are covered by Companion Update plugin installed with WordPress by YunoHost packaging.

This behavior was not really documented here except by a comment in README.md (Limitations section) (see #58).

I'm using YunoHost app since 1 year and I didn't notice any issue with Companion Update plugin so I'm not sure assessment on instability of plugin is still true. Perhaps @Thatoo and @maniackcrudelis have an opinion on this topic.

On the other side, I noticed changes introduced by #119. If I understand correctly, it means that now new installations and current installation that upgrade to 5.6~ynh2 will have automatic upgrades of WordPress core for major versions.

At first glance, I find this config too agressive. It means that if WordPress release a 5.7, 5.6~ynh2 installation will automatically upgrade to 5.7. I see several drawbacks:

• You have a YunoHost package version that didn't match your WordPress version
• If 5.7 comes with specific dependencies, there will be not installed by automatic upgrade
• A major release could change several things that need to be handle by packaging

So I suggest we keep previous behavior:

• minor upgrades are done automatically by Companion Update plugin
• major upgrades need to be done in two steps:
  1. Yunohost package
  2. WordPress web admin

and add notes in README.md

Hey hello,
Thanks for the great package, everything has always been working fairly good so far, but recently a bug came up, that wasn't present before, don't know when it appeared exactly, in a recent update I guess, or maybe I'm doing something wrong but I can't really find what.

I'm using worpdress in "multisite" mode. Wordpress is installed at mydomain.tld/wp.
The problem is that, after logging in successfully the wp-admin/ (or wp-admin/index.php) page returns a "502 bad gateway" response.

Two things to specify:

• The problem doesn't occur for the root site: mydomain.tld/wp/wp-admin/ opens properly, but every other sites admin panel (mydomain/wp/somesite/wp-admin/) respond with "502 bad gateway".
• The 502 response seems to occur only when opening mydomain/wp/somesite/wp-admin/ or mydomain/wp/somesite/wp-admin/index.php, I managed to access other parts of the admin panel opening: mydomain/wp/somesite/wp-admin/edit.php for example.

The bug occurs both for the wordpress admin user, and with sites admin users.

About wordpress and yunohost. I'm using the last versions, just updated the server. So wordpress 5.7~ynh1. But the problem was also present in 5.6 before upgrading.

If there's anything I'm doing wrong, please tell me. Otherwise I hope the bug report is useful :)

I installed several wordpress for three weeks, and the fr_FR option still install a wordpress with english activated by default. I was btw on three different fresh yunohost instances. Actually not really problematic as it isvery easy to change in wp-admin.

Hi there,

wordpress_ynh is the official app name and can be really confusing.
Actually, it can even cause havoc if yunohost makes an update to the official app and people have this one installed.

Would it be possible for you to create wordpressms_ynh ?

In place of cp -a , the backup script should use ynh_backup.

Bonjour,

J'essaye d'installer wordpress sur raspberry pi.
L'installation échoue par l'interface d'administration. Du coup, j'ai essayé en ligne de commande:
yunohost app install https://github.com/YunoHost-Apps/wordpress_ynh
j'ai l'erreur suivante:
ERROR 1146 (42S02) at line 1: Table 'wordpress.wp_options' doesn't exist
Après quelques recherches il semble que ce soit un problème de base de données ou de permission sur la base de données. Avez vous une idée sur la façon de résoudre ce problème?

Hey hello, thanks for the nice wordpress_ynh package :)

I'm stumbling upon some issue but didn't find any related issues.
I'm trying to create a wordpress instance with multisite support that would allow different sites to be served at for example:
(a1) mywpdomain.tld <= let's say this would be the main domain, where wordpress administration interface is served
(a2) sub.mywpdomain.tld
(a3) myfriendswordpressPage.tld
...

It seems that at the moment none of the previous three setup are possible, in multisite situation, every sites would have to be for example:
(b1) mydomain.tld/wordpress/mySite
(b2) mydomain.tld/wordpress/sub
(b3) mydomain.tld/wordpress/myFriendsSite
...

From what I know, at least the (a1) and (a2) or* (b) options are supported by wordpress multisite installation (if not using wordpress_ynh). I'm not so sure about (a3).
Is there a possibility to achieve at least (a1) and (a2) and maybe (a3) with wordpress_ynh app?

Thanks a lot :)

*you chose it when installing wordpress

The first time I ran yunohost install wordpress the LDAP integration worked fine.

Unfortunately, it did not work after runnning yunohost remove wordpress and then again yunohost install wordpress.

Only the assigned admin had an account but other users registered in LDAP were not.

Strange things are observed, sirs.

When Log in is clicked it sends user to Ynh portal @ <yunohost/sso/> instead of Wp admin.

The server was reinstantiated from system snapshot with external utilities. Though no other features were impacted. And no evidence that there is a connection with this one.

Did someone experienced this type of bug, or can I provide something to debug it?

Hi,
I have the folliwing issue:
I have to change a wordpress url, so I went to the application menu and clicked on the button "Change URL" it fails, ad it seems to be because of it's database's table prefix, that is not the standard wp_, as you can see in this log error message:
WARNING - ERROR 1146 (42S02) at line 1: Table 'wordpress__4.wp_options' doesn't exist

(Partial) Logs below:

2019-06-12 14:58:31,662: DEBUG - + VALUE=02205bfbc6b08e8bd8c46c769ad6361f
2019-06-12 14:58:31,662: DEBUG - + python -
2019-06-12 14:58:31,964: DEBUG - + '[' -n '' ']'
2019-06-12 14:58:31,964: DEBUG - + unset backup_file_checksum
2019-06-12 14:58:31,965: DEBUG - + ynh_mysql_execute_as_root 'UPDATE wp_options SET option_value='\''old.voyag.earth/'\'' WHERE option_name='\''siteurl'\''' wordpress__4
2019-06-12 14:58:31,965: DEBUG - + local legacy_args=sd
2019-06-12 14:58:31,965: DEBUG - + args_array=([s]=sql= [d]=database=)
2019-06-12 14:58:31,966: DEBUG - + declare -Ar args_array
2019-06-12 14:58:31,966: DEBUG - + local sql
2019-06-12 14:58:31,966: DEBUG - + local database
2019-06-12 14:58:31,967: DEBUG - + ynh_handle_getopts_args 'UPDATE wp_options SET option_value='\''old.voyag.earth/'\'' WHERE option_name='\''siteurl'\''' wordpress__4
2019-06-12 14:58:31,967: DEBUG - + set +x
2019-06-12 14:58:31,967: DEBUG - + echo '! Helper used in legacy mode !'
2019-06-12 14:58:31,968: DEBUG - + set +x
2019-06-12 14:58:31,968: DEBUG - + database=wordpress__4
2019-06-12 14:58:31,968: DEBUG - ++ sudo cat /etc/yunohost/mysql
2019-06-12 14:58:31,969: DEBUG - + ynh_mysql_connect_as --user=root --password=notreallytheoneiuse--database=wordpress__4
2019-06-12 14:58:31,969: DEBUG - + local legacy_args=upd
2019-06-12 14:58:31,969: DEBUG - + args_array=([u]=user= [p]=password= [d]=database=)
2019-06-12 14:58:31,970: DEBUG - + declare -Ar args_array
2019-06-12 14:58:31,970: DEBUG - + local user
2019-06-12 14:58:31,970: DEBUG - + local password
2019-06-12 14:58:31,971: DEBUG - + local database
2019-06-12 14:58:31,971: DEBUG - + ynh_handle_getopts_args --user=root --password=notreallytheoneiuse--database=wordpress__4
2019-06-12 14:58:31,971: DEBUG - + set +x
2019-06-12 14:58:31,972: DEBUG - + database=wordpress__4
2019-06-12 14:58:31,972: DEBUG - + mysql -u root --password=***********-B wordpress__4
2019-06-12 14:58:32,173: DEBUG - + ynh_exit_properly
2019-06-12 14:58:32,174: WARNING - ERROR 1146 (42S02) at line 1: Table 'wordpress__4.wp_options' doesn't exist
2019-06-12 14:58:32,175: DEBUG - + local exit_code=1
2019-06-12 14:58:32,175: WARNING - !!
2019-06-12 14:58:32,175: DEBUG - + '[' 1 -eq 0 ']'
2019-06-12 14:58:32,176: WARNING -   wordpress__4's script has encountered an error. Its execution was cancelled.
2019-06-12 14:58:32,176: DEBUG - + trap '' EXIT
2019-06-12 14:58:32,177: WARNING - !!
2019-06-12 14:58:32,178: DEBUG - + set +eu
2019-06-12 14:58:32,178: WARNING - 
2019-06-12 14:58:32,179: DEBUG - + echo -e '!!\n  wordpress__4'\''s script has encountered an error. Its execution was cancelled.\n!!'
2019-06-12 14:58:32,179: DEBUG - + type -t ynh_clean_setup
2019-06-12 14:58:32,180: DEBUG - + ynh_die
2019-06-12 14:58:32,180: DEBUG - + local legacy_args=mc
2019-06-12 14:58:32,180: DEBUG - + args_array=([m]=message= [c]=ret_code=)
2019-06-12 14:58:32,181: DEBUG - + declare -Ar args_array
2019-06-12 14:58:32,181: DEBUG - + local message
2019-06-12 14:58:32,181: DEBUG - + local ret_code
2019-06-12 14:58:32,182: DEBUG - + ynh_handle_getopts_args
2019-06-12 14:58:32,182: DEBUG - + set +x
2019-06-12 14:58:32,182: DEBUG - + echo ''
2019-06-12 14:58:32,183: DEBUG - + exit 1
2019-06-12 14:58:32,334: ERROR - Failed to change 'wordpress__4' url.

First, I like to thank all contributors and maintainers for their work. 😊

After changing the domain associated with WordPress through the admin panel, many paths of the WordPress instance were broken.

I thought switching back to the old one, would fix this again. Sadly it was still broken.

I think the issue was that the links were not properly changed and ended up looking like this:

example.com/example.com/wordpress

Some string appending seemed to been going wrong. 😢

This might also help to reproduce the error:
I changed the domain in the following order:
foo.org -> www.foo.org -> foo.org

INSTALL SCRIPT
✘ At line 42 'ynh_die' or 'exit' command is executed with system modification before.
Aucune modification avant.
✘ set -eu is missing at beginning of file.
Remplacé par ynh_abort_if_errors

REMOVE SCRIPT
✘ set -u is missing at beginning of file.
Usage de SECURE_REMOVE

UPGRADE SCRIPT
✘ set -eu is missing at beginning of file.
Remplacé par ynh_abort_if_errors

BACKUP SCRIPT
✘ set -eu is missing at beginning of file.
Il est bien présent au début du script !

RESTORE SCRIPT
✘ At line 53 'ynh_die' or 'exit' command is executed with system modification before.
Aucune modification avant.
✘ set -eu is missing at beginning of file.
Il est bien présent au début du script !

.FONCTIONS SCRIPT
✘ Line 79 you should add "sudo" before this command line: ***
rm -r $temp_dir
sudo n'est pas nécessaire. Et c'est mieux sans !
✘ Line 244/332/333: 'exit' command shouldn't be used. Use 'ynh_die' helper instead.
Variable exit_code
✘ Line 331/357: 'exit' command shouldn't be used. Use 'ynh_die' helper instead.
Fonction ynh_exit_properly
✘ Line 334: 'exit' command shouldn't be used. Use 'ynh_die' helper instead.
exit 0, ce n'est pas un exit sur une erreur.

Hi
The mails send to user from wordpress don't have the DKIM signatures, because of which there is delivery problem for the mails.
The rmilter should not sign the mail by default?
If not, then how can I edit the wp-mail.php so that it signs the mails?

Thanks

links: https://github.com/louisameline/php-mail-signature

step to reproduce :

• on a fresh yunohost with you own domain (i.e. domain: https://domain.tld)
• install wordpress, at the following url https://domain.tld/blog
• in the wordpress database, wp_option table, you have both siteurl and home = "https://domain.tld/blog"
• in the admin gui, change the wordpress path to https://domain.tld/www
• open the address https://domain.tld/www

current result :

• in the wordpress database, wp_option table, you have both siteurl and home = "domain.tld/www" this causes an error 404 (on wordpress)

expected result :

• the wordpress is correctly displayed (no 404)
• in the wordpress database, wp_option table, you have both siteurl and home = "https://domain.tld/www"

hi,
my last update was yesterday without any trouble,
but today, the update removed my 2 wordpress and i needed to restart php-fpm ...
restoration failed (via webadmin)

root@krashboyz:/home/isaaac# yunohost -v
yunohost: 
  repo: stable
  version: 3.4.2.4
yunohost-admin: 
  repo: stable
  version: 3.4.2
moulinette: 
  repo: stable
  version: 3.4.2
ssowat: 
  repo: stable
  version: 3.4.2

failed update logs :
https://paste.yunohost.org/raw/basobekopo

failed restoration logs : https://paste.yunohost.org/raw/asametozaw

help needed to restore the 2 wordpress for my users,
thx

I try to login with my user credentials via wp-admin and they are invalid.
Can you advise please?

Hello,
i tried to fix some right trouble on my multiste instance this night,
i based myself on a single site instance i have on the same server, but now, i have this issue :

2019/11/29 03:32:53 [error] 23041#23041: *54620 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 88.121.55.144, server: port.krashboyz.org, request: "GET /blog/ HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.0-fpm-wordpress__2.sock:", host: "port.krashboyz.org", referrer: "https://krashboyz.org/yunohost/sso/portal.html"

i think something is not good with my rights fix,
site multisite was working before my "fix" :/

could someone help me please ?

thx a lot

The entire log is here https://paste.yunohost.org/raw/ocafitoceq

With the latest commit, I am not able anymore to install the module. It is stucked right away after the SSOwat generation and the little black "pacman" of the installation keeps going and never disappear.

I do not have any other information because everything went good until that.

Hello,
Wordpress indicates in the "site health" menu that PHP requires an upgrade.
Can it be upgraded without breaking Yunohost?
Yunohost version : 3.7.1.1 FR
Wordpress version : 5.4 FR
Thank's a lot
Have a nice day
Laurent

Yunohost users don't know that wordpress is very risky because it's the number one solution for creating website.

I suggest to add a special warrant for this app to explain, this app and its plugins and themes should be really maintained up to date.

I don't know if the issue is related to the wordpress app specifically or to yunohost in general, since I have similar issues with other apps (or maybe they are different, but anyway). The issue is that if I'm logged in wordpress and click logout in the wordpress interface, I'm redirected to the sso login page, but if I open the administration url again, I'm still logged in.

My setup is wordpress single site with url: wp.domain.tld, and main yunohost domain is ynh.domain.tld.

Hi,
Backup failed on my server :

admin@lamo:/$ sudo yunohost backup create --apps wordpress -n test --method myborg --debug
[...]
2268 DEBUG + ynh_backup /etc/fail2ban/jail.d/wordpress.conf
2268 DEBUG + local SRC_PATH=/etc/fail2ban/jail.d/wordpress.conf
2268 DEBUG + local DEST_PATH=
2268 DEBUG + local IS_BIG=0
2268 DEBUG + BACKUP_CORE_ONLY=0
2268 DEBUG + '[' 0 == 1 ']'
2269 DEBUG + [[ -e /etc/fail2ban/jail.d/wordpress.conf ]]
2302 DEBUG + echo 'Source path '\''/etc/fail2ban/jail.d/wordpress.conf'\'' does not exist'
2302 DEBUG + return 1
2303 DEBUG + ynh_exit_properly
2302 WARNING Source path '/etc/fail2ban/jail.d/wordpress.conf' does not exist
2303 DEBUG + local exit_code=1
2304 DEBUG + '[' 1 -eq 0 ']'
2304 WARNING !!
2304 DEBUG + trap '' EXIT
2304 WARNING   wordpress's script has encountered an error. Its execution was cancelled.
2304 DEBUG + set +eu
2305 WARNING !!
2305 DEBUG + echo -e '!!\n  wordpress'\''s script has encountered an error. Its execution was cancelled.\n!!'
2305 WARNING
2305 DEBUG + type -t ynh_clean_setup
2305 DEBUG + ynh_die
2306 DEBUG + echo ''
2306 DEBUG + exit 1
2360 ERROR Impossible de sauvegarder l'application « wordpress »
Traceback (most recent call last):
  File "/usr/lib/moulinette/yunohost/backup.py", line 682, in _collect_app_files
    raise_on_error=True, chdir=tmp_app_bkp_dir, env=env_dict, user="root")
  File "/usr/lib/moulinette/yunohost/hook.py", line 381, in hook_exec
    errno.EIO, m18n.n('hook_exec_failed', path=path))
MoulinetteError: [Errno 5] Échec de l’exécution du script « /tmp/backup_jkMKrA »
2408 DEBUG action [686.1] executed in 2.184s
2408 DEBUG lock has been released
2409 ERROR Il n'y a rien à sauvegarder

I'm on yunohost 3, x64.

As explain here we should improve the security of wordpress_ynh specifically.
https://forum.yunohost.org/t/virus-qui-envoie-des-mails-en-masse-spam/3330/5?u=ljf

I suggest to chroot all the environment of wordpress. Like that it will be more difficult to succeed in priviledge escalation