Not logged in. · Lost password · Register
Page:  1  2  3 ... 33  34  35  next 

All posts by schplurtz (515)

topic: Big media upload (Message from error.log)  in the forum: General Help and Support Server Setup
Avatar
schplurtz (Moderator) #1
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
Hi,

You can probably discard the PHP warning "should be compatible"... This is a well known warning and it is usually harmless. If you want to fix it however, see this post by Andreas Gohr himself: https://www.patreon.com/posts/declaration-be-20638123
 
Now, the error message "PHP message: PHP Warning:  Unknown: POST data can't be buffered; all data discarded in Unknown on line 0".

Well... data probably too big. Why is hard to say. I don't think you're hitting some sort of PHP or apache/nginx/lighty/whatever limit. This sounds like "Hey, I was trying to write the upload in a temporary file but some unexpected situation happent. I give up".
So I'd go for a disk problem. A "disk full" error or some other problem with the disk that prevents php from storing the temporary file. Note that the disk may not be /mnt/hd1 and could be your system disk. Check the value of upload_tmp_dir php.ini directive to find out which folder is used for temporary uploaded files. If it's empty, php will use some system defaults that most probably aren't anywhere under /mnt/hd1.
topic: Bureaucracy and debugging  in the forum: General Help and Support Features and Functionality
Avatar
schplurtz (Moderator) #2
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68787
That sorts out why bureaucracy is having problems, any ideas on getting debuggin to work?
whenever I need to debug my own little PHP  code, I use DW msg function. Say I need to check the content of $variable, I'll use this code :
msg('<pre>'.hsc(print_r($variable,true)).'</pre>');

Some may find this ugly, but it works well enough for me.
I have  absolutely no idea how to activate all the debugging things you try to turn on. Sorry.
topic: Bureaucracy and debugging  in the forum: General Help and Support Features and Functionality
Avatar
schplurtz (Moderator) #3
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68774
Hi,

[Sun Mar 15 15:09:00.592196 2020] [:error] [pid 31360] [client ::1:60242] PHP Parse error:  syntax error, unexpected 'class' (T_CLASS), expecting identifier (T_STRING) or variable (T_VARIABLE) or '{' or '$' in /var/www/html/dokuwiki/lib/plugins/bureaucracy/helper/actionscript.php on line 45, referer: http://localhost/dokuwiki/doku.php?id=playground:playground
Do you by any chance use a PHP older than 5.5 ? the ::class syntax appeared in 5.5.

I'm absolutely not sure I'm not suggesting something stupid here, but could you try to modify line 45 of /var/www/html/dokuwiki/lib/plugins/bureaucracy/helper/actionscript.php so it reads this :

