Leaderboard

Hi guys! Padloper is officially released today: https://www.padloper.pw All of you who did purchase it during beta: your license has been upgraded into developer license - big thanks for all the feedback I have got. You can download the latest version from your order confirmation email. If you don't have it anymore, please contact me. Most significant late addition was shipping classes - now it is possible to define different shipping rates based on country/state and/or per product. I have also added tutorial how to use PageTables to handle product variations. PS: there is nice release sale going on. Single site license is 50€ and developer license only 120€.

Quite correct - the user has indeed begun to irritate me (and others, I'm sure). Fact of the matter is that the user signed up, started posting things all over the place about whether or not PW should be used - yet this discussion has been had so many times before. There are indeed signs that the user has tried PW, but not enough signs indicating that he/she read the docs. For me, this is meant to be a high-quality discussion and support forum and, as such, I agree with the encoding of his two posts (which are exactly the same, for those who did not notice). </thread>

I don't think anyone would disagree with that but that's not what cssabc123 expressed in his post, which actually started with "Drupal is better than PW". Of course each is entitled to his/her own opinion, no problem, but when almost all of ones forum activity up until now consists of subtle or less than subtle trolling attempts there will be a time when people are fed up with it. Especially when there are no apparent signs of actually having tried PW, read some docs etc.

Not a module, just a little function for applying effects to images if you have the Imagick PHP extension installed. This started out as a need to blur an image and then I expanded it to accept more of the Imagick methods. Not all Imagick methods are supported. The function takes the URL to a source image, the name of an Imagick method and an array of arguments for that method, and returns the URL to the processed image. The processed image is saved to same directory as the source image, with the method name and arguments appended to the name of the source image. Images are cached in that the function checks if an image with that name/method/arguments exists already to save recreating it on every page load. function imagickal($imagePath, $method, array $arguments) { $path_parts = pathinfo($imagePath); $dirname = $path_parts['dirname'] . '/'; $filename = $path_parts['filename']; $mod = $method . '-' . implode($arguments, '-'); $mod = wire('sanitizer')->filename($mod, true); $savename = $dirname . $filename . '_' . $mod . '.jpg'; if (!file_exists($_SERVER['DOCUMENT_ROOT'] . $savename)) { $image = new Imagick($_SERVER['DOCUMENT_ROOT'] . $imagePath); call_user_func_array([$image, $method], $arguments); $image->writeImage($_SERVER['DOCUMENT_ROOT'] . $savename); } return $savename; } I'm a PHP novice so happy to receive suggestions of how this could be improved. Imagick reference: http://php.net/manual/en/class.imagick.php Examples of some effects possibilities...

This could done via a "album" type of image field that used for uploading a bunch of images and this images are saved under this parent page as single image pages... https://github.com/mr-fan/AutoImagePages (based on a gist from Adrian https://processwire.com/talk/topic/8698-creating-page-for-every-image-uploaded/#entry84012 ) some more reading starts here: https://processwire.com/talk/topic/8698-creating-page-for-every-image-uploaded/page-2#entry84465 honour goes to Adrian while he has put the main things together and helped me to polish it a bit. Best regards mr-fan

I like your post and what you have said. But here, the situation seems to be a bit difficult. Have you read the more than 50 posts that the cssabc123 user has posted here in the last 5 days? I remember moments when I came to the forums and have had a look to the "Recent Posts" Box that was full with only his posts. I understand this box as a way to get quick recognition, what is useful for new announcements or people who need "emergency" help. I can't remember a time where only one person has flooded it completly alone. (And there were times where I was online every day here)

Yes I have looked at it with a narrowed view. I should have googled about Imagick PHP before I did my post. Just because I never had the need for something like this doesn't mean there is no need for it.

@horst That sounds definitely clumpsy. What about some buttons in the page editor? Put this as is in /site/ready.php: $wire->addHookAfter("ProcessPageEdit::buildForm", function(HookEvent $event){ $process = $event->object; $form = $event->return; $page = $process->getPage(); // Update to fit your fieldnames $imageFields = array("images"); $multiple = $page->fields->find("name=" . implode($imageFields))->count() > 1; foreach ($imageFields as $field) { if($page->fields->has($field) && $page->editable($field)){ if(wire('input')->post("hook_sort_$field")){ $page->of(false); $page->set($field, $page->get($field)->sort("basename")); $page->save($field); } $button = wire('modules')->get("InputfieldSubmit"); $button->attr("id+name", "hook_sort_$field"); $button->value = __("Bilder Sortieren"); $button->value .= ($multiple ? " (" . $field->get("label|name") . ")" : ""); $button->icon = "sort-alpha-asc"; $button->addClass("ui-priority-secondary"); $form->insertBefore($button, $form->get("id")); } } });

Incidentally, when I set out to achieve a blurred image effect I initially thought I would do it client-side. Each client-side option I tried had issues: CSS filter - not supported in IE SVG filter - blur effect noticeably less smooth JS stackblur plugins - difficult to use as a CSS background image supporting background position and background size properties In the end it was so much easier to do it server-side, and browser support is 100%. Edit: for those interested in client-side image manipulation, CamanJS is pretty cool. It's an absolute breeze to use on inline images using the "data-caman" attribute, just a bit of a hassle to use it for CSS backgrounds.

@LostKobrakai This is awsome! Thanks so much for this piece of code. I still have to learn a lot till I can do this on my own. Works like a charm ... I only had to update my PW from master 2.6.1 to the dev branch (Use of ready.php requires at least PW 2.6.7 I guess). The module code you helped me with in your first answer would probably do, but adding an extra button is of course much nicer. @horst Thank you very much for your code as well. I'll take it to study how things work in PW. Maybe it helps me with other tasks later on ... Again ... Thanks to both of you.

Sorry for being a bit hasty there! The module seemed mature enough to be mentioned, and I've personally found that often good stuff gets buried for way too long just because it's not "fully polished" yet. Early announcement combined with a little warning tends to work out just fine.. and it does also have the added benefit of getting feedback at a stage where making changes doesn't necessarily mean hours and hours work being wasted

Slightly unrelated, but for knowing more about Patreon, this talk from Jack Conte is great Before watching that, I didn't even know that he was behind Patreon, although I was following his music and videos on Youtube

Absolutely no apology necessary - I am honored that you featured it and completely agree that early attention and testing is a great benefit to myself and any potential users, so thank you for including it and for PW weekly and everything else you do for PW!

I thought I had better make some improvements after teppo's very generous, but slightly premature publicity in PW weekly this morning I really wanted the images working better, so you can now specify how many images to randomly generate. Also, images are now cached so even though the first view of a page may be a little slow (while images are grabbed), subsequents loads will be as fast as normal. I will be plugging away at this module as I find inspiration for new fieldtype support, and snippets of time when procrastinating, but please let me know if you have any specific requirements for auto content generation.

Why is the first post absolutely unrelated with the topic title?

For the record, I originally managed to miss the post from Patreon where they announced the hacking. It's actually a pretty good one: seems honest, and they're not just apologizing, they're also explaining how they're going to prevent the same from happening again. In essence this is a good reminder to never keep dev stuff publicly available

Hi, I have uploaded a new version to Github that fully supports PW 2.6+ with its new naming scheme. The package now ships with two Pim versions, the older one, called Pim, that can be used until PW 2.5 stable, and the new one, Pim2 that should be used with PW 2.6+ So, if you start a new site with PW 2.6+, simply install Pim2 only! If you have upgraded PW to 2.6 on an existing site with lots of image variations, you should install Pim2 additionally to the older one, (do not uninstall it yet!) then you should start to change your API calls in your templates like the following explanation . here is a code line from the older Pim: $image = $image->pimLoad($prefix)->watermarkText($txt, 75)->setQuality(80)->pimSave(); . To start with smooth change from Pim to Pim2, you can change it to this: // use the old Pim to remove the PimVariations with old naming scheme: $image->pimLoad($prefix)->removePimVariations(); // in the copied original code line, only change pimLoad to pim2Load, note the number 2 ! in the new start method ! $image = $image->pim2Load($prefix)->watermarkText($txt, 75)->setQuality(80)->pimSave(); . This way you have some control on which parts the new creation may take effect, e.g. on a small site you can change all API calls at once and drop caches if exists. On bigger sites you may start at one template / page first, and add more changes later. . Regardless of this, you can safely let the call to the older removePimVariations() method stay in your code for a while, as they do not interact with the newer one. After a while, when you do not see any of those old filenames in your assets/files folders, you can remove those lines from your code and also uninstall the older Pim. All other methods than pimLoad / pim2Load are completly identical and can be seen here in the API

To create a sitemap.xml you can use Pete's Sitemap XML module, or you can create a template file and page to do it for you. This post explains how to create a template to do it for you. The benefit here is that you may find it simpler to tweak a template file than a module, though either is a good solution. Here is how to do it with a template file and a page: sitemap-xml.php <?php namespace ProcessWire; /** * ProcessWire Template to power a sitemap.xml * * 1. Copy this file to /site/templates/sitemap-xml.php * 2. Add the new template from the admin. * Under the "URLs" section, set it to NOT use trailing slashes. * 3. Create a new page at the root level, use your sitemap-xml template * and name the page "sitemap.xml". * * Note: hidden pages (and their children) are excluded from the sitemap. * If you have hidden pages that you want to be included, you can do so * by specifying the ID or path to them in an array sent to the * renderSiteMapXML() method at the bottom of this file. For instance: * * echo renderSiteMapXML(array('/hidden/page/', '/another/hidden/page/')); * */ function renderSitemapPage(Page $page) { return "\n<url>" . "\n\t<loc>" . $page->httpUrl . "</loc>" . "\n\t<lastmod>" . date("Y-m-d", $page->modified) . "</lastmod>" . "\n</url>"; } function renderSitemapChildren(Page $page) { $out = ''; $newParents = new PageArray(); $children = $page->children; foreach($children as $child) { $out .= renderSitemapPage($child); if($child->numChildren) $newParents->add($child); else wire('pages')->uncache($child); } foreach($newParents as $newParent) { $out .= renderSitemapChildren($newParent); wire('pages')->uncache($newParent); } return $out; } function renderSitemapXML(array $paths = array()) { $out = '<?xml version="1.0" encoding="UTF-8"?>' . "\n" . '<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">'; array_unshift($paths, '/'); // prepend homepage foreach($paths as $path) { $page = wire('pages')->get($path); if(!$page->id) continue; $out .= renderSitemapPage($page); if($page->numChildren) $out .= renderSitemapChildren($page); } $out .= "\n</urlset>"; return $out; } header("Content-Type: text/xml"); echo renderSitemapXML(); // If you want to include other hidden pages: // echo renderSitemapXML(array('/path/to/hidden/page/'));

I'm unable to find out how to hook the process of creating image variations. I would like to use resmush api to optimize images. I'm using the service successfully on adding images using $this->addHookBefore('InputfieldFile::fileAdded', $this, 'optimizeImage_InputfieldFile'); and I also added a new optimize() method to image fields that can be used like this: $page->image->size(100,100)->optimize()->url But it would be nice if it could be fully automatic. That is: optimize on upload - DONE optimize on request - DONE optimize automatically if new image size is requested (eg. changing from size(100,100) to size(480,200)) - FAIL ImageSizer::resize seemed the right one but it returns only "true" and I can get only the image file name in the cache dir. What I would need is the final image path and final image url. Any thoughts on this?

this piece from adobe...is some sort of mini photoshop on every webapp working (even simple websites) https://www.aviary.com/ https://developers.aviary.com/docs/web it is used within this imagemanager plugin for CKE/Tiny/HTML and looks great for such fast/little image edits. http://www.responsivefilemanager.com/ (It's on the third slide i think) and this module i've tested sometimes ago and works even great, too https://processwire.com/talk/topic/1703-pixlreditor/ This are all only solutions where the user/editor has the role to use them - your snippet provide the force to preset effects by the admin/developer...so everything has it's own benefits. regards mr-fan

$resizer = $event->object; $filename = $resizer->filename;

I don't see the connection here either. The whole point of server-side image processing is to a) automate things so that you don't need to perform them manually on image-by-image basis and b) make these kinds of things possible for users with no access to software or know-how needed to do image processing themselves.

The main difference is behind the scenes: Moderators are more privileged than PW-moderators. I do agree that the naming could be better, though

Haha, I only just noticed that. (Methinks troll.)

Why would you encode his post? I personally have to agree with him(cssabc123). It depends on the project's needs when you decide a framework to work with. Whether it is Drupal or PW or Joomla depending on the project, one is more suited than the other. I personally think it's disrespect to encode another person's post, when it's their own opinions to discuss a topic openly and freely.

The ready.php is so nice. No more tons of mini modules just to enhance the admin.

I just never use system resources, but either mamp or a vm. It's just so much more portable and resistant to changes on the host system.

I think replacing files is quicker than enabling multi-language, but in the end it doesn't really matter. The result will most likely be the same.

Quite frankly, i am starting to get annoyed with your posts. I get the impression that all you do is start threads, or digg up old ones, with the sole intention of trolling around. I suggest you stop this.

I want to note, that the default PHP on macs is really default. I always feel better when PHP is installed with the installer from: http://php-osx.liip.ch/

Thank you Kongondo & @Valan for this great little helper! For me as a non real dev...it is much more easy to get some special admin magic working with this! This is one of the real big things i like with PW - there are tools that helps and can used by non experienced PHP users without to force them to do risky things within the backend...in other systems the level of complexity always grows and grows...with PW it seems it always get easier I'm on a hard deadline this days so less time to contribute but this little snippet may helps others - easy to use and very helpful. It works as a kind of shortcut navigation to prev next siblings - like Kongondo showed off in his video to the notorious V.P.S. I saw the raw links and thought hey i've a version of this running with UI buttons so here we go: $out =''; $siblings = $page->siblings; //generate next & prev links output if (count($siblings)) { $prev = $siblings->getPrev($page); if ($prev) { $out .= '<a href="'.$prev->editUrl.'">'; $out .= '<button type="button" name="button" class="ui-button ui-widget ui-corner-all ui-state-default">'; $out .= '<span class="ui-button-text"><i class="fa fa-angle-double-left"></i> '.$prev->title.'</span></button>'; $out .= '</a>'; } $next = $siblings->getNext($page); if ($next) { $out .= '<a href="'.$next->editUrl.'">'; $out .= '<button type="button" name="button" class="ui-button ui-widget ui-corner-all ui-state-default">'; $out .= '<span class="ui-button-text">'.$next->title.' <i class="fa fa-angle-double-right"></i></span></button>'; $out .= '</a>'; } if ($out <> "") $out = "<div class='NextPrevLinks'>".$out."</div>"; return "<div class='NextPrevLinks'>".$out."</div>"; } Output of the field is: Have fun and best regards mr-fan

I haven't spent a lot of time at tutsplus, but get the impression the article is not consistent with what you guys expect from them. Maybe they are just testing the waters to see if there's any interest before investing more time into it? But the article should not have been titled "Introduction to ProcessWire", it should have instead been "A quick look at ProcessWire from a WordPress perspective" – I think the article would have been just fine with that as the title. What I do know about tutsplus.com is that it says Envato on it – a business that largely exists because of WordPress (?). So I'm not entirely surprised by the content of the article. If the choice is them writing something or nothing, I'll take something. The article left me with these impressions: If I'm a WordPress user that doesn't know anything about code, I'm probably not going to look at PW after reading this. But if I'm a full time, or hobbyist web developer that uses WordPress, this article is probably going to make me take a closer look at PW. From that perspective, it's alright. Maybe the article is lacking relative to what it could have been, but we are still better off with this article than without it. The article had a lot more good to say about PW than it did bad. I just hope that they follow through with Tweeting it to their half a million followers, which they've not done yet–we could really benefit from that. Yes there are a lot of Tweets about the article, but looks to be mostly just low-follower bots, and we haven't seen any real increase in traffic here from that. There wasn't a lot of blatantly inaccurate stuff like in that other WordPress-centric article from a year or two ago. I've only read it once so far, but the only thing that made me cringe was the word "mature" in quote "ProcessWire, and its lack of a mature theming model...", which I think is not the right choice of words because there is no theming modal by design, and that is one of the points of ProcessWire. The correct thing to say would have been "If you want to create a website without any development, use a ready-to-go theme with WordPress. If you want to develop a website and have control over the output, use ProcessWire." Hopefully they are just testing the waters and will publish a real introduction to ProcessWire… one where we can tell they've actually downloaded and installed it, and taken the time to learn a little and develop something in it. Or what they should probably do is hire someone like @teppokoivula to write an article for them… someone that already knows ProcessWire well, and knows how to communicate that.

I prefer to use PHP variables whenever possible. But there are some cases where it wouldn't be applicable or possible, like with a call to WireArray::implode(), etc. If there's an instance where you need to supply an output format (like with markup) before the variables are known/available, then the only way to do it is to {tag} it with placeholders. This is useful when providing an output format for something ahead of time that's going to be repeated over many times. For instance, the supporting markup for PW's Inputfield forms is generated in this manner, so that a module or core can specify the output format without having to get involved in the runtime rendering of the form. But it's not really a question of which strategy you should use, because most of the places where we support {tags} using variables isn't a possible alternative.

Crosslink to a interesting categorising post for products with extra options for pagefields: https://processwire.com/talk/topic/10306-product-catalog-with-a-twist/#entry97847 (i like to keep such really good examples organized together somehow...) regards mr-fan

Hi @paulbrause, Lots of great suggestions above regarding PageTable fields etc, but I just put together a quick module that I think does exactly what you are looking for. https://gist.github.com/adrianbj/2b3b6b40f64a816d397f To make it work as is, you will need these: Templates: album (for the album parent pages) image (used for the automatically created child pages) Fields: images (for the album template) image (for the image template)

I just looked into this again and there's no argument for removeAll() just for remove($key). See here in source https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/core/WireArray.php#L790 removeAll() removes ALL pages from a Wire/PageArray (pages, images, POST vars etc). So I'm not sure about why it works for you because it shouldn't and also doesn't work for me. Assuming user_app is a page field allowing multiple pages to be selected. It's a WireArray/PageArray and you add pages to it like this from API: $user->of(false); $page1 = $pages->get("/somepage/"); $page2 = $pages->get("/someotherpage/"); $user->user_app->add($page1); $user->user_app->add($page2); $user->save(); Now we got 2 pages added to the page field. If you now do a $page->user_app->removeAll($page1) they all get removed so does $user->user_app->removeAll(); But if you do: $page2 = $pages->get("/someotherpage/"); $user->user_app->remove($page2); $user->of(false); $user->save(); Now only the $page2 which is in the array gets removed. It works all as expected and make sense.

Sorry about that, I went back and forth on the name a couple times and ultimately entered the wrong class name in the modules directory. It should have been TextformatterHannaCode, not ProcessHannaCode. I have corrected that. I was throwing an exception when I shouldn't have. I'm pushing a correction for this. Technically they are part of the same program "Hanna Code", even if that program has two modules. But I know what you mean. I'm adding "(Process)" to the Process one, just so that the two next to each other can be differentiated. Also, one more section I just added to the README: Using Hanna Code from the API If you want to populate Hanna Code from the API, you can do so using the render() method, like this: $hanna = $modules->get('TextformatterHannaCode'); $page->body = $hanna->render($page->body);