Leaderboard

The go to classic: And this gist by Soma. https://gist.github.com/somatonic/4150974

This week I’ve been working on a combination of the core, and a PW audio-streaming project for a friend, working as a volunteer. There’s some overlap in these two things, as a lot of the core updates this week are somewhat related. It provided the needed motivation to finish a new feature I started working on in 3.0.149, which will be finally finished in 3.0.166. Actually, it’s finished now, but I haven’t bumped the version number on the dev branch yet—I’ll do that next week. The feature finished this week adds support for a new secure files option similar to the $config->pagefileSecure option (you may or may not have heard of), except that it allows you to configure secure files at the template level, rather than just site-wide level. In ProcessWire, when you unpublish or trash a page, or when you access control a page so that it’s not visible to guest users, the page’s files in /site/assets/files/page-ID/ can still be accessed directly by URL (like if someone bookmarked a PDF or something). So we have the $config->pagefileSecure option that lets you specify that the files should also be access controlled. This ensures (for example) that if a page is unpublished, its files can’t be loaded by anyone except a user that can view unpublished pages. But I rarely use this option because it is site-wide, and access controlled files take some overhead (being delivered by ProcessWire rather than Apache) and thus are something I’ve always wanted finer control over. That’s because most of the time, I don’t care too much about direct access to files because they are mostly images and endless variations of them. But there are also those specific cases where I really do need it. So being able to make it part of the template-level access control really makes it a lot more flexible, and hopefully makes the option a lot more obvious: There’s also that “Yes always” option (in the screenshot above), which is something we’ve not had before. This is useful when you want to have full control over a file download (or stream). Because the files would always pass through ProcessWire, you can hook any part of the process, keep a download counter, log downloads, etc. ProcessWire supports partial file delivery and delivery of specific byte ranges and seeking, which comes in especially handy with <audio> tags. In the case of the project I was working on this week, the audio streams are available only to logged in users (via LoginRegisterPro) and we had to find a way to make the audio files protected from direct access, so that they would only work as a stream through an <audio> tag to an authenticated user, not be accessible outside of that, and not be downloadable. That was all a bit of a challenge, but a fun one. If anybody ever runs into a similar need, be sure to send me a message. I have a few more things I want to work into version 3.0.166 before bumping the version number, so that’ll likely come by this time next week. I also hope to fully wrap up the new version of either FormBuilder or ProCache next week, followed by the remaining one the following week. Thanks for reading. Have a great weekend!

https://processwire.com/docs/start/variables/input/ https://processwire.com/blog/posts/pw-3.0.125/ https://processwire.com/api/ref/wire-input/ $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->name == 'myselect') { $temp = $this->wire('input')->get('temp', 'text', 'fallback-template'); $event->return = $event->pages->find('template=$temp'); } });

All has gone smoothly with the new master branch version of ProcessWire (3.0.164), officially released last week. Next week we’ll also be releasing 3.0.165 on the master branch, which will fix a couple minor issues that have surfaced. Though we are talking very minor, so there’s no reason to wait on upgrading. The dev branch commit log covers changes since 3.0.164. There will be more commits next week and then we’ll be on version 3.0.165 on both dev and master branches. This week, in addition to some minor core updates, I’ve been working on updates for both ProCache and FormBuilder. The ProCache updates primarily focus on providing better API functions for finding what’s cached, adding more hooks, and providing better control over when and how cached versions of pages originating from URL segments are cleared from the cache. On the FormBuilder side, I’ve been focused on improving our submitted form entry listing tools for the admin side. Prior to the version in progress, it hasn’t been possible to perform custom searches on submitted form entries, the way that you might do in Lister/ListerPro for pages. Nor has it been possible to sort by anything other than created or modified date. That all changes in this new FormBuilder version. Now you can search within and sort on any field in the entries listings. You can search and filter by any number of fields at once. You can select what fields/columns display, and in what order. You can export (CSV) rows that match your search criteria. It’s basically like a mini ListerPro, but for forms submitted on your site. So far I’m finding it extremely useful in testing here, and I'm excited to release it in the FormBuilder support board. Below is a screenshot. I should have this version released in the FormBuilder board in 1-2 weeks, along with some other updates to it. Thanks for reading this quick update and have a great weekend!

I would like see the bookmark feature as well. Now that I am using LIsterPro I see the benefits of something like this.

@ryan The export/import module is great, but it would be nice if it could import focus points of images and SVG files. ? Not sure if I should post this to the Wishlist board or as processwire-request issue on GitHub. Just wanted to mention it. Regards, Andreas

Moderator Note @maddmac I split your question into its own topic as it was not related to the thread where it was (Captain Hook).

@MSP01 1.. pw cachis any.thing it load, so no.many how times u.cal $page->feld or $page->parent->smoga or $page->feld->bilpa --- it load feld or smoga or bilpa 1 time....... if autojoinin for.feld smoga or bilpa then it load it with th 1 queery that loader page 2) yes 1 sql to loader template=settings page and 1 sql to loader somesetting. ifs somesetting.feld is autojoinin then 1 sql for both. if u.cal eithers template=settings page agains or somesetting agains then alredy loadeded so no xtra sql unless u $pages->uncacheAll() whch clearys it all 3- may be. autojoinin can makes littel small faster but at cost of memry .use autojoinin only for.felds that u accessor on.evry load of $page. title good one to be.autojoinin ......most othrs not;;; body or images and most betters not autojoinin

Imo the most important part missing in conversations about one language vs. the other is context. Just using features for comparison is useful mostly to fanboys. One needs to look at existing knowledge, time to learn, amount of benefit from the learned language (short term and long term), team dynamics (hiring, on-boarding, finding devs already fluent), existing code, …. There's a reason there's so much PHP written for things objectively much simpler done in other languages – because all the above things often outweigh changing away from PHP. Like everything async/stateful (even just websockets) is a pain in the ass in php, because the common way to deploy php is stateless. Does that stop people from doing that with PHP? Nope, people take on a bunch of complexity to do it even with languages/runtimes out there much more suited to the task. Take the leap from webdev to ML and the context is completely different. Suddenly things like existing code don't exist anymore, ML is "new". ML needs to be learned anyway, so existing PHP knowledge is vain. Other people mostly use python for ML, so it makes sense to use them. Short term there's a clear benefit in moving to python for ML. The same should apply to green field projects, but what today is actually properly green field (including team knowledge and such).

If you have the time, never hurts to learn a new language. Python is very easy to pick up. You don't need to learn Django or use Python for web dev....there's lots of other stuff you can do with it.

I have never used MAMP but the following setup should work... Your MAMP htdocs folder (the one with wire inside), should have a structure like this. site site-blog site-another site-dev wire .htaccess composer.json CONTRIBUTING.md index.config.php index.php LICENSE.TXT README.md Note the index.config.php. Do you have that? Inside it reads: Your index.config.php (that you moved/copied from wire/index.config.php) <?php namespace ProcessWire; /** * ProcessWire multi-domain configuration file (optional) * * If used, this file should be copied/moved to the ProcessWire installation root directory. * * ProcessWire 3.x, Copyright 2016 by Ryan Cramer * https://processwire.com * */ if(!defined("PROCESSWIRE")) die(); /** * Multi-domain configuration: Optionally define alternate /site/ dirs according to host * * If used, this file should be placed in your web root and then edited as follows. * * This function returns an array that should be in the format where the array key * is the hostname (including domain) and the value is the /site/ directory you want to use. * This value must start with 'site-', i.e. 'site-domain' or 'site-something'. This is to * ensure that ProcessWire's htaccess file can recognize and protect files in that directory. * * Note that if your site may be accessed at either domain.com OR www.domain.com, then you'll * want to include entries for both, pointing to the same /site-domain/ directory. * * Each /site/ dir has it's own /site/config.php file that should be pointing to a separate * database. You shouldn't have two different /site/ dirs sharing the same database. * */ function ProcessWireHostSiteConfig() { return array( /* * Some Examples (you should remove/replace them if used). * Just note that the values must begin with 'site-'. * */ 'mydomainblog.com' => 'site-blog', 'www.mydomainblog.com' => 'site-blog', 'anotherdomain.com' => 'site-another', 'dev.mydomain.com' => 'site-dev', /* * Default for all others (typically /site/) * */ '*' => 'site', ); } Each site* will have its own site/config.php, with the correct credentials. ProcessWire will do the rest. Of course, you need all your domains working first, even locally. E.g. dev.mydomain.local, etc. in your hosts file.

You can find all the elements that are wider than the window by adding the code here to the console https://gist.github.com/cuth/c1ddf2b1ce2fb07e512a. One of those should be the cause for the scrollbar.

Thanks for setting this up! ? Of course this won't be a problem for everyone, but personally I avoid direct downloads. Here are a few reasons: With direct downloads I can't easily validate the package to make sure it is indeed the original one in case the server has been compromised or something along those lines — which of course is something that shouldn't happen, but in this regard I have more trust in GitHub than individual hosting providers / server maintainers. GitHub (/ Git) allows me to see and track the full change history in case something doesn't work. This way it's easier to track what change caused the problem, why it was made (commit message), and (assuming that the module author is somewhat active on GitHub) file an issue or even submit a fixed version for approval. Finally, I prefer to handle updates via either Git or Composer. It would be too much work to keep track of different blogs for individual modules, let alone download the module package every now and then to see if it has changed . GitHub makes this trivial (periodic git fetch or git pull is quite enough). No pressure, but big thumbs up from here for always uploading modules to GitHub ??

@HMCB Do you mean like the bookmarks feature in Lister? It doesn't have anything built in like that at present. However, the search queries are all query-string based (unlike Lister), so you can save the search queries on your own by copying the URL from the browser address bar, or using your browser bookmarks.