theoretic

Hi friends! And thanks for Processwire! Maybe i'm missing something, but i have no idea how to select an (admin) page by the process it uses. It could look this: "template=admin,process=my_process_name" This could be a great help while using a perfect ProcessSettingsFactory module (many thanks to @Macrura!). That module allows to create admin settings pages, each holding a certain set of configurable data fields. Getting that fields is a piece of cake: $settings = $settingsFactory->getSettings('general'); //'general' is the name of admin page holding the settings $phone = $settings->phone; Works great when we need quite a limited number of settings. But when the things are getting bigger, it becomes quite reasonable to create a number of settings pages and to organize all the settings into a unified structure. Here's an example how it could be: //getting all settings pages $settingsPages = $pages->find("template=admin,process=ProcessSettingsFactory"); //creating the settings object $settings = (Object)[]; //putting all data from settings pages into $settings object foreach( $settingsPages as $settingsPage ){ $settingName = $settingsPage->name; //e.g. 'general' $settings->$settingName = $settingsFactory->getSettings($settingName); } //now we can use the $settings object echo "<a href=mailto:{$settings->general->email}>Mail us!</a>"; This approach definitely requires a process-specific selector. Guess that it could also be implemented at module level but having a specific selector for process could be useful in a large number of tasks. Will appreciate any idea )

@Jan Romero, You're super cool! That extra slash in form action value resolves the problem. Thanks a lot!

Hi friends! And thanks for Processwire! I've got a strange PW behavior which i cannot explain. Maybe i'm missing something. I have a form with method=post and action=action_page (different from page where the form resides). I'm trying to use post vars in the action_page's template. Both $_POST and $input->post() are empty. Deeper analysis shows that PW performs a http 301 redirect to action_page after the form is submitted, so all post vars are no longer available. How can i prevent PW from doing so? Did some simple tests to find the reason, i'm 95% sure that the redirect is triggered by PW. Thanks in advance for any advice!

Hi everybody! And thanks for Processwire! I like PW hooks and use them in almost all of my projects. But it appears i'm missing some functionality. Some pseudocode to explain my wishlist: //somewhere in site/ready.php addHookClass('Page(template=my_template)::my_data', function($event) { ... } //somewhere in site/templates/my_template.php var_dump($page->my_data); //should output a multilevel array or nested objects $page->my_data->set('some_var',$some_value); //doesn't write to database $page->my_data->save(); //$page->save('my_data') is not applicable here because my_data is not a regular PW data field In fact i'm trying to create a solution for manipulating per-user settings (how to display some data on some pages etc.) but this approach may appear to be useful in different cases. Any suggestions are welcome!

Just to clarify the situation. It appears that i've run into Firefox memory issues. I have many Firefox tabs and windows opened at the same time, and sometimes it may lead to strange effects concerning sessions and cookies. So it's not a Processwire-related issue. Hope this will be useful for someone.

Hi guys! And thanks for Processwire! I got a strange issue concerning user system behavior. Maybe it's a bug in Processwire, maybe i'm missing something. I'm developing a site having 2 different user templates: the native user template and member template. The alternative user template setup has been done according to official tutorial. What's working fine: "Regular" users can log in and log out as intended Member users also can log in and log out as intended using $session->forceLogin($memberUser) and $session->logout() "Regular" users (all having superuser permissions) can access admin pages and use them Member users have their own set of permissions, they cannot access admin pages What's buggy: Both $session->forceLogin($memberUser) and $session->logout() have no effect on "regular" user sessions. Logging in/logging out regular users have no effect on member user sessions. Member users can only access their own personal pages with member template, trying to access other member pages gives 404. The only project-specific thing which could potentially lead to this behavior is the empty password field for any member user. They always log in using $session->forceLogin() and credentials obtained from external API. Tried to assign a password for one of member users; that user could log in/log out using admin page but the above-described bugs were still the same for him. Have no idea how to fix this, will appreciate any help. Thanks in advance! P.S. I'm using Processwire 3.0.201 in both dev (Windows) and test (Linux) environments.

Thanks @matjasp! It's exactly what i've missed.

Hi friends! And thanks for Processwire! I've found a... hmm, not a bug but rather missing feature. Let's imagine we have a field of type Page Reference. Due to some reasons (e.g. for having possibility to create new pages directly from inputfield) we assigned a Parent page to Selectable pages settings of our inputfield. Later we decide that we n o longer need that Parent page setting. And - voila! - there's no possibility to unset it. In fact, this impossibility may lead to errors like "A page does not have necessary parent" which may appear while populating our inputfield programmatically. At the moment, the only way to fix this is to edit the database manually and to delete the parent settings from 'data' column. Hope this will be fixed in later versions of Processwire. Thanks again!

@Pixrael, good question! I thought that PW database uses InnoDB by default but it was wrong. Did an InnoDB migration without changing any code, the concurrent tests are experiencing the same troubles as before with MyISAM, but now there will be more space for experiments. Thanks!

Hi friends! Many thanks for the brilliant Processwire! I have an interesting question concerning concurrent requests. I'm working on a PW-driven API which should pass some tests required by my client, including a so-called concurrent request test. The test harness generates a certain number of unique http requests and "fires" them in almost no time (they're received by webserver with time difference of the order of milliseconds). However far from real life use cases, this test is absolutely required by my client. Experiencing such a high (however short) load, PW reveals some weaknesses mainly concerning database interaction. Almost all concurrent requests should update a PW-driven numeric data field (in fact a database table). Concurrent requests try to increment/decrement its value, and after that a final check of the field value is performed. In most cases the final check fails. In-depth study shows that PW may receive new requests before the current request is processed, and this may lead to wrong final value. I tried some possible solutions: Wrapping field-changing operations in a database transaction. No success. Using mysql table lock. In my case this also didn't give a versatile result. Writing a lock mechanism denying any operation with data field until the previous request(s) are ended. Not versatile enough again. Organizing request queue. Maybe the best possible solution, but didn't try it yet. So what are your ideas in this case? Any possible approach is welcome ?

Hello everybody! And thanks for Processwire! I have an interesting task which i couldn't resolve in the way i'd like. Hope someone will give a good advice ? So let's suppose we have pages with template called 'event'. We need an easy way to check whether a user can participate in this or that event. In such cases i'd like to write a hook of this kind: //somewhere in site/ready.php $wire->addHookProperty('User::canParticipateIn', function($event) { //deciding whether user can participate or not $event->return = $result; }); //somewhere in a template file if( $user->canParticipateIn ){ //displaying a form etc. } This generally works with simpler tasks. But in this particular case we need to pass an argument to our newly created hook function. This argument will be an event page instance. So our possible hook should change to something like pseudocode below: //somewhere in site/ready.php $wire->addHookProperty('User::canParticipateIn', function($event) use ($page) { //deciding whether user can participate or not $event->return = $result; }); //somewhere in a template file if( $user->canParticipateIn($eventPage) ){ //displaying a form etc. } Unfortunately this doesn't work. Processwire gives an error: So is there any way to pass an argument to a hook in this case? Thanks in advance for any possible answer!

I think that due to almost-impossibility to change Processwire default language it's not necessary to explicitly name the language from which the text will be translated. It's enough to change all "Translate from English" phrases to just "Translate".

Hello Robert! Thanks for a perfect module! I've made some changes to it (e.g. possibility to set the source language in module settings), how can i collaborate with You?

Hi all! As of end of May 2021 the situation has changed. PagePermissions.module included in Processwire 3.0.178 (and maybe in some of previous versions) has been updated, and @Jan Romero's patch is no longer actual. However you may need to manually create a new permission called user-view-all and apply it to guest role and maybe some other roles. After that guest users will have possibility to browse custom user profile pages.

@Jan Romero, thanks a lot! Your patch resolves the problem. I think it deserves Ryan's attention and should be added to Processwire core.

Hi there! And thanks for Processwire! I've got an interesting case concerning access to current user page. It appears that PW somehow limits access to the frontend page of current user. I'm speaking about a specific PW configuration. We have two kind of users: 'regular' users with native user template and member users with specific member template and specific members parent page (by the way, it's so cool that PW allows to use custom user templates and custom parent for certain user pages!). So a member with name Joe has a page with member template and url like /members/joe . The members template has some access limitations: only member users can see pages with member template. It works like a charm in most situations. For example, user Bill (who has member template and is logged in) can browse a page with url /members/ann which also is a member page with member template. And now, meet the glitch! The above-mentioned Bill cannot get to his own page /members/bill ! PW generates 404 page instead. I see no reason for this behavior. From my point of view any member should have access to any member page in this situation. What am i doing wrong? Any advice is welcome!

Sorry guys. It appears i've run into an issue with the forum editor. I tried to edit my post around 10 times, it's still not visible. So i'll try to post it as plain text. Hi there! And thanks for Processwire! I have an interesting task which i cannot fulfill as i want. Maybe someone could help me please? Let's imagine a simple page structure of this kind: Category 1 + Item 1.1 + Item 1.2 Category 2 + Item 2.1 + Item 2.2 My task is to attach some items to more than one category, at least to show some items on different frontend category pages. With PW, it's a piece of cake. I've just created a field called Items (of type Page Reference) and attrached it to Category template. Since i have lots of items inside each category i preferred to use Page Autocomplete input for my Items field. The pages available for autocomplete are restricted by a very simple selector: template=item It works like a charm. But later i decided to make this autocomplete even smarter and to exclude current category children items from it. I tried to update my selector this way... template=item,parent!=(page) ...and oops, this broke my selector. My autocomplete founds nothing. Sorry, i had to replace the square braces by () because of forum limitations, i swear i'm using square brackets in real-life selector! What am i doing wrong? And is there any way to include current page info in autocomplete-related selectors? Thanks in advance!

Hi there! And thanks for Processwire! I have an interesting task which i cannot fulfill as i want. Maybe someone could help me please? Let's imagine a simple page structure of this kind: Category 1 + Item 1.1 + Item 1.2 Category 2 + Item 2.1 + Item 2.2 My task is to attach some items to more than one category, at least to show some items on different frontend category pages. With PW, it's a piece of cake. I've just created a field called Items (of type Page Reference) and attrached it to Category template. Since i have lots of items inside each category i preferred to use Page Autocomplete input for my Items field. The pages available for autocomplete are restricted by a very simple selector: template=item It works like a charm. But later i decided to make this autocomplete even smarter and to exclude current category children items from it. I tried to update my selector this way... template=item,parent!=(page) ...and oops, this broke my selector. My autocomplete founds nothing. Sorry, i had to replace the square braces by () because of this forum limitations, i swear i'm using square brackets in real-life selector! What am i doing wrong? And is there any way to include current page info in autocomplete-related selectors? Thanks in advance!

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.

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.

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!

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!

P.S. It appears that the problem exists in Firefox only. Vivaldi renders such pages nice and smooth.

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!

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? ?