szabesz

Hey Charles, I've just read The Inerview: https://pwreview.com/series/interviews/featured-professionals/ryan-cramer/ big thanks for that, too! My favorite messages in it: "...just go with the flow..." "...working through the issues... ...it's about solving mysteries..."

@matjazp Thanks for the info! I am going to evaluate it in this case.

Yeap, I did realized that too. If one needs PW's out of the box pagination support, simply filtering with if($page->viewable()) is just not enough, it can only be used as a last resort to prevent information leakage but that does not necessarily mean issue-free code. The approach I came up with in a nutshell is (besides using PW's built in access control): Hooking after Page::viewable with custom access checks and using if($page->viewable()) where needed. Hooking before Page::render with custom access checks, in order to block certain page access cases. Added hook method (Pages::siteFind) which delegates its task to Pages::find but before doing so it modifies the selector string based on certain conditions in order to prevent fetching certain records in the first place. However, my approach is rather crude and hardcoded into the site, so there is a lot of room for improvement here. I do not know if I should spend the time on evaluating DynamicRoles as I do not have too much time to waste, but what makes it compelling is this bit I read in Ryans intro: "This module directly affects the results of all page getting/finding operations by applying the access control directly to the database queries before pages are loaded. As a result, it is fast (regardless of scale), pagination friendly, and requires no further intervention by the developer other than configuring the dynamic roles as they see fit." Anyway, if you guys no longer use DynamicRoles with current versions of PW, then may I ask what other approach you use? Any guidance would be appreciated.

Thanks for the reply! Maybe others can chime in? Anyone out there using Dynamic Roles in production?

Hi Adrian, Thanx for the reply! Actually, it is probably me who needs Dynamic Roles. So do I understand it right that the fork of @matjazp is ok to install in production? This weekend I worked on implementing some sort of dynamic roles just to see how far I can get and also to study at least the basics in this area. However, if this fork is quite OK to use then it should be the way to go, I think. Side-note: it's a pity that Ryan left Dynamic Roles in the dust ?

Here is a discussion related to this issue, in which Ryan explains the API decisions: https://processwire.com/talk/topic/11736-get-requests-not-subject-to-access-control To sum it up real quick (quotes): A $pages->find() or $pages->findOne() method that filters results is based on database-filtering, not runtime filtering. The API is based around providing methods for the developer to control access the way they see fit. The viewable() method is the basis of that. PW's access control model supports runtime hooks to Page::viewable. One shouldn't skip a $page->viewable() call regardless of what method you used to retrieve the page. When rendering frontend templates <?php if ($page->viewable()) : ?> (or $page->viewable('field_name'); ) is the way to go to check for default PW permissions. For example: https://processwire.com/talk/topic/4834-simple-hooks-tutorial-turn-a-pagearray-into-a-list-of-links/ ... // loop through each item in the PageArray and render some links foreach($event->object as $page) { $value = $page->get($property); if(!strlen($value)) continue; // skip empty values if(strlen($out)) $out .= $delimiter; if($page->viewable()) { $out .= "<a href='$page->url'>$value</a>"; // if page is viewable, make it a link } else { $out .= $value; // if page is not viewable, just display the value } } ... In order to "extend" the access control logic, one can hook after Page::viewable eg.: https://github.com/processwire/processwire-issues/issues/560#issuecomment-384656192 quote: // goes into /site/ready.php $wire->addHookAfter('Page::viewable', function($event) { $viewable = $event->return; if($viewable) return; // use PW's existing logic, since it said it was viewable $page = $event->object; if(!$page instanceof User) return; // this is an example for User templates only if(whatever logic you decide that $page is viewable) { $viewable = true; $event->return = $viewable; } });

I have become famous! ?

I'm only interested in models with a great "view": https://www.google.com/search?q=models&tbm=isch Don't even try to control them, youl'll fail!

