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().

@MilenKo, you need to add the round bracket and semicolon ad the end. The last line must be "});"

Hi @MilenKo, the function closing round parenthesis and semicolon were missing, I have edited it above. Please note I had no time to test it, it may be necessary to tune it

Hi @MilenKo, you could try with an hook in ready.php. In this example Pages:saveReady is called right before the page is saved, so this can be used to fill some fields right before save will be executed. Assumption is that this is triggered when you are saving the page from within the Admin area. $wire->addHookBefore('Pages::saveReady', function($event) { $page = $event->arguments(0); if($page->hasField('date_created')) { $page->date_created = time(); } $event->arguments(0, $page); }); I quickly wrote it in the browser w/o testing Please note, this is more a date_modified as it will be overwritten at the next save, but you can easily make it a "true" date_created, with something like that: if(empty($page->date_created)) $page->date_created = time(); Sorry, of course I thought Linux-wise ... as you have a Windows server when you have sometime have look if php locales are installed.

Hi @MilenKo, I may be wrong but it looks like it's returning a php default locale. It may sound like a stupid question, but are your languages locales installed on your server? If you have access to your server you should check the file /etc/default/locale. Running a sudo cat /etc/default/locale you get the list of installed locales. I am asking that as I recall I had first to install locales on the server before I could use them. The html language directive is normally used by the browser or search engines to classify the page by language, so should not be relevant for this issue. Anyway you may wish to set the proper lang using this code snippet where html is generated: <html lang='<?= wire('user')->language->code ?>'> EDIT: sorry too easy ... the above snippet works if you create the following hook in ready.php: // call it using $user->language->code or wire('user')->language->code or user()->language->code $wire->addHookProperty('Language::code', function(HookEvent $event) { $language = $event->object; $event->return = $language->name === 'default' ? 'en' : $language->name; });

Hi @MilenKo, it's curious strftime is only showing the date in English, it looks like the locale is not switching. Can you test the following for each of your site languages: echo setlocale(LC_ALL, 0); // Will return current locale If locale is properly switching you should see the corresponding locale associated to each language. Regarding the datetime field I can try to put in place a small a tutorial.

Hi @MilenKo, forgotten to mention that formatting date created with strftime() has some limitations, in particular if you need a different date format for each locale you code will get more complex. And if in the future you will have to add a new language you will have to modify your code. I believe you can achieve a more flexible result creating a DateTime field, where you will define the output format for each language. You will then add this datetime field to your template. An hook on pages:saveReady can take care to automatically load your datetime field. Each time you will output it as $page->yourDateTimeField it will be formatted automatically, depending on the locale, as you defined during the field creation.

Hi @MilenKo, I think strtotime() is not needed. $page->created should return a Unix timestamp that you can directly supply to strftime(). This is probably the reason you get 1969's date. I tested the following on my site and it seems to be working. The site is multi-language, and the month is properly returned in both English and Italian, without the need to use setlocale(): echo strftime("%d %B %Y", $page->created); and here is the output: Regarding setlocale() in principle you should not need to set them. May be you can check for each language its individual configuration, in Core Translation Files: And add the locale in the field "C": This should be repeated for every language including default one. Not sure this will help.

Probably creating a custom FieldtypeDataLogger (or how your prefer to name it !) may give you the best of both worlds. You could have your own optimized MySQL table schema, while for post-processing/reporting you could embed it as field in a PW page/pages, where you will access individual data (temperature, humidity, etc..) as properties of the field, and with all the advantages of PW selectors.

Hi @mr-fan, you are dealing with a very interesting project! Wow… it brings me back to my previous lives in Microcontrollers and Nand Flash storage... If your MCU timer is sampling analog data every 10 minutes, and your objective is to store them for 5 years at this granularity level (10 minutes), as you have calculated, it means 2.6*10^5 records. That's not trivial at all. I love PW page-storage capabilities, but, on my personal opinion, resulting storage solution would be less efficient and performant than directly storing data into a MySQL table. I would use MySQL table for data storage and PW pages for data post-processing and reporting. A lot would depend from which kind of post-processing you are going to need, but as you are building a simple (but big!) data logger, another option for storage could be even to create a simple flat file to which you are appending a new record every 10 minutes. However MySQL, in the long run, will give much better flexibility, versatility, and performance. If you wish to look for a simple example of using MySQL from inside PW I suggest you to explore at FieldtypeComments core module. Comments in PW are not made using PW page-storage, but as a MySQL table (field_comments) so you can get some useful hints in dealing with MySQL schemas from within PW. Of course you do not need to create a separated MySQL database for your logger, it can be simply a new table inside your existing PW database, exactly as PW does to manage comments. Please also note that PW library provides an embedded support for dealing with MySQL (I did not use it so far, but .. now I feel I need to make a trial soon…) in $database API variable. By the way, if you need any help to create a MySQL data logger table inside your PW database, just give me the data specs, I would be glad to help you in setting up a trace. Wish you a nice week-end.

Hi @Juergen, what about the following: $y = new Y(); echo $y->addText()->setText(' A B C D '); class X { protected $text = ''; public function setText(string $value = null) { $this->text = trim($value); return $this->text; } } class Y { protected $x; public function __construct() { $this->x = new X(); } public function addText() { return $this->x; } } I have tested it and it is working, however I did not thought about it too much, it may be possible to do something smarter. Wish you a nice week end.