Edison

Hi @opalepatrick, your can load your module anywhere and then call one of its methods: $myModule = $modules->get('MyGreatModule'); $myModule->greatRender(); //call whatever method of the module It's probably helpful to have a look at $modules API to get more details. Also this forum post could be useful:

Hi @teppo, yes you are right. I should have mentioned in my case the user owner is not the same as the Apache user. ?

Hi @Neo, I have the same permissions 755-644 in PW config. I think I encountered this problem when I initially set them. It was depending from Apache process's owner. Please create a simple php file in the root including the following and run it from the browser: <?php echo `whoami`; If it returns "apache" or "www-data" it should not be possible to use restricted permissions. You need to get your web user name (your website name) to support them. If you get the first output, it is possible to solve it using php-fpm and creating separated pools. Just le me know if you want to go for that, I can describe all the steps.

Ciao @dragan, unfortunately I cannot test it right now . The message suggests an issue with the spreadsheet columns or in the way columns are addressed. What is curious is the spreadsheet tables range (Tabellenblatt1!A1:A2) as Ryan's example does not directly defines a range. Going inside GoogleSheets.php, the function setRows() is defining the range: public function setRows($fromRowNum, array $rows, array $options = array()) { $fromRowNum = (int) $fromRowNum; $numRows = count($rows); if(!$numRows) return false; $toRowNum = $fromRowNum + ($numRows - 1); $range = $this->rangeStr("A$fromRowNum:A$toRowNum"); return $this->setCells($range, $rows, $options); } Franky I do not understand why the function is fixing the range within column "A" only (A1:A2). It sounds to me strange also the second column of the range is hardwired to "A" ... but probably is due to the fact each row is managed like an array of columns starting with column "A" ... ?... need to study the code deeper. By the way, googling around I found the following links https://stackoverflow.com/questions/46350876/error-trying-to-write-a-row-in-google-sheets-using-api-v4 this case the same error (very similar) is reported and the issue seems to come from spreadsheet addressing notation https://help.formstack.com/hc/en-us/articles/360019521651-Google-Sheets-Commonly-Returned-Errors this one is a bit more generic and not sure it is the case. I hope you may find some hints with them.

Hi @Neo, I gave a quick view to your virtual host conf file and it seems ok. However I see you are using SSL and virtual host:80 automatically rewrites to https. I guess you just did not mention, but just to double check... do you have a second virtual host for https? I have a second virtual host:443, which, if I well recall was created by Letsencrypt with a name similar to example.com-le-ssl.conf, and that also needs to be enabled. You may wish to have a look at apache error.log/access.log as this could help to identify what is the cause of the problem. Last question, is PW installed in the root directory (likely ?) or in a subdirectory?

Hi @Kai2000, I think you can find this guide very helpful: https://processwire.com/docs/modules/guides/comments/ in particular in the section "Generating your own output": foreach($page->comments as $comment) { if($comment->status < 1) continue; // skip unapproved or spam comments $cite = htmlentities($comment->cite); // make sure output is entity encoded $text = htmlentities($comment->text); $date = date('m/d/y g:ia', $comment->created); // format the date echo "<p><strong>Posted by $cite on $date</strong><br />$text</p>"; } EDIT: I realized you were looking to the comment FORM markup, not the comments markup. ? As a first step, if you use Uikt 3 Site/Block Template you can look at file _uikit.php in site/templates directory, and look at function ukCommentForm(). This function calls $comments->renderForm($options) with a set of $options. You can find details about these options in wire/modules/FieldtypeComments file CommentForm.php. What you can do is to see if you can shape out your form using these options. In case providing $options is not sufficient you can consider to modify CommentForm.php to setup your custom form. However do not modify the original one, you can duplicate FieldtypeComments module under site/modules. Suggest to refer to this tutorials about duplicating the module and modify the comment form:

Hi @Clément Lambelet, I am glad you solved! Thank you for sharing the cause of the problem! Wish you a nice day

Interesting decision from EU Court today about Facebook "Like" button. ? Details in these articles: https://www.reuters.com/article/us-eu-facebook-dataprotection/companies-using-facebook-like-button-liable-for-data-eu-court-idUSKCN1UO1B4 https://www.dw.com/en/like-button-needs-caveat-european-court-of-justice-rules/a-49785019 https://www.zdnet.com/article/eu-court-of-justice-ruling-may-spell-the-death-of-social-like-share-buttons/ If any doubts ... GDPR consent needed... ?or ... button removed ? Welcome to EEC's magic world ! ?

Hi @Clément Lambelet I rarely had issues with the admin theme. When it happened it was depending from javascript, conflicts/errors at ajax level, but there were errors in the console. May be it could help if you may recall which modifications you introduced before experiencing the issue ! ? I do not know if it can help and hope not to mislead you! By chance were you doing any modifications to your front end css file such that it could have affected also the admin theme, like changing ui-menu colors ? Below a snapshot of the elements and css colors of the user pop-down menu (first menu item is named debug, add new, etc..). I reproduced what you see by setting css for .ui-menu .ui-menu-item a {color: white} If cause is due to css and you experience the issue after reinstalling PW, can be the css file is still cached in your browser. In Chrome shift+View+Force_Reload_This_Page will also reload css files. If this is not the case it would be interesting you inspect the first menu item of the user pop-down menu, it is named debug and should look as follows: If "Debug" name of menu item does not appear we have to think to something else.

Yeah, on the net there are several references to the application of "legitimate interest" as described in article 6.f, which of course in certain cases it makes great sense. For example apache log files are tracking ip addresses and can be properly used to protect from attacks provided their storage is limited in time. Sometimes on the web the "legitimate interest" is presented as a sort of preferred way, because of course it greatly simplifies, however, to my personal point of view, there are some drawbacks to consider. In certain cases appealing to article 6.f may sound quite weak from a legal stand point. The part of the paragraph which states "except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data" implies that the data controller is taking full liability these circumstances are not taking place. If any user is able (and willing) to demonstrate somehow its interests have been damaged, the company who has chosen article 6.f way can be seriously hurt in a court, as they have chosen to operate data processing without any consent from the user. But... as a lawyer was used to tell me: "it's a business decision!" ? More specifically, coming back to PW Comments, we have not to forget ip addresses are stored in the database TOGETHER with the user email, and possibly the user name, so THE REAL USER CAN BE IDENTIFIED. ?This goes beyond the "legitimate interest" case described by 6.f. But definitively these are matters for lawyers ! ?

Well, it depends... ? I am not sure spam, from a pure legal standpoint, can be assimilated to a hacking attack, which may legitimate GDPR lawfulness of processing under legal obligation or legitimate interests cases. GDPR lawfulness of processing is strictly defined under article 6. Even considering broader legal interpretations (here is a good post about it), I think that the safer approach is always to get from the user a "specific purpose consent" (not to be confused with a "generic explicit consent" which would be legally weak). You may achieve a "specific purpose consent" through a GDPR checkbox to be clicked by the user before submitting a comment, being this checkbox properly associated with a Privacy Policy which describes the data processing taking place in this specific case: Getting a "specific purpose consent" from the user, where data processing that will take place will be properly described, matches article 6.a of GDPR. ? Surely I am not a GDPR's fan ?, but having dealt with legal contracts for a couple of decades, I learned it's preferable to prevent than cure... ?

Debian 10 (codename Buster) stable version has been released on July 6. Around a week later it was available for download at my server provider. Yesterday I put myself in good mood … ?and I decided to update my VPS. As Debian 10 comes with PHP 7.3.4-2 bundled, I wanted to take the opportunity to upgrade from PHP 7.0. The process of updating from Debian 9 to Debian 10 was quite smooth. I just had to manually check some configuration files that I previously changed, in particular openssh, sysctl, postfixadmin, and dovecot. All small fixes. I just encountered two issues: emails were not accessible in remote and network.service did not start. The first one was depending from dovecot configuration files, while the second was a bit more tricky to solve. ? I installed PHP 7.3.4-2 FPM/FastCGI and updated the virtual hosts accordingly. So far I did not encounter issues. There were only some incompatibility problems of PhpMyAdmin 4.6.6 (the version that comes from Debian) with PHP 7.3. As I am not in a hurry to update it, for the time being I just reverted its dedicated virtual host to PHP 7.0. And finally let's come to ProcessWire (3.0.123). After the update everything seems to be working well. ? I only had an issue with one of my custom classes. As of PHP 7.2 the word "object" has become a reserved word! ?It took a bit of patience to find, as even with display errors enabled in php.ini you do not get any error (not even in logs) but just the blank screen. ? So far so good! If I encounter any issue I will let you know. Wish you a nice weekend!

Hi @jncs, sorry for taking sometime to reply you, it was a busy week. I just replicated your code in my environment and tested it. I created your two hooks Pages::saveReady and Pages::saved in ready.php and works without any issues. I tested it supplying a constant value to $page->email (my field equivalent). I suspect the issue you are encountering may be somehow related to the modified value storage in the session ($this->session->get("email")) or, as you suggested, it may be affected by cache. If the issue depends from this session variable it should be interesting to trace its contents. I am sure you have good reasons to use session storage, but you may also consider an $email property to your class module (of course the approach is different, but may be useful to validate if the issue depends from session/cache).

Hi @jncs, how do you retrieve $page from within Pages::saved ? Not sure this will help you. It is how to get $page in the hook and return it after it has been manipulated: $this->addHookBefore('Pages::saved', function(HookEvent $event) { $pages = $event->object; $page = $event->arguments(0); // add here your modifications to $page fields $event->arguments(0, $page); });

Hi @chrizz, personally I load all my custom classes through an autoloader called in config.php. For this purpose you can also consider ready.php. However If the custom class is associated only to a specific module (it will be used only when this module is installed) I think you may consider to load it from within the module itself in init() or ready().