https://stackoverflow.com/questions/28278705/always-populate-raw-post-data-trouble-accessing-request-payload-from-backbone?answertab=votes#tab-top I guess you are on PHP 5.6. Can't you upgrade to at least to 7.0.x?

https://github.com/rolandtoth/AdminOnSteroids/wiki/AddNewChildFirst

Also worth noting that there is a 7 page book related to the rejection craze of jQuery and other libraries: https://www.oreilly.com/programming/free/native-javascript-apis.csp Quotes: "If you’re using native APIs in your application logic, you can’t help but know what browser is being used because you need to account for browser differences. That means your application logic will always need to be updated as new browsers and new browser versions are released. That’s a recipe for disaster. ... You should absolutely be using a JavaScript library to abstract away browser differences for you. ... Libraries like jQuery, YUI, and Dojo abstract away browser differences behind facades, which allow you to focus on building your application logic in a browser-agnostic way. ... So, keep using your favorite JavaScript library. Don’t be tempted by the draw of native APIs simply because you can avoid downloading an external library. Using native APIs comes with a high cost of maintainability down the road." People write spaghetti code because they do not know JavaScript well enough and/or do not use appropriate design patterns, which is not jQuery's or other libraries' fault. One can just as well produce unmaintainable code by using any framework out there. Here is the case of UIkit 3 which relies on its own 132k JS library which is only partially documented: https://github.com/uikit/uikit-site/blob/feature/js-utils/docs/pages/javascript-utilities.md They say: "...allow you to write simplified Vanilla JavaScript and replace the most common functions of jQuery" So they got rid of jQuery by partially re-implementing its features. Good to know... Now if I add jQuery I have overlapping feature sets and the visitor of the site has to download more assets ? Is it an improvement? At the same time the current full version of jQuery (3.3.1) is 87k and one can use versions leaving out features not needed (say AJAX or effects if not used on a site), so it can further be trimmed if the projects allows. Introducing a mature and maintained JS library called JsViews: Currently, I have started to build upon a library which can either be used along with jQuery or without it: https://www.jsviews.com/ It is from one of the jQuery authors. Worth checking out the examples, eg.: https://www.jsviews.com/#samples/computed/team-manager JsViews can be used without precompiled JS templating – so it is easy to get started – and it is still very performant that way. One can also use a builder to precompile the templates if needed (think of the needs of overly complex JS apps and NOT websites). By using JsViews one can rely on declarative programming and build upon design patterns built in. By adding jQuery to it, code becomes shorter, easier to read and maintain.

Thanks for sharing! It is also worth noting the existence of something similar: http://modules.pw/

I told you Vivaldi a is good browser ? I wonder how you picked it, did you spot it on this nice tree? ?

+1 for Tabulator. I have not yet used it though but this is the one I like by reading the docs and seeing all those examples, so as soon as the needs arises I will surely use Tabulator as I could not find a better alternative for my usual needs.

260 pixel versions are generated by the admin, you need these there. 1024 versions must come from another source you somehow added to the system, so if you can identify its source, you can get rid of these. Here is a recent discussion you might be interested in:

Hello, do you need something like this: https://processwire.com/blog/posts/processwire-3.0.63-adds-client-side-image-resizing/ ? Or are you after something else? Can you please explain what you are referring to?

The relevant rules are explained in .htaccess: https://github.com/processwire/processwire/blob/master/htaccess.txt#L145 I recommend keeping these rules and pick a location which is not protected bye the default .htaccess file.

@Robin S has already provided us with hundrends of goodies, one of them this deals with it: https://github.com/processwire/processwire-issues/issues/70#issuecomment-258023285 same in the forum: https://processwire.com/talk/topic/1674-sorting-repeater/?do=findComment&comment=131713

