Leaderboard

Hey Ryan! Just a quick note that you may have a cache invalidation issue going on: visited the blog root a while ago, and the latest post was still the one from last week. Checked the latest entry (from last week), and kind of accidentally spotted that the "newest blog post" link actually pointed to another post. Publishing a blog post probably should invalidate the cache for the blog page? I've noticed similar issue with the sites directory (directory root is often updated much later), and in the past I've also had similar issues with the modules directory (though not sure if that's still an issue). Of course not a major problem, but it's a bit problematic in the case of things like new blog posts, where folks might want to get their hands on them as soon as possible ?

ProcessWire 3.0.131 adds support for partial/resumable downloads and http stream delivery, and contains several updates to our comments system, among other updates— https://processwire.com/blog/posts/pw-3.0.131/

News Update - 3 May 2019 - Part Two Class Padloper - Public API We have re-written the Padloper Class (Padloper.module) to server as proxy class for use as a public API for everything you need to do with Padloper (except rendering; we don't do that :-), see previous post). Think of ProcessWire $pages variable. This is something similar in that it allows you to interact with (retrieval and manipulation) with Padloper at a higher level. Rather than multiple methods from multiple classes such as $modules->get("PadCart")->someMethod() or $modules->get("PadCheckout)->anotherMethod(), you will only need to interact with one class, Padloper. This will hopefully streamline your development process. Most (maybe all) of the current modules will be "converted" to Padloper core classes (.php) and/or absorbed in other classes. This means less modules will be installed. With one class (proxy class but also with native methods) you won't need to know (but good if you did :-)), the names of the fields that Padloper will ship with. Your code could be as simple as this: // get the class $padloper = $modules->get("Padloper"); // find a limited number of products $products = $padloper->findProducts(); // find products matching a criteria $selector = "brand=toshiba,price>200"; $products = $padloper->findProducts($selector); $selector = "tags|categories~=Vane,type*=Jac,description~=Some text,images.count>3"; $products = $padloper->findProducts($selector); $selector = "inventory<=10,variant_option=size|colour,variant_option_value=red|black"; $products = $padloper->findProducts($selector); // find related products $related = $padloper->findRelatedProducts($product); // get current cart $cart = $padloper->getCart(); // add item to current cart $padloper->addCart($item); // import products $padloper->importProducts($imports);// array/json/csv // get an order $order = $padloper->getOrder($id); // export orders $padloper->exportOrders($selectedOrders); // etc for customers, discounts, downloads, categories, tags, brands, variants, reports, inventory, types, etc Note the short 'field names' in the selectors. For instance, there are no fields known as brand or tags or categories in Padloper (they have other names and/or are subfields) but Padloper will convert them into something ProcessWire will be happy with. Currently, we don't support Or:groups, sub-selector selectors and similar using the 'short-field-names-selectors' . For such, you would need to pass the the full names and subfields of the Padloper fields you want to query to findProducts(), etc. The Padloper Class is also useful for debugging your shop, producing reports using the API, etc.. We'll talk about this and more in future posts.

? Heya, success! This seems to be a reliable and resource-saving method to bring webp support to (existing) PW sites: .htaccess only 2.0 ? (subtitle: learning more about htaccess directives) When only calling webpUrl | webpSrc for all image sources, without any conditional markup, the whole site / page tries to get all images as webp files. $options = ["webpAdd" => true]; $img = $page->images->first()->size(120, 120, $options); echo "<img src='{$img->webpUrl}' alt='{$img->description}' />"; The new htaccess directives will check if the browser supports webp. If not, it redirects the webp requests to the jpeg or png variations. Also if the browser supports webp, but a webp file is not available (for what ever reason), the htaccess redirects to an existing jpeg or png file. So, it redirects, it does not only rewrite the URL. Look at this screenshot, the redirected request has the correct file extension: The new .htaccess directives: To support png too, we need to copy the block and change .jpg to .png, or there is a way to implement both types into one block. We will see. ?

This module (github) does with site/assets/files what Ryan's DatabaseBackups module does with the database: Backup site/assets Download ZIP archive Upload ZIP archive Restore site/assets Motivation: This module can be the missing part for projects with content backup responsibility on the client's side: The client will be able to download DB and assets/files snapshots through the backend without filesystem access, thus backing up all content themselves. Release state alpha – do not use in production environments. Credits for the nice UI go to @ryan – I reused most of it and some other code from the DatabaseBackups module.

This is AMAZINGGGGG! Great work. Excited to check this out is an understatement.

There‘s the $classLoader class in the core if you need to setup autoloading.

News Update - 3 May 2019 - Part One The little speckled fella has been very busy on the trail. Despite being the smallest of its kind, she has lofty dreams. We've been working on the API and the Products GUI. In the next post, I'll tell you more about the API. Products Features and GUI Though there are a few issues still pending (aren't there always? sigh), I am relatively pleased with the results. Of course, during beta testing we'll received and incorporate feedback as best as we can. Only UI-Kit theme will be officially supported. Multilingual fields if site is multilingual Ajax powered inputs for fast and convenient editing Four types of products Physical product requiring shipping Physical product not requiring shipping (for collection) Digital product Service/Event (etc) products - e.g. Swimming lessons, Consultancy services, Hotel booking, etc Product Classification (ajax powered) by: Type: e.g. Belt, trousers, etc Brand: Puma, Sanyo, whatever (editors can type in or import brand names + planning to support logos) Categories (aka Collections): Multiple categories, e.g. Men, Girls, Hospitality Tags: Multiple tags can be entered, e.g. sale, amazing, etc Product Variants (consists of an Option (e.g. Colour) and an Option Value (e.g. Red) Add zero or n variants as you wish Live preview as you build variants Each created product variant can be enabled/disabled. Devs can then decide to either show that variant as unavailable or not show them at all. That's up to you :-). Apart from classifications, shipping class, inventory policy, weight and dimensions units, title and description (and this latter one may change), almost all product properties will vary by variant if variants are used Product properties include: Images Colour (more on this below) Downloads (centralised and reusable) Price and Compare Price (aka former price) Inventory policy (whether to track or not) Charge taxes SKU (stock keeping unit) Inventory (quantity) Allow back orders (aka overselling) - @note: this can be set per variant. This is useful if one variant can be restocked faster than others Weight Length Width Height Weight Unit (mg, g, kg, oz, lb, t) Dimensions Unit (mm, cm, m, in, ft ) Shipping Class - can be used for product-based shipping if needed (e.g. bulky goods, light, fragile, small items, perishable, etc) Images (more on this below) Downloads (more on this below) Images Multiple images can be added to both a product and its variants (in case its has some). Images add to the product itself can be used with all variants Images added to a variant are tracked/tagged as belonging to only that variant In some cases, it may not make much sense to add different images for similar variants. For instance, a small red hat and a large red hat could probably share the same images. Although we do not currently support specifying an already uploaded image as belonging to a group of variants, this may change in the future Colour Similar to images, can be set at both product and its variants level Colour saved in RGBA format Downloads Also similar to images, can be populated for both both product and/or its variants Multiple files can be added to a product A file designated for 'whole' product will be available to download irrespective which variant of the product was purchased Conversely, a file or files saved for a variant will only be available to the buyer if they buy that variant of the product The above is useful if you want buyers to be able to download different files of the same product. For instance, recently someone needed to sell two versions of a font as part of one product. This is a solution for such cases. TODO List Lots! e.g. default settings for some properties, e.g. weight unit, shop currency, etc. For the frontend, we are creating a rich language-aware API that you can use to build your shop however you want. There will be no rendering of markup (but see first post in this thread about a separate fully functional frontend shop). In the next post, we talk a bit about the API. Before that, here are some screenshots and a video demo (if you can spare some 20 minutes away from watching, er..., cat videos? ?) Screenshots Video Demo Thanks ?

@Gadgetto Maybe you can check if there is any information in DB and use getDefaults() method as a fallback. https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/ModuleConfig.php#L60 Also, take a look at the description of the getDefaults method https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/ModuleConfig.php#L55

This has appeared several times in the forum already. This screenshot shows what + where you have to define the locale.

Thanks for the report on the progress you are making! I have a few observations and questions. I know that at this stage of development it is not top priority and hopefully things can be fine tuned later on, but I would like to mention that excessive usage of whitespace – i.e. uselessly big padding – is against good UX. The more one has to scroll up and down, the more tedious it becomes to work in the admin, especially on laptop screens. I made a quick mockup to show what I mean. I moved the action GUI bits in line with other action like features. I also marked areas where whitespace could be made smaller: My questions: Are you planning to utilize tabs (for example) on the Product page? Variants section is a good candidate to be separated under a tab, for example. Are we going to be able to add "custom" PW fields to products? I already have sites with product catalogues waiting for Padloper 2 to be added in order to implement shop features. However, all custom data should be kept somehow. For example, I use repeaters for simple variations and each repeater – among a few other fields – has an SKU and also an EAN-13 barcode field. Also, a product itself has various other fields, such as Option Select fields and page reference fields with ASM select. In the video, Inventory management seems to apply to the product and not its individual variations. Is that correct? What fieldtype will Padloper 2 use for prices? When supporting currencies, it is quite common that a product can have a price in the 10000.00 - 100000000.00 price range, which is not something PW's FieldtypeFloat can handle (maximum is 9999.99 with FieldtypeFloat). This is why this request is so popular https://github.com/processwire/processwire-requests/issues/126 but unfortunately the is no sign of Ryan adding it to the core ? Thanks in advance and keep up the good work!

http://blog.chriszacharias.com/a-conspiracy-to-kill-ie6

Thanks for sharing this, a wonderful and funny read that also brings up some sentimental points. And, coincidentally, I also read his article about quitting at YouTube which ends with My request to take six months off next year to go backpacking (thru-hiking) on the Pacific Crest Trail was approved a week ago. Didn't think it might be this valuable in my CV?

PageTableExtended Download here: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Extends the Processwire PageTable field for rendering table row layouts. This is great for editors, because they actually see at a glance what the table rows consist of. What it does Turns the Processwire Fieldtype "Page Table" from this: into something like this (sorting capabilities of course still functional): See it in action: Requirements FieldtypePageTable installed (part of the core since Processwire 2.4.10.) Templates used for PageTable need a file associated (otherwise nothing gets rendered) This render method is meant for sites where the PageTable templates only render part of the layout, not complete websites. But you also can define what will be rendered (see below). Options Render Layout instead of table rows Check this for seeing the rows rendered. You can easily turn off the complete functionality by unchecking this. Path to Stylesheet Since the parts are unstyled by default, it is a good idea to define styles for them. All rendered templates are encapsulated in a div with the class "renderedLayout" so you can style them with: div.renderedLayout h2{ color: green; } The path is to be set relative to your templates' folder. Reset Admin CSS Since the parts are rendered inside the Admin, common styles of the Admin Interface apply also to your layout parts. This is not a bad thing, because especially text styles are well integrated in your admin's theme. But if you like to override the admin styles in your table rows completely (more or less), just check this box. Don't forget to define a custom CSS then! Advanced Since this module is meant for parts of your layout you already have defined for your frontend templates, it is a good idea to use a preprocessor like Stylus, Sass or Less for building the custom CSS file. Just outsource your layout part definitions in an extra file, compile that in a separete CSS file and use this as custom CSS for this module. Since your CSS is should be built in a modular way, this works pretty well ;-) Will write a tutorial with a use case once finished testing. Notes: Github: https://github.com/MadeMyDay/PageTableExtended If you want to get rid of the unnecessary step for entering a title before editing the page, just set the "autoformat" value as suggested in the PageTable settings. If you don't want to use a title field at all, see this post from Soma Will put it in the module repository once finished testing. Please test it and give feedback. I haven't used GitHub for a long time, please check if everything is in place and if this will work with the modules manager and the new core module installer once added to the repository. Have fun Module is in the repository now: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Please use GitHub for instructions, I made some additions there.

Hello guys Though times. Hope this is ok to post here. I'm currently looking for a new job here in Switzerland. I have over 20 years of experience in web development. I'm specialised in front-end HTML5, CSS, JS and backend (PW of course). I also have strong visual design skills. If anyone has a tip or knows a good address, I would really appreciate it. Thanks in advance for any help you could provide. Soma

VSCode introduces Remote Development in the new Insiders Release! https://code.visualstudio.com/docs/remote/remote-overview Seems like they were watching our thread here closely ?

It's working here on Windows and IIS 8.5

OK. Let's arrange to have a chat, please, thanks.

Thanks for the quick reply with clarifications. Tabs could help either with "custom" fields or with "inventory dash table" too, as you could separate them from the main products edit page. Especially for custom fields, tabs based separation would be great and that way you might be able to separate the two worlds of Padloper 2's GUI from PW's inputfield type based GUI.

Does that mean that products are not going to be ProcessWire pages the same way as they were in Padloper 1? It was such a great integration and made it super easy to edit product templates. Or will they still be available in the Templates section in admin? Great progress, can't wait to test it out.

My favourite atm is to serve webp format in webp files and use the htaccess solution to detect missing browser support and then, as fallback, serve jpeg format in webp files. This false file types automatically will go away by time, as browser support becomes complete.

@BitPoet - enjoy the PCT - I have only done Tuolumne to Sonora Pass, but it was incredible. I am sure the entire thing will be an amazing experience!

This still seems to be the case in 2019... the files set in $config->prependTemplateFile and $config->appendTemplateFile must be in /site/templates/: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/PageRender.module#L362 If there's a way around this, I'd really like to know. Note: Regular template file locations can effectively be anywhere with the hook mentioned in this GitHub issue: https://github.com/processwire/processwire-requests/issues/204

Would you be able to briefly talk more about that here?

Thank you @Noboru, I will try this out. ? I am wondering: Can you even open WebP files in apps other than browsers without having the codec installed? As far as I know you cannot simply open a .webp file. After all it is meant for browers. But I haven't tried it much. In my opinion I would not serve WebP content in a .jpg or .png file. I would serve only WebP in a .webp file for browsers that support it. ?

This is the only disadvantage I see, but it might outweigh all the advantages. It works fine on my local docker environment. Nice ? I am moving servers, but I will check it out on a VPS but I won't see why it shouldn't work.

It's working great, i have it on about 20 fields now on 1 current/major project and this going to really make a world of difference in reducing support (calls/emails/trello cards)... I've noticed the more of these sorts of things i put in the admin (including stuff like Field Descriptions Extended, Context help for templates, and ProcessDocumentation), the more careful clients are to check before wasting my support resources...

Thanks, This is helpful.

Boom! Finally I've got Intelephense working as expected ? Before: After: Turns out that it is already available as setting in settings.json:

+1 over here

Update on the intelephense issue of core modules: https://github.com/processwire/processwire-issues/issues/860 The mentioned quickfix is to copy all .module files in a temp/hidden directory, eg /site/assets/.intelephense and add the .php file ending. It works: In my installation I have 139 .module files - quite a lot that is not indexed by Intelephense! Moving those files to a new folder when anything has changed would be quite easy. Intelephense would always be up to date with the current install (there could be custom modules in /site/modules as you can see in the screenshot). A custom module for this would be too much, I guess. I think that would fit great into @adrian 's TracyDebugger. What do you (and others) think? In the meantime I've filed an issue in their repo, you might give me support there: https://github.com/bmewburn/vscode-intelephense/issues/454

Best of luck on the job search, Soma! I hope you find a great place soon!

Hey reno, You can set your defaults like this. Just put it before your init(): protected static $configDefaults = array( "defaultSelector" => "default value here" ); /** * Data as used by the get/set functions * */ protected $data = array(); Add this line to your inputfield: $field->attr('value', $data["defaultSelector"]); And add the following at the top of your static public function getModuleConfigInputfields(array $data) {: foreach(self::$configDefaults as $key => $value) { if(!isset($data[$key]) || $data[$key]=='') $data[$key] = $value; } You can then access this throughout your module using: $this->defaultSelector; At least that is how I have been doing it - maybe someone else has something cleaner Does that make sense? PS, Sorry for all the consecutive edits. I really shouldn't try to offer device when I am busy with other things and rushing EDIT Again - I just read that tutorial you pointed to and I see if uses: public function __construct() to set the default values. I haven't used that before. I guess I started by copying from other modules and never came across that approach. I guess there are a few different options, but construct does seem cleaner.