Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

31 Excellent

About theoretic

  • Rank
    Full Member

Recent Profile Visitors

1,721 profile views
  1. Hi there! And thanks for Processwire! It appears there's a possible bug in Processwire 3.0.170 concerning file and/or image inputfield. Creating such a field results in the following error: Fatal Error: Uncaught Error: Call to a member function get() on null The inputfield is created however. The closer look reveals a problem at line 60 in wire\modules\Fieldtype\FieldtypeFile\config.php: if(!$value) $value = $fieldtype->get('defaultFileExtensions'); Commenting this line removes the problem, but the newly created inputfield requires 'Allowed file extensions' config option to be set (which is rather expectable since i commented the above-cited line of code). Never faced this problem before, hope it can be resolved.
  2. It appears i've found a quick workaround for the problem. It's not a patch for PW core, just a methodology of writing hooks. Okay, here's a part of real hook which works perfectly on every site/admin pages having a certain inputfield except the admin page for that inputfield: ... $event->return = $event->arguments('page')->parents('template=products')->first()->find('template=cloth'); ... This hook fails on the inputfield admin page because first() is applied to nothing in this case. It's rather logical: the inputfield admin page has no parent with template=product ! So we need to split the above cited code into parts and to add some logic which will prevent the hook error on our inputfield admin page: ... //$realProductsPage works everywhere except the inputfield admin page, it fails there because admin page has no parent with template=products $realProductsPage = $event->arguments('page')->parents('template=products')->first(); //$stubProductsPage is used only on the inputfield admin page to prevent hook error $stubProductsPage = $event->pages->findOne('template=products'); $productsPage = $realProductsPage? : $stubProductsPage; $event->return = $productsPage->find('template=cloth'); ... It's far from being a perfect solution but it works.
  3. Hi everybody! And thanks for Processwire! There's a kind of bug or incorrect behavior associated with hooks for Page Reference fields. The Page Reference field stores references for PW page(s), sorry for being so banal. This kind of field needs some rules to fetch PW pages which will be available as content of inputfield. There are some possibilities to fetch that pages: by choosing their parent by choosing their template by custom find procedure having a nice user interface by PW selector string by custom PHP code Let's now focus on the last 5th option. In this case we should add some PHP code to /site/ready.php . Just an example from PW docs: $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'cloth') { $event->return = $event->pages->find('your selector here'); } }); Up to this point, the things are simple and easy. But what if we will try something more complex? ... $event->return = $event->arguments('page')->parents('template=product')->first()->findOne('name=clothes,include=all')->children('template=cloth'); ... It's an excerpt from my real hook. I tested it both outside of the hook and inside it, it works (fetches the pages i need). But when i try so edit and/or to save my Page Reference field which uses that hook, i get an error of this kind: Fatal Error: Uncaught Error: Call to a member function find() on bool One more time: the above-cited piece of php code is correct. It populates my inputfield with the desired page references, the pages having that pagefield can be saved, fetched and so on. The only problem is that fatal error during save/edit of pagefield itself. I can suppose that this error takes place because the above-cited custom php code deals with some parent page(s). It works when the inputfield is used by non-admin PW page having correct parent(s) expected by cutom php code, but fails when we're trying to work with the admin PW page representing this inputfield itself. If so, we can consider a kind of "sandbox" for custom php code of this kind. Ideally, it shouldn't give us a fatal error even if it's incorrect. It should better throw an exception and output a warning, still giving us possibility to edit/save the inputfield admin page. Any ideas are welcome. Thanks in advance!
  4. Hi guys and ladies! And thanks for Processwire! It appears i've got an interesting issue concerning the template-settings-based PW redirects dealing with access control. Any PW template has some access control options i.e. "Login redirect URL or page ID to render". If this option is used for a page having a template with this option filled, a redirect will occur if user is not logged in and/or has insufficient access rights. I like to hook PW events. In one of my current projects i decided to write an addHookBefore('Session::redirect', ...) which should store the page we are being redirected from. With "regular" redirects like $session->redirect('/somewhere/') this hook works like a charm. But it was strange to see that it doesn't work with the template-settings-based redirect. I'm too dumb to dive deep inside PW and to examine the whole PW session mechanism. But it could be rather logical if ANY redirect ( no matter template-settings-based or using $session->redirect() ) could be hooked in the same manner. Okay okay i can forget about template-settings-based redirect and write my own. Just a couple of lines of code, and it works. But it's less elegant than hooking the template-settings-based redirects. So am i missing something? It this behavior a bug, or is it intended by PW team? Thanks in advance for any comment!
  5. P.S. It appears that the problem exists in Firefox only. Vivaldi renders such pages nice and smooth.
  6. Hi guys and ladies! And thanks for Processwire! It appears i've found a very specific case of template rendering behaviour. The steps to reproduce this: Enable markup regions in site/config.php: $config->useMarkupRegions = true; Let's suppose we have a data file templates/data.php with the content like this: <? return ['name'=>'value']; ?> This file is included into a template file default.php in the following way: <? //getting data from external file $data = include 'data.php'; //the rest of template logic and output ?> <html> <?=$data['name']?> </html> In this case the pages with default.php template are being rendered in a very strange way (at least in fresh Firefox). A flash of unstyled content, followed by repaint and rendering of styled content. It's very likely that the "return - include" construction causes some output before all the page html is fully prepared. It's easy to "fix" this behaviour: <? //inisializing $data in-place $data = ['name'=>'value']; //the rest of template logic and output ?> <html> <?=$data['name']?> </html> I like that "include-return" code approach and use it in many of my projects, and it was always giving no problem with page rendering. With the markup regions turned on, it becomes a problem. Are there any ideas how to use both "include-return" and markup regions together with no rendering trouble? And what could cause that trouble? Thanks in advance!
  7. For me it's still showing 3.0.153. Tried it using different browsers so it's definitely not the caching issue. Maybe it's because i'm in Russia? 😉
  8. @zoeck , thanks! It's a problem with the caption of download button. It says 3.0.153 but in fact it triggers the download of 3.0.155. Only the caption should be changed!
  9. Hi everybody! And thanks for Processwire! Guess many of us have noted the strange fact that there's a post about new Processwire 3.0.154 - 3.0.155 dev branches full of interesting new features but they still are not available for download. At the moment i'm writing this post the last available dev is 3.0.153 . For sure i don't want to force core develpers to make new branches available, it's just to clarify the situation. Dear devs, when could we expect the last dev branches to be available for download? Thanks in advance!
  10. Hi everyone! And thanks for Processwire! It appears i've found a bug related to translation of template files. I'm developing a website under Windows and publish it under Linux. When i try to add some translations to a template file in production environment (under Linux) this thing happens: File does not exist: /site\templates\product.php (translation file not needed? textdomain: site--templates--product-php) Under Windows i have no such problem. It's obvious that there's a problem with directory separator. It's a backslash ( \ ) under Windows and normal slash ( / ) under Linux. Have no idea how to make PW recognize this situation which makes impossible to translate templates in production environment. Thanks in advance for any possible help!
  11. Hi there! Got a strange WireMailSMTP behaviour. I'm sending emails via Gmail which works fine except one problem. Gmail browser client shows that emails like this: xxxxxxxxx@gmail.com 16:56 (23 минуты назад) кому: я X-Mailer: ProcessWire/WireMailSmtp Date: Tue, 24 Sep 2019 13:56:49 GMT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="99e7bb5336c619adedcc743d03b1ec46" Message-ID: <20190924165649.0537.xxxxxxxxx@gmail.com> --99e7bb5336c619adedcc743d03b1ec46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =D0=9F=D0=BE=D1=81=D1=82=D1=83=D0=BF=D0=B8=D0=BB =D0=BD=D0=BE=D0=B2=D1= =8B=D0=B9 =D0=B7=D0=B0=D0=BA=D0=B0=D0=B7 . --99e7bb5336c619adedcc743d03b1ec46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =D0=9F=D0=BE=D1=81=D1=82=D1=83=D0=BF=D0=B8=D0=BB =D0=BD=D0=BE=D0=B2=D1= =8B=D0=B9 =D0=B7=D0=B0=D0=BA=D0=B0=D0=B7. It's obviously the quoted-printable decoding problem. Google also allows to download any message as .eml file, and here's a sample of what is inside such a file: X-Mailer: ProcessWire/WireMailSmtp Date: Tue, 24 Sep 2019 13:56:49 GMT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="99e7bb5336c619adedcc743d03b1ec46" Message-ID: <20190924165649.0537.xxxxxxxx@gmail.com> --99e7bb5336c619adedcc743d03b1ec46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =D0=9F=D0=BE=D1=81=D1=82=D1=83=D0=BF=D0=B8=D0=BB =D0=BD=D0=BE=D0=B2=D1= =8B=D0=B9 =D0=B7=D0=B0=D0=BA=D0=B0=D0=B7 . --99e7bb5336c619adedcc743d03b1ec46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =D0=9F=D0=BE=D1=81=D1=82=D1=83=D0=BF=D0=B8=D0=BB =D0=BD=D0=BE=D0=B2=D1= =8B=D0=B9 =D0=B7=D0=B0=D0=BA=D0=B0=D0=B7. Both samples are parts of the same letter with some editing applied (real address changed, some inline css skipped etc.). Is there a way to make Gmail decode such letters in a correct way? Thanks in advance!
  12. Hi guys and girls! And thanks for Processwire! Just to give some help with Google account settings for WireMailSMTP. They are pretty well known... but Google appears to reject SMTP authentication from "non-trusted apps". There's however a solution which doesn't make Processwire "more secure" (from Google point of view) but unlocks the possibility of sending mails by WireMailSMTP using a Google account. You need to enable 2-factor authentication for Gmail account which You want to use with WireMailSMTP. You need to generate an "app password" different from Gmail account password. This "app password" should be used as SMTP password while setting WireMailSMTP up. Bingo! No more blocking. P.S. In my case, that Google blocking was occuring even if i tried to send a single letter per day. I'm not sending spam, just notifications for website owner/manager.
  13. Hi everyone! And thanks for Processwire! A small bug found in this great admin theme. It concerns the datepicker behavior. If we have two date fields one below another, the first field datepicker may slide below the input field of second field. The problem can be resolved by changing the AdminThemeBoss\uikit\dist\css\uikit.(color).min.css from: .pw .ui-datepicker#ui-datepicker-div { z-index:2 !important; background: ... to: .pw .ui-datepicker#ui-datepicker-div { background: ... Thanks again for this nice theme!
  14. @Zeka, thanks! The built-in selector array representation is good for relatively simple queries. But i couldn't find any example of correct select array syntax for cases like my_repeater = [ my_repeater_field1=value1, my_repeater_field2>value2, my_repeater_field3%=value3 ] I suppose that there's some array syntax for cases like this but i could'n find it.
  15. Hi there! And thanks for Processwire! It appears that i've found something interesting about PW selectors. They should only be strings! Here's an example of SQL-like syntax for selector: $my_complex_selector = " name='some name', parameter=123, other_parameter=[subparam>=subvalue] "; Trying to use this selector lead to a very buggy PW behaviour. It appears that newlines are treated in a very special manner by PW selector engine, preventing the newlined selectors from working as expected. I cannot imagine a situation when an unescaped newline could be a part of selector or selector value, so stripping newline symbols from selector could be a good idea for further PW development. And, currently, another good idea is to write complex selectors as PHP arrays: $my_complex_selector = [ "name=$name", "param1=$param1", ]; and to implode them into a single line before using find() and other functions which use selectors. Sorry if i wrote something trivial, but having this post already present at support forum could save me a couple of hours. Hope mine will save that tame for someone else 😉
  • Create New...