if (!is_a($handler, 'dokuwiki\\plugin\\bureaucracy\\interfaces\\bureaucracy_handler_interface')) {
topic: export_html: ugly style, how to fix?  in the forum: General Help and Support General Stuff
Avatar
schplurtz (Moderator) #4
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68576
Hi,

The question is: why there's no styles for .export class in the default template?
Because this is precisely an export; with no special usage in mind. So no special treatment, no modification. Just the text part (that is designed to fit into the whole wiki). You want to see the export on screen directly, others may want to do something completely different with the export. With a special style, that would not be an export anymore. If you want a custom style, you have to write it yourself in a userstyle.css file; the export class is here to let you do that easily.

I tried to patch "dokuwiki\lib\tpl\dokuwiki\css\content.less" and clean the cache. I can see my rules in the summary css.php, but can't see them in the browser.
You will loose your modifications when you upgrade DW. The upgradeproof method is to create
a userstyle.css or userstyle.less file. You can use less css in both files.

Are there developers on this forum? There probably should be slight patches to Export.php and content.less focused on disabling the background and increasing paddings.
Yes there are. I'm not one of them so can't talk for them.  but your request would probably be denied because, a special style would make the export not be an export anymore; and it is easy to create a custom style. That said, feel free to open a bug report on https://github.com/splitbrain/dokuwiki, that's the preferred way to reach them.

Now I have padding, but can't get rid of the background, cause it's in <body>.
And it's even in <html>, so it's not possible to get rid of it without affecting the standard, non exported pages :-(
html {
    body {
        > div.dokuwiki.export {
            margin: 2em;
            padding: 2em;
        }
        background: unset;
    }
    background: unset;
}
topic: updated timezone = images all gone  in the forum: General Help and Support Installation and Configuration
Avatar
schplurtz (Moderator) #5
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68530
Good evening (in my timezone)

It's obviously something about the timezone change that is affecting how the wiki is pulling those images from their location.
Maybe not.
You manually edited a PHP file, local.protected.php. Make sure the file has no BOM, make sure the very first bytes of the file are "<?php".
See my answer and turnermm's answer and links in https://forum.dokuwiki.org/post/65023 and following post.
topic: Gestionnaire Multimédia - Upload image failed  in the forum: Non-English Discussion French discussion
Avatar
schplurtz (Moderator) #6
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68480
Est-ce que ceci pourrait aider ?

https://www.dokuwiki.org/fr:install:ovh.com
topic: Gestionnaire Multimédia - Upload image failed  in the forum: Non-English Discussion French discussion
Avatar
schplurtz (Moderator) #7
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68476
Bonsoir,

Est-ce que ça pourrait être un problème de limite de taille ? Par exemple, avec une image de 2 ko, est-ce que ça fonctionne ?
J'y crois pas trop, mais il faut bien commencer qq part.

Ton problème m'intrigue, alors je fouille un peu le web. peut-être qu'il va sortir un truc d'un moteur de recherche. Pour le moment, rien de concret avec OVH doku et échec d'envoi, mais on sait jamais...
topic: AuthAD and Authldap not working with SSL - Certificate trouble  in the forum: General Help and Support Installation and Configuration
Avatar
schplurtz (Moderator) #8
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68353
Hi,

TLS certificate verification: depth: 0, err: 20, subject: /CN=d.domain.d.d, issuer: /DC=d/DC=d/DC=domain/CN=Account //redacted
TLS certificate verification: Error, unable to get local issuer certificate
TLS trace: SSL3 alert write:fatal:unknown CA
the TLS implementation on your DokuWiki server does not trust the authority that signed the LDAP/AD certificate.

The solution is to add the root CA of the AD cert (or at least its issuer cert) to the list of trusted CA on the DouWiki server. I don't know how you do that.

Please note that certificates were also invented so that clients are sure they connect to the right server. The name embedded in the certificate CN and SAN fields must match the name of the server. This means :
the ad server must use a correct cert, otherwise DW won't be able to connect to it.
the dw HTTPS server must use a correct cert, otherwise browsers won't be able to connect, or will at least show a warning "This site is probably dangerous"
topic: Trouble with ACL  in the forum: General Help and Support Installation and Configuration
Avatar
schplurtz (Moderator) #9
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68325
Hi,

What's more, my in-wiki control panel disappeared
You probably changed the useacl setting. Near domains/THEWIKI/private_html/conf/acl.auth.php, there should be a file named local.php edit this file and make sure it contains this line :
$conf['useacl'] = 1;

This should restore both the control panel and the ability to set ACL.

Now a quick tour of ACL :
acl.auth.php is a list of (page,who, privileges) rules. For anyone visiting any page, the most page-specific rule and if more than one apply the one that gives the greatest privileges apply. You currently have this :
* @ALL 0 : * : Any page, @ALL : anyone, 0 : cannot read
* @user 8 : * : Any page, @user : logged in users, 8 : can write (mofify and create page)

Visitors who aren't logged in cannot read page. That is easy to test. Visit your wiki in a private navigation window. You should not be able to read any page.

I think you want one of these sets to start with.

* @ALL  1 : * : any page, @ALL : anyone, 1 : can read
Implicit : only you, the superuser, can modify

* @ALL  1 : * : any page, @ALL : anyone, 1 : can read
* @user 8 : * : any page, @user : logged in users, 8 : can create/modify/delete page


* @ALL       1
* @user      1
* @writers   8
* @trusted  16
+ the superuser has to make users members of the writers and trusted groups via the control panel,


rule 1 : * : any page, @ALL : anyone, 1 : can read
rule 2 : * : any page, @user : logged in users, 1 : can read
rule 3 : * : any page,
             @writers : logged in users who belong to the writers group,
             8 : can create/write/delete page but not media
rule 4 : * : any page,
         @trusted : logged in users who belong to the trusted group,
         16 : can modify anything and can upload and delete media


AMHA, the second set is not a good idea. Any user who just registers an account can spam your site. I'd start with 1)
You can disable user regitration in control panel. You could read this too : https://www.dokuwiki.org/faq:userapproval.
topic: uninstall apache and recover dokuwiki data  in the forum: General Help and Support Server Setup
Avatar
schplurtz (Moderator) #10
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68292
Hi,

Maybe you can find someone near you who is familiar with servers. I mean someone who could help you restore a recent backup of your server, if there is one.
If not, then :
  • First of all, locate your dokuwiki folder on the server and make a backup. double check to make sure you actually back up the correct folders. You should find .php files but also .txt files that are named after your page names. Put that backup on some external drive and check again the content.
  • Then try to reinstall apache. How you do this depends on the OS runnIng on the server. Please refer to your OS documentation, or maybe apache documentation.
  • When you're done, come back here. There will probably be someone to help you.
topic: Plugin PopUpViewer Plugin (Le Plugin Popup ne respect pas les ACL en page)  in the forum: Non-English Discussion French discussion
Avatar
schplurtz (Moderator) #11
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68221
Toujours bon à savoir.

Merci pour l'info
topic: Gestion habilitation  in the forum: Non-English Discussion French discussion
Avatar
schplurtz (Moderator) #12
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68191
Bonjour,
if ($_SERVER['REMOTE_USER']=='nom de l'administrateur')
Oui, des fois, "quick and dirty" c'est bien aussi !

Je n'ai pas bien compris tes problèmes de versions, mais au final tu
disposes de 2018-04-22 Greebo, qui est la dernière version et le greffon est
indiqué compatible avec cette version. Donc, tout va bien de côté là.

Quant à l'avertissement, il faudrait le signaler comme bug sur le github du greffon.
Tu peux le corriger facilement. Édite le fichier lib/plugins/disableactionsbygroup/action.php
et modifie la ligne
    public function register(Doku_Event_Handler &$controller) {
Il suffit d'enlever le «&» et tout rentrera dans l'ordre (normalement). Pareil pour la ligne
    public function handle_post_login(Doku_Event &$event, $param) {
si elle génère aussi un avertissement. => supprimer le «&».
topic: Gestion habilitation  in the forum: Non-English Discussion French discussion
Avatar
schplurtz (Moderator) #13
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68174
Bonjour,

Ce que tu cherches à faire nécessite forcément un greffon, reste à trouver le bon.

La page du greffon Denyactions indique qu'il existe un greffon similaire appelé disableactionsbygroup. S'il fonctionne comme c'est annoncé, et que tu peux l'utiliser, alors il devrait résoudre tes problèmes. Peut-être devras-tu ne conserver que ce greffon et te défaire de denyactions. Aucune idée.

Quant à l'affichage ou non de l'icône d'un outil dans l'interface en fonction du fait que l'action correspondante est autorisée ou non, ça me semble plus délicat. Si le thème que utilises ne réalise pas ces vérifications, je pense que tu n'auras d'autres choix que d'éditer le code du thème -- mais ça pose toujours le problème des mises à jour -- si tu as le temps et les compétences de programmation nécessaires, ou vivre avec le fait que pour certains outils, certains utilisateurs n'obtiendront pas ce qui leur est proposé.
topic: Problem with automatic emails  in the forum: General Help and Support Server Setup
Avatar
schplurtz (Moderator) #14
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68130
Quote by Zapo99:
Sent: MAIL FROM:<>
Got: 550 5.1.8 Sender address rejected

Indeed <> is a reserved email address. It should be instead your email address.
Did you set the mailfrom address in DW config as stated on https://www.dokuwiki.org/plugin:smtp ?
topic: Probleme tableau vide  in the forum: Non-English Discussion French discussion
Avatar
schplurtz (Moderator) #15
Member since Nov 2009 · 518 posts · Location: France, Finistère
Group memberships: Global Moderators, Members
Show profile · Link to this post
In reply to post ID 68081
bonjour,

C'est un bug du greffon wrap qui ne vérifie pas suffisamment la valeur des options de configuration avant de les utiliser. Il faudrait le rapporter sur https://github.com/selfthinker/dokuwiki_plugin_wrap/issues .

En jetant un coup d'œil rapide au code du greffon, je pense que soit la valeur de l'option de configuration noPrefix est vide soit elle est malformée.

administration => paramètre de configuration => Wrap => «Quelles classes (séparées par une virgule) ne devraient pas être préfixées d'un "wrap_" ?»
la valeur par défaut est :
tabs, group

Si la valeur est vide, et que tu l'avais volontairement vidée, essaie de mettre un truc improbable à la place comme "ne_pas_supprimer_cette_valeur" ou "schproutz". Rétablis la valeur par défaut si c'était non volontaire.
Close Smaller – Larger + Reply to this post:
Special characters:
Page:  1  2  3 ... 33  34  35  next 
Special queries
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2020-04-06, 05:10:54 (UTC +02:00)