Leaderboard

Changelog styles now improved. Here's a changelog from the update screen - no breaking changes detected... ... and here it is with breaking changes ... Raw markdown also get's labelled...

This week we've got a newly updated ProcessWire installer, some nice upgrades to our user profile editor, along with more updates to the new Uikit admin theme that was recently added to the core. https://processwire.com/blog/posts/processwire-3.0.84-core-updates/

Hi, Check this thread if it can solve your problem:

It's available. Extremely alpha. If you discover a security related issue, please get in contact via the forum PM system. Feel free to post any other issues here. PW Repo Entry: ModuleReleaseNotes Github: ModuleReleaseNotes Thanks to @adrian and @Mike Rockett for their kind assistance.

For reference for other who come across this and don't see the github issue: https://github.com/processwire/processwire-issues/issues/434#issuecomment-345437293 Ryan talks about the uncacheAll issue and how to deal with it.

you need to use the classname of the inputfield that you are modifying. your field is inside a repeater, but it is not a repeater itself. if it is a textfield you have to use InputfieldText, if it was a checkbox it would have to be InputfieldCheckbox. Also $field->entityEncodeText = false; is only necessary if you want to use markup in your note

You could also look at this code/module by @Soma for the live search feature: https://github.com/somatonic/AjaxSearch/blob/master/AjaxSearch.js Then its up to you to do your logic in the search.php template. To filter the data, check the doc/example : - https://datatables.net/examples/plug-ins/range_filtering.html - https://datatables.net/examples/api/multi_filter.html - https://www.google.fr/search?q=jquery+datatables+filter

One thing to consider here would be offline or LAN use, where you may not have access to GitHub.. and of course GitHub being offline, though that doesn't happen too often these days. That being said, I personally think that we should limit the starting site profiles to a bare minimum – three or four being the absolute maximum in my opinion. Offering an online site profile installer as an additional option in case none of the starting profiles feel just right would be pretty awesome.

@Tom., there does seem to be something funny going on in this case when hooking before Pages::save. Will do some more testing, but to allow you to move forward with your project the quick solution is just to hook after Pages::save. So in the test case: $wire->addHookAfter("Pages::save", function(HookEvent $event) { $page = $event->arguments('page'); if($page->template == 'bug' && !$page->skip_me) { for($i = 0; $i < 3; $i++) { $p = $page->repeater_2->getNew(); $p->text = 'Bug'; $p->save(); $page->repeater_2->add($p); $page->skip_me = true; // prevent recursion $page->save(); } } }); Edit: did some more testing using a Page Reference field and managed to trace it back to the "uncacheAll" option in PagesEditor::save(). Posted a comment on the other GitHub issue, which is definitely related to your issue. Hopefully Ryan can fix it soon.

Another approach is to not allow users to create pages at all, but rather automatically create a single unpublished page for each user in a hook at the time the user is created. Then each user can populate and publish their page if they wish.

hi dragan, you don't have any limitation when working with InputfieldMarkup. It just RETURNS markup, but of course you can create this markup via php or whatever you want. For example: $html = '<p>This is a test</p>'; for($i=0; $i<10; $i++) $html .= "<div>Line $i</div>"; $field = modules('InputfieldMarkup'); // using the functionsAPI it gets that short $field->value = $html; $form->add($field); but also in my example you could place any PHP code inside the renderChart method.

Thank you so much Robin, I really appreciate it!

thats nice! so what about making a PR on github so that ryan can accept the compressed profile? ...and i'm pretty close to release something even more awesome i have to see if the new online installer changed anything or if it still works.

Hi @teppo. Yes you has a lot of experience and your point of view seems to me to be right. When it comes to slimming processwire it would generally be useful to compress all the images that are in the profiles. I used a compressor from here: https://compressor.io/compress And I compressed the images in the Regular profile that you can download from here: https://github.com/rafaoski/site-compress Comparing it with the uncompressed profile from here: https://github.com/ryancramerdesign/regular I reduced regular profile by 1.5MB, It would be nice to have some compression when adding profiles to the core.

I know, and I can't reproduce any problem, so more of a step by step guide to reproducing the issue on a clean PW installation would be helpful.

$wire->addHookBefore('Inputfield::render', function(HookEvent $event) { $field = $event->object; if($this->process != 'ProcessPageEdit') return; $page = $this->process->getPage(); //... BTW, it would be better to hook a more specific inputfield render rather than just Inputfield::render. So something like InputfieldPageTable::render or whatever inputfield type you are targeting.

It is a public method of the FieldtypePage class. See the description of the arguments in the DocBlock. Not sure. It works for me. But if you're not going to be changing the conditions for selectable pages often then you can just check the template and date in the foreach instead. There is no performance reason to not use a foreach. It's not like a $pages->find() selector where the database is involved. When you do anything with the value of a Page Reference field the entire PageArray (aka WireArray) is loaded (more about that here) and methods like find() or filter() are just foreaching the WireArray internally anyway.

A ProcessWire Fieldtype storing files in a customized location, outside the web root. This module is primarily useful if you need to store sensitive data which should not be accessible directly from the web. Normally, ProcessWire stores all files under /site/assets/files. Direct URL access to these files can be restriced by setting $config->pagefileSecure = true. Still you need to make sure that your template permissions are setup correctly. If something goes wrong, those files could be accessed from outside. GitHub: https://github.com/wanze/FieldtypeSecureFile Modules Directory: http://modules.processwire.com/modules/fieldtype-secure-file/ How does it work? After installing this module, you can create a new field of type SecureFile. Enter your configuration under the "Details" section when editing the field: Storage Location Enter a path outside the web root where the files are stored. You need to create the directory manually. Also make sure that the user running the web server has write permission. Roles allowing to download a secure file Users with a role selected here are able to download the files if a download is requested via the API. Allow Download in Admin If checked, users having a role selected above can download the files when editing a page. I needed this functionality for a recent project, so I created this module and thought to share it, mabye this is useful for someone else Consider it beta, I'm using it on one site but I'm sure it could be improved here and there. Feel free to suggest additional features! Cheers

Check out Tracy Debugger and you'll be glad you did. Then rather than using var_dump and echo you can use the bd() function in your files to get a lovely expandable dump output and the "double output" thing won't be an issue with Markup Regions.

You will need to use a hook, maybe in ready.php. Here's some code to get u started (unstested and written in a hurry). // I can't remember if 'child' will get unpublished and/or hidden pages // you might need to perform other checks (user logged in? => $user->isLoggedin()) $usersChildPage = $parentPage->child("created_users_id={$user->id}"); if($usersChildPage && $usersChildPage->id) { // this user already has a child page; do something else }

Good suggestion - I have actually used this module (slightly modified) on the frontend - works great!

Thanks for this great tutorial! I was playing around lately with modules myself. It's really remarkable how easy it can be. Quick question: Is this the only (or just the "recommended") way to add content in a module page? $form = wire()->modules->get('InputfieldForm'); $field = wire()->modules->get('InputfieldMarkup'); What I'd like, is include() a PHP file that resides either in my modules or my site/templates folder. Or - well - any kind of PHP code right in the .module. InputFieldMarkup will not allow PHP. Is is possible to include just about anything I'd like? Or is this some kind of security limitation? Background: I created a simple custom help page that resides under /admin/setup, and also installs a custom role. If I wanted to extend that to not only use HTML/CSS/JS, but also PHP, how would I do that? (using all of PW's methods... $pages / wire() etc.). I'd like to create some kind of dashboard (just as a proof of concept).

Thanks @bernhard for the brief explanation what I have to do it. I actually sent the PR for the first time ( I hope its good ). In this place addings the link: https://github.com/ryancramerdesign/regular/pull/4 Time will tell if PR will be approved

Challenge accepted

i encourage you to take this challenge as soon as possible. it's really not hard and it will make your head think differently in some situations and make your code cleaner and easier to maintain. and in the end that will save you time have fun

@adrianyour hideotherpages and hideuneditable modules works like charm, but i used createdUser->id with User->id to match and show only those pages which a user has created. Many thanks to adrian, i really appreciated the way he reponds.

@adrian thank you, your module works great, and i have changed a statement after that everything works perfect, now can show only those pages to the logged in users which they have created. this : if($c->createdUser != $this->user) unset($json['children'][$key]); to this: if($c->createdUser->id != $this->user->id) unset($json['children'][$key]);

$pages->find() return a PageArray. Using echo PageArrays always return a string of the Page IDs separated by pipe "|" characters. Since you are looking for a single page you may want to use $pages->get(). To get the title of the page use $pages->get()->title. $pages$tags = explode(',', $page->tags); foreach ($tags as $tag) { $tag = trim($tag); echo $pages->get("tags=$tag")->title; }

@Robin SI think you were right about it seeing the commented out stuff - crazy! I just removed all of the commented out module config and was able to get the mods directory to up it to the latest version...

I haven't followed closely, but please try: $p->save('text'); Or something like that depending on what field(s) you are trying to save. Sorry, I should probably look at this more thoroughly, but not enough time Saving the entire page in a save hook will always cause problems because of recursion.

@Robin S I've updated the forum post with a step by step guide, I'll also add that to the github post.

@Tom., members of the PW community might be able to help with your issue if you can isolate the conditions that cause it and list steps for reproducing the issue. In the GitHub issue under "Steps to reproduce the issue" you just say... ...which really does not make for a useful bug report.

As a general issue... It's a tricky one, how pages that are already selected in a Page Reference field should be handled if they no longer meet the requirements for selectable pages for that field. When getting the value of the Page Reference field via the API, I think the value should be validated through the isValidPage() method when it is "woken up" from the database. Currently the field value is validated on sleep but not on wakeup. Validating on wakeup would solve the situation where the value of the field when accessed from the API is different to the apparent value when viewing the field in Page Edit. But wouldn't solve the fact that the database value still includes an invalid page and so could give unwanted matches in $pages->find() for example. Or if that is not desirable for some reason then I think there should be some improvement to how invalid items are handled in the inputfield. Currently they are hidden in the inputfield, but that means that if you just view the page in Page Edit but do not save then you get a false impression of what the value of the field is. Maybe if invalid items were shown in the inputfield but highlighted in a warning colour, and then those items removed when the page is saved. Would be good to hear what others think about how invalid selected pages should be handled. For your specific issue... If you are foreaching the pages in your template, you could check the template and date of each item to determine if it should be output or not. Edit: you could actually use FieldtypePage::isValidPage() to validate each page in the Page Reference field value in your template, e.g. /* @var FieldtypePage $field */ $field = $fields->home_whatson; foreach($page->home_whatson as $item) { if($modules->FieldtypePage->isValidPage($item, $field, $page)) { // output $item } }

To hide pages from ProcessPageList for non-superusers (doesn't apply for superusers) you can hook Page::listable(). $page->listable() bool Returns true if the page is listable by the current user, false if not. Can also be used as property: $page->listable So to hide pages that the user cannot edit you can add this to /site/ready.php: $wire->addHookAfter('Page::listable', function(HookEvent $event) { $page = $event->object; if(!$page->editable) $event->return = false; });

Have you tried this gist: https://gist.github.com/adrianbj/e391e2e343c5620d0720 With this PW permission: I haven't tested, but I think that combination should work as is, or with a little tweaking. Might avoid you needing to reinvent things.

I'd try to keep things decoupled. So if your php functionality does not depend on anything processwire I'd keep in in a separate class/file even if it's going to be used in a module, which does bind/hook the functionality into processwire.

Do you intend to import this tabular data into PW as pages? If yes, have a look here:

i don't think there is any noticable performance difference (just guessing). the main difference imho is reusability. for small things functions are totally fine. there is a reason why the _func.php file exists in the profile but if you use your function across several pw installations it's for sure better to pack them in a module, host them on some version control system and push updates to all of your sites easily whenever you want. that could get tedious when you have your code spread all over your sites and _func files...

I've been doing functions from the start, but more recently I've had a couple of instances where I go for a custom module. I can't really speak in terms of performance, haven't made any tests, but the module approach feels better when there's more than one or two functions, to organise everything more neatly. Example: I'm working on an online store built from scratch. In that project the server shoots emails all the time. On register, on purchase, on order status changes, etc. Each email has a template that can be edited in the CMS. It becomes complex having to handle multiple templates and usage scenarios, replacing variables, different results based on context, so turning it into a module made it much more organised. I guess for me it's about volume and reusability. If it's small stuff I don't bother.

Thanks for the encouraging feedback folks! @Robin S There's an option to turn off the timed author-auto-shock-via-email(tm) feature which should stop it telling you off too much Actually, the module gives you some options here - including doing nothing more than using git to commit your code - which we all do already. But I think I take your point; I guess the module could induce some of our users to nag us about keeping the upgrade process free of yellow notes. Regarding guidance, I think it partially comes down to your own style working and issuing releases. For example, I commit lots of small changes - which makes my commit log pretty long and difficult to review. In my case, forcing myself to either keep a concise changelog file or to git tag my releases and then use the github release-notes feature, can be better for my module users. Even if I didn't want to start using Github's Release Notes or keeping a changelog, simply learning to add a git tag on each version increment is an improvement, as it allows the length of the commit list to be automatically limited to what is relevant. For someone like Ryan, who tends to commit larger changes at lower frequencies, just using the git-tags feature to limit the list of commits to those between your installed version and the newest version is probably all that is needed.

I've noticed that I need to set the sort order to keep the admin page order (this is what users expect I guess). You can do this like so: $query = 'include=all, sort=' . $this->editedPage->parent->sortfield . ', parent='.$this->editedPage->parent;

Ok, so there is the new version out now which includes a gallery type like the ones in the medium articles. The whole module has been rewritten and I changed the way the galleries are rendered. Instead of weird template files the galleries are now modules which extend the MarkupPwpswpGallery module. Have a look at the readme for some more info. Everything should work just fine when updating despite the code changes. I build a gallery module which should ensure compatibility in case anyone was using her/his own template file. This is the new gallery type „Petersburger Hängung“ The inspiration for that type: https://github.com/SiteMarina/guggenheim The linear partition problem: http://www8.cs.umu.se/kurser/TDBAfl/VT06/algorithms/BOOK/BOOK2/NODE45.HTM https://github.com/crispymtn/linear-partition/blob/master/linear_partition.coffee#L11 (coffee script) Yet, I implemented a simplier and I guess faster algorithm: https://stackoverflow.com/a/6670011/3004669 Maybe I will implement the original algorithm, too, at some point. ...

I needed a way for the files to not force download, so that admin users can quickly view a document in their browser; i added this to the hookDownloadFile() method: $options = []; if($this->wire('input')->get('view')) { $options['forceDownload'] = false; } and then added options to the download: $file->download($options); // Access check performed by this method up in the hookRenderItem i added this: $segments['view'] = 1; $link = $this->wire('page')->url . '?' . http_build_query($segments); $markup .= " | <a href='{$link}' target='_blank'><i class='fa fa-eye'></i> " . $this->_('View File') . "</a>"; $markup .= "</div>"; so now the file looks like this: It would be cool to consider adding this functionality, since it can't always be assumed that the files should force download; maybe it needs to be a config option where you choose the behavior or opt in for download and/or view links...

Glad it works as you want! If you remove that line, then you will hide all pages on your site, because there won't be any direct children of Home that match the name of the current user. One other useful variation you might want to experiment with would be to replace: if($c->name != $this->user->name) unset($json['children'][$key]); with: if($c->createdUser != $this->user) unset($json['children'][$key]); which would hide pages that weren't created by the current logged in user.