All this issue is still muddy (as ususal....): https://www.i-programmer.info/news/81-web-general/12643-eu-copyright-directive-approved.html "This has been picked up by Florian Mueller on his Foss Patents site. In a post with the title, Even after today's EU Parliament vote, we can still kill Article 13 through pressure on German government to prevent formal adoption by EU Council,..." also: "As we've previously pointed out these concessions are very much open to interpretation leading to uncertainly that will undermine the Internet."

Have you tried this: https://processwire.com/talk/topic/45-url-schema/?do=findComment&comment=150 "ProcessWire will support .html extensions. You just have to make them your page names, i.e. "about.html" rather than "about", or look for them in urlSegments. I've actually done this before, though for specific pages (like /sitemap.xml), not on a site-wide basis. But I don't see any problem with it conceptually."

It is worth noting that in the music industry only the most popular artists gain money (and a lot), anyone else is left in the dust as no one cares when their creative work is "stolen". Probably the same mechanism will be put in practice in this case too. Copyright fee on blank CDs, tapes and such? These guys work hard to rip us off.

@happywire I think in the foreseeable future we cannot expect Ryan to change the way ProcessWire manages images so it is up to us to implement it the way we want to. As it is an "advance topic" I do not think it will be documented in details, except if we do it ourselves. One good way of doing it is how @bernhard wrote a great tutorial, which was happily published by Ryan in the blog: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ If you have the time to do your own research regarding this issue and ask others for more info then you might want to sum it up for us to in a similar tutorial. Most of us have their own way of managing images but this should not bother you, just do it your own way and help others by publishing it you have the time. ProcessWire pages under processwire.com/docs/ cover most what is needed for developers to get started but the blog articles often highlight even more, it's just that they are buried in there. Forum and Githubs issues also have a lot of information, but those are even more buried. However, I do not think that it will be possible to organize it all, so doing our own research is a must. Most of us perform custom goggle searches in order to dig into all these sources. The goos thing is that under the hood of ProcessWire things rarely change, so most things you are going to read in these sources are still relevant and work. However, the there have been major upgrade to images field, just search like: https://www.google.hu/search?q=image+site%3Aprocesswire.com For example: "In the new images field, they are now 260 pixels in the smaller dimension, scaled to 130 pixels (for HiDPI/retina support). The actual size and HiDPI support can be adjusted in config.php settings in $config->adminThumbOptions, though we think most will likely want to keep the default settings." https://processwire.com/blog/posts/major-images-field-upgrade/ So using gridSize it is possible to set the dimensions: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/config.php#L636 I do not exactly know how it should work though. When I set 'gridSize' => 100 and 'scale' => 1.0 then "1.0=force non-hidpi" should kick in, and in my understanding with this setting I should get images no bigger than 100x100 pixels. However, with this setting I get 200x200 pixels or less. Maybe it's me who does not understand the comment in the code. Also, there is this part in the comment: "1=allow hidpi, 0.5=always hidpi" which does not make any difference at all. In my case not matter what is set to scale, the admin thumb will always be twice the value of gridSize. It's not that hard, just sart by reading https://processwire.com/docs/modules/ and Bernhard's article.

I have a site where I also take advantage of this. I implemented a custom image process algorithm, whereby I check the extension of the uploaded image, rename it and after that create predefined variations (using Imagick) based on the aspect ratio and/or the dimensions. I put all this into a custom module which hooks into InputfieldFile::fileAdded, something like: $this->addHookBefore('InputfieldFile::fileAdded', $this, 'hookRenamePng', array('priority' => 10)); $this->addHookAfter('InputfieldFile::fileAdded', $this, 'hookCreateJpgClones', array('priority' => 10)); BTW, have you read this Github issue? https://github.com/processwire/processwire-issues/issues/703 it is somewhat related.

Thank you! I myself actually like the idea that the custom indicator is always visible. Thanks for reminding me. Strange but I've never had the need of them, bd() and d() have just been enough. Maybe it is because I tend to prefer very targeted checks.

Thanks for this and all your work on the other issues. I think the current sate is just good enough!