Leaderboard

This week we've got a demo setup of the admin theme framework that's been written about in the last two weeks of posts. Read all about it here and try it out from our demo site– https://processwire.com/blog/posts/demo-of-admin-theme-framework/

For our in-house printing house Leitz Medien we have build a small landing page to feature their qualifications. The website has as background multiple illustrations, which are sorted randomly on every page load. The layout uses Masonry and the paths of the illustrations are animated using vivus.js. You can access every modal under its own Url, which are added to the browser history using the replaceState method. www.leitzmedien.com Modules used: ProCache Markup Sitemap XML Email Obfuscation (EMO) Tracy Debugger Regards, Andreas

Thanks Ryan. Very good progress on this! Can't wait to see what the communities front dev pros can show us how to use it / what all can be done with it, now that you have opened it for easy configuration.

@mikeuk, Sorry that you had problems with ProcessWire. We are glad that you have taken the time to try out ProcessWire. Hopefully you will hang in there and will stick with this vibrant community. Numerous members are extremely helpful and go out of their way to help people with their particular problems. I believe anyone can learn from this community and we also would benefit from your future contributions. It can be extremely difficult when things don't quite work out as you had planned. Fortunately, we all learn from these disasters. The important thing is that our community will always be there to help troubleshoot or explain how things work. I believe with time, you will look back and be very pleased that you hung in there with us.

There's a typo in the source. In the line in question, "$button" is missing one "t" (and $buton is of course undefined). This has already been fixed in the development version. Meanwhile, you could add the missing "t" by hand and not worry about updates since the fix will be in the next stable release.

Never done it myself, but I know it's possible to decouple the image processing and keep the goodies on an API for manipulation, similar to PW's. You can take a look at Cloudinary feature to upload an image by its URL. Also, there's IMGIX .

Yes, correct on both. One advantage of the Connect Page Fields module is that it can make the generation of your tags page more efficient. How much so depends on what you want to show on the tags page. To explain... For a page like the screenshot from @Sérgio, with a count next to each tag link, the typical way using only common API methods would be something like: $tags = $pages->find("template=tag, sort=title"); foreach($tags as $tag) { $count = $pages->count("tags=$tag"); // count how many pages have this tag selected // now output the tag link and count } And if you happened to want to list the articles that use each tag underneath that tag you would do something like: $tags = $pages->find("template=tag, sort=title"); foreach($tags as $tag) { $tagged_pages = $pages->find("tags=$tag"); // find pages that have this tag selected // now output the tag and the list of pages } A $pages->count() has less overhead than a $pages->find(), but it's still a lot of DB queries if you have a lot of tags. You'd probably want to cache this if you did it this way. With Connect Page Fields, the pages that use the tag are stored in a Page field so you can easily get a count or the pages themselves directly: $tags = $pages->find("template=tag, sort=title"); foreach($tags as $tag) { // you probably wouldn't bother assigning these to variables but just for demonstration $count = $tag->articles->count(); $tagged_pages = $tag->articles; // output your tag, count, etc } And for one more option involving a single SQL query on the tags table see this:

More: http://gizmodo.com/cloudbleed-password-memory-leak-cloudflare-1792709635

Hey @tpr - I have made an initial (although took much longer than I thought) start on support multi-language in Edit mode. Keep in mind that this is not designed to make it possible to edit all languages at once, but rather add proper support for editing the title and name for the user's current language. Here you can see the same set of child pages in Portuguese and then the default English. The keys things are: When viewing a non-default language the Title and Name columns have the current language in parentheses. Title is left blank for the current language if no language-specific version is available (uses "Placeholder" to show default language title). Name is left blank for the current language if no language-specific version is available. If you have the BCE "Overwrite Names" setting checked, the name for the current language will be created/updated to match the entered title. If you edit the page in a modal and save, the title and name for the current language will populate the edit mode interface instantly when modal is closed. Unrelated to multi-language, but there is now a new "edit in normal mode" icon - sometimes I prefer this to modal and think a link from here is nice. I am going to attach the new version here for the moment - please let me know if everything works as expected for you. Portuguese Default: English BatchChildEditor.zip

PageTableExtraActions A module for ProcessWire CMS/CMF. Allows PageTable items to be published/unpublished and hidden/unhidden directly from the inputfield. Usage Install the PageTableExtraActions module. Use the icons in the "Actions" column of a PageTable field to publish/unpublish or hide/unhide an item. https://modules.processwire.com/modules/page-table-extra-actions/ https://github.com/Toutouwai/PageTableExtraActions/

Hey Ivan, I think Ryan was just mentioning me in that post because I've worked heavily on the admin before (Admin Theme Reno), and because I've expressed interest in contributing to this next phase. I don't expect my ideas to carry any more weight than anyone else in the community that wants to contribute. I'm sure @ryan will have ideas for how ideas are vetted and integrated. I'm just excited that the admin will be easier to theme, and from the looks of it more configurable all around.

Looks like the problem arises in the profileImport section. Try to ramp up logging in php.ini and/or look in the server error log to see what's going wrong.

The major difference for me is the how detailed it is for me to write Twig Extensions, especially in OOP manner asides that they are quite similar.

Thanks - all seem to work fine here. I feel the empty "name" column for non-default language is a bit misleading, perhaps adding the default name there in grey would be less confusing? Now it looks like there's no name provided (which can't be as it's required). Plus this way you don't know the page name. The new edit mode for me is not very helpful because I can open the modal link in a new tab with middle-click. But of course it can be handy for others. Btw, what about displaying the "Active" state of pages in multilanguage installs?

No. The default behaviour is slightly different. Under the following conditions the file is not accessible: $config->pagefileSecure is set to true Page::status >= 2048 (unpubished) User is not logged in OR has not page-view permission for this page (template) Currently, Processwire does not meet your needs and provides Pagefiles if the status is appropriate for the current user and the user has page-view permission. The function Page::isPublic() does not change the status of the page it returns false if the the status is >= 2048. This function is used by PagefilesManager and ProcessPageView. It is a kind of bridge between the status and these classes. ProcessPageView::sendFile() is meant to go around the .htaccess protection anyway to provide the files in the backend. The function is not called if you can access the file via Apache. It will be called only if a secured file path is detected. Perhaps it would be useful if ProcessPageView::sendFile() checks whether the file is requested by the admin template or by the frontend. As far as I can see there is no reason against the following changings. You maybe want to post an issue on github. /** * Passthru a file for a non-public page to make it visible in the backend * * If the page is public, then it just does a 301 redirect to the file. * */ protected function ___sendFile($page, $basename) { $err = 'File not found'; // use the static hasPath first to make sure this page actually has a files directory // this ensures one isn't automatically created when we call $page->filesManager->path below if(!PagefilesManager::hasPath($page)) throw new Wire404Exception($err); $filename = $page->filesManager->path() . $basename; if(!is_file($filename)) throw new Wire404Exception($err); if($page->isPublic()) { // deprecated, only necessary for method 2 in checkRequestFile $this->wire('session')->redirect($page->filesManager->url() . $basename); } else if ($this->wire('page')->template == 'admin') { $options = array('exit' => false); wireSendFile($filename, $options); } else throw new Wire404Exception($err); }

@j00st, you might like to take a look at the Connect Page Fields module: Once the module is installed it takes care of keeping the fields in sync but if you already have your articles(?) tagged you would write some API code for a one-time operation to iterate over your article pages and add them to the selected tag pages.

Thanks very much, Kixe. Good call on the before hook. Maybe you can help me better my own understanding of the situation... I guess I am still not understanding a piece of the puzzle here. Consider the following: $config->pagefileSecure is set to true Page::isPublic() returns false User is not logged in If all 3 of the above are true, the file should not be directly accessible... correct? This is how PW behaves normally, with no need to hook ProcessPageView::sendFile(). Yet when all of the above is true except that Page::isPublic() was modified by a hook, suddenly it doesn't work as expected. There must be some other requirement that isn't being met, since this functionality doesn't normally require hooking sendFile(). See what I'm getting at?

plus DataTables are so easy to setup on the front end, you really don't need a module... just make your table, and then load the datatables scripts and init; the instructions are all there on the datatables site, and it is really well documented..

This looks really nice! I agree having the page as context is a smart move! Hadn't thought of the problems of having that represented at field level. I also REALLY like the idea of variations existing on its own as presets somewhere else. Something that I see solved nicely and horrible at the same time, is Shopify's very own variation editor is batch edition of prices and variation names. Eg. Select a variation by one of its properties and change the price in a batch table mode. This was done pretty nicely in an Excel like fashion, or multi checkbox select and command in menu. What I did suffered was making a soccer uniform shop with 10+ sizes and sometimes 20+ variations in color. An error in creating the names would imply to REDO all the variations, or go through a menu to edit EACH variations name. Always almost easier to recreate the whole thing. It seemed as if after creating the list of variations per property in a nice interface, they all lost the relationship amongst them. So if you had written Brgundy / Dark Blue, get ready to edit +50 fields in modals or just delete the whole thing. There goes your day! And the variations problem reveals a flaw in Shopify's service, no more than 100 product variations. Why I might guess won't be a problem for PW. I think variations images would also be quite the deal! Nothing more to add, just personal experiences of suffering from product variations. Hope to see this released!

Hi @j00st, do you mean something link the screenshot below?

What is causing you difficulty exactly? Another example with a few more comments: $table = $fields->get('tags')->getTable(); // enter the name of your "tags" Page field $query = $database->query("SELECT data FROM $table"); $ids = $query->fetchAll(PDO::FETCH_COLUMN); $count_values = array_count_values($ids); // count the frequency of values in the array arsort($count_values); // sort highest to lowest $count_values = array_slice($count_values, 0, 10, true); // we only want the top 10 tags // use the pages IDs and counts as needed, for example: foreach($count_values as $key => $value) { $p = $pages->get($key); // output whatever you want using $p (Page object) and $value (number of times tag is selected) echo "<p><a href='/search/?tag={$p->name}'>{$p->title}</a> (selected in $value pages)</p>"; } And in your search template you could do something like: $tag = $sanitizer->name($input->get->tag); if($tag) { $results = $pages->find("tags.name=$tag"); // output your results for pages with this tag }

Well, that depends... If you have a domain for the site or create a subdomain for the site, then we are talking about two different situations. For example in the case of a standard cPanel only account: say you have dev.example.com and want to install ProcessWire in /public_html/dev_example, in that case the default .htaccess file just does its job fine. However, when I moved the "main" site – which runs under the domain the cPanel account is tied to – to a subdirectory, only these rules did the trick for me: RewriteCond %{HTTP_HOST} ^(www.)?szabesz\.hu$ RewriteCond %{THE_REQUEST} \s/+szabesz_hu/(\S*)\s [NC] RewriteRule ^ /%1 [R=302,L,NE] Where szabesz.hu is my site, szabesz_hu is the subdirectory. I inserted this before the line RewriteCond %{REQUEST_FILENAME} !-f Also $config->urls->root = '/'; must probably be present in /site/config.php to get page()->url return the url segments without the subfolder being part of it, more on this: https://processwire.com/api/ref/page/url/ Nothing else I found in the forum or in the docs worked in my case. And there are other situations as well, but I just wanted to point out this one, since I had to google around to solve it. Your scenario can be different though, so you might want to provide some information about what you exactly want to solve .

This jQuery plugin seems to do the job without any obvious performance issues: http://laertejjunior.github.io/freezeheader/

I think you can do this with core PW fields, and enhance it with some custom JS if you want. Here's what I'm thinking... You have your Place pages in their own branch of the tree. The Place template has a repeater field "Offers" where all the possible offers for that Place are defined. Then you have a repeater field "Places" on your Partner template. You add two Page Reference fields to the repeater: 1. "Place", which is a single select field limited to the Place template. 2. "Choose offers" which is a multiple AsmSelect field using a "Custom PHP code" hook. The hook will return the value of the "Offers" repeater field (which will be a PageArray) for the place that is selected in the "Place" field. Now this hook is a bit trickier than normal because your Page Reference fields are inside a repeater and so you don't want $page to be the page being edited, but rather the repeater page that contains your fields. So in the hook you need to get the inputfield name and extract the ID integer portion of it and use that to get the $page object. I can explain more about this if you decide to go down this road. So this approach should work but it will require editors to save the page after choosing a place in the "Place" select, before they can choose offers for that place. If you wanted to enhance it a bit more you could have the "Choose offers" field allow all offers pages (limit using the Offers repeater template rather than a custom PHP hook) and then use some custom JS in admin to empty the inputfield options on load and on change of the "Place" select it gets the offers for that place via AJAX and populates the "Choose offers" options.