Leaderboard

ProcessWire 3.0.125 has several useful new $sanitizer methods and options, as well as new ways to access them directly from the $input API variable. This makes dealing with user input even easier than it was before. This version also brings updates to our translation functions and improvements to our API documentation: https://processwire.com/blog/posts/pw-3.0.125/

You might want to look into that Extra Allowed Content setting in your textarea field. You can change settings accordingly to the CKEditor docs. So something like this could already do the trick: // from the docs // A rule accepting <p> and <h1> elements with all their attributes. p h1[*] // change it to p h1 h2 h3 h4 h5 h6 ul ol li img[*]

Well set() sets a property to the data property which is PW specific. I think it's mostly used to make it distinct data for a module or object and set data to a WireData module which is used to save data to DB like module/class configurations, change tracking etc. Defining a property directly in the class body makes it just a normal class property which PW doesn't threat special and it won't be in the data array. protected $foo = "bar"; // standard class property - and then set foo using set() $this->set("foo", "baz"); // set data array only $this->foo = "bar2"; // set the class property - You'll end with two "foo" which are not the same $this->foo // bar2 $this->get("foo") // baz (from data array) But If you don't set a class property and only use data array or set(key, value) to define a PW data property $this->set("foo" , "bar"); $this->foo = "bar2"; is the same "foo" Just look a the WireData class

Found this today: Wild, weird and out there, it's a big bonus to making PW sites more accessible... https://websitevoice.com/ Talk to me ProcessWire ?

Definetly a typo here, but is it a missing "t" or a missing "y"? ?

What does autojoin do? Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. What sites should use autojoin? Autojoin is most applicable with larger sites. On smaller sites, there may be no benefit to using it or not using it. But it's good to know what it's for regardless. Where do you control autojoin? Autojoin is controlled per-field. You can turn it on by editing each field under Setup > Fields > [your field], and you'll see it under the 'Advanced' heading. When should you use autojoin? Autojoin causes the field's data to be loaded automatically with the page, whether you use it or not. This is an optimization for fields that you know will be used most of the time. Fields having their data loaded with the page can increase performance because ProcessWire grabs that data in the same query that it grabs the Page. Autojoin is a benefit for fields that are always used with the Page. This is best explained by an example. Lets say that you have a template for individual news stories called news_story. The news_story template has these fields: title date summary body sidebar We'll assume that when you view a page using the news_story template, all of the fields above are displayed. Fields that should have autojoin ON: Now consider a separate news_index template that displays ALL of the news stories together and links to them. But it only displays these fields from each news story: title* date summary In this case, the 3 fields above would be good to autojoin since they are used on both the news_index and news_story templates. If your title, date and summary fields didn't have autojoin turned on, then ProcessWire wouldn't go retrieve the value from the database until you asked for it it (via $page->summary, for example). Because the news_index template displays all the stories at once, and always uses the title, date and summary fields, it will perform better with title, date and summary having autojoin ON than with it OFF. In this case, it reduces the query load of the news_index template by 3 for each news story. To take that further, if it were displaying 20 news stories, that would mean 60 fewer queries, which could be significant. Fields that should have autojoin OFF: Now lets consider the body and sidebar fields, which are only used on the news_story template: body sidebar It would be desirable to leave autojoin OFF on those fields because there is no reason for the body and sidebar to be taking up space in memory when they are never used on the news_index template. While it might mean 2 fewer queries to view a news story, that is not significant and certainly not a worthwhile tradeoff for the increased memory footprint on the news_index template. Keeping autojoin OFF reduces a page's memory footprint. Conclusion Using the 'autojoin' optimization can increase performance on fields that get used a lot. Not using it can reduce the page's memory footprint. What is more desirable in each instance depends on your situation. But if your situation doesn't involve lots of pages or data, then you don't need to consider autojoin at all (and can generally just leave it off). Additional Notes Not all fields have autojoin capability. You won't see the option listed on fields that don't have the capability. *The title field has autojoin on by default, so you don't need to consider that one. It was included in the examples above because I thought it's omission might cause more confusion than it's inclusion. Be careful with multi-value fields that offer autojoin capability (page references and images, for example). Because MySQL limits the combined length of multiple values returned from a group in 1 query, autojoin will fail on multi-value fields that contain lots of values (combined length exceeding 1024 characters). If you experience strange behavior from a multi-value field that has autojoin ON, turn it OFF. If you want to play it safe, then don't use autojoin on multi-value fields like page references and images.

Maybe the 13" version had similar issues but I can only talk about the 15" version and its issues. I started with Macs back when the iBook G4 was the latest (not so expensive) model and kept Macs on my desk until 2015. That year and that MBPr 15 made me switch back to Windows setups. First Windows 8.1 on Lenovo X1 and now on a MS Surface. Never looked back. The day you need your Bluetooth keyboard or any other device you might see a change in your Wifi connection. ? Get yourself a USB hub (if needed) and a nice mechanical keyboard.

I'll try that thanks. Didn't even know it was on tbh, I must have left it on after connecting to Sphero.

Turn off Bluetooth entirely. Restart (keep Bluetooth disabled) and watch if behaviour changed.

Thank you for answering. The client is a financial group. They are all in the same building and they all know that their site have to be in both languages (it's almost a prerogative for doing things in Canada...) But I agree with you that I would got with 4 different instances. Since they will share the main design with perhaps difference in colors, there is certainly a way to make sure that the core CSS is identical.

i guess we do need to cleanup the checkboxes then, but i just copied the other checkbox config stuff for the new checkbox; I didn't realize that would make it checked by default; I guess this means that all of the checkboxes for this module are checked by default when you install;

So back to your first post and what is the problem? It's hard to say as it depends what you want to do. I think it's once you $mymodule = $this->wire('modules')->get('MyModule'); The module is loaded and init()'d , unless it's a autoload module. So the fullname is already set. So you want to set the fullname after you set the names or when you call execute. Or have a getter method for fullname. There's lots of ways... <?php namespace ProcessWire; class MyModule extends Process { public static function getModuleInfo() { return array( 'title' => "My Module", 'version' => 1, ); } public function __construct() { $this->set('firstName', 'Han'); $this->set('lastName', 'Solo'); } public function init() { } public function getFullName() { return $this->firstName . ' ' . $this->lastName; } public function ___execute() { return $this->getFullName(); } }

@adrian, in order for dynamic domain to work, all of the domains have to be registered/validated in Mailgun. So for most uses the dynamic domain is not necessary. It shouldn't have been checked by default, if it was, i'll have to figure out how to make it not so. This would only be useful for sites where you have identities that are sending from multiple domains; So for example if someone had a few forms, and one of the forms needed to have the sender email be a different domain than was entered in the form settings. If you are in fact sending from a verified domain, and the mails are not being sent, can you check the mailgun log to see what the error code is? Also, i should point out what happens if you don't use the dynamic domains, the emails will still go through, but will all be logged under the domain entered in the settings. The dynmaic domain just allows that config property, which is used for the CURL, to be changed on a per-message basis, setting the value of the api domain to the sender's domain (extracted from their email address). This files the messages under the correct domain logs in the Mailgun interface. If it is not working, one possibility is that the code to extract the domain is not 100% working for all email address formats.

Out of curiosity I've just dived a little deeper and agree that the limiting factor is the database field. The interesting point is, that my limitation differs, as I get 6 significant digits. So storing 15248.25 returns 15248.2, which is a little surprise, since a regular float should provide 7 significant decimal digits (https://en.wikipedia.org/wiki/IEEE_754). Anyway, if two decimals are relevant and values larger than 10000 need to be handled, float is not your friend. Btw: "float" in PHP is double precision, able to provide 14 significant digits.

JSON rule format is now supported but I have a small problem with that. It works fine in the global rule field but storing JSON in file descriptions is not possible atm. Pagefile uses JSON internally for storing multi-language file descriptions so it is not possible to store JSON data there... I could not find a way to overcome this issue (even if multi-language descriptions are disabled Pagefile still drops JSON descriptions). Any idea? See Github issue

Hey, I just wanted to say that this kind of functionality is super important for many websites. I just spend three hours looking for a solution until I stumbled on this. Seriously consider adding it to the documentation. Now I can easily show only news item that actually has content in the relevant language.

Awesome! Good luck with the project!

Hi bernhart ;-), thanks, that did the trick! Here's my code, if someone also needs to do this: wire()->addHookAfter('ProcessPageEdit::buildForm', function (HookEvent $e) { // skip the whole thing and return, if the user has not the proper role if (!wire('user')->hasRole('superuser') && !wire('user')->hasRole('useradmin')) return; $form = $e->return; $boxes = ['privacy', 'consent']; foreach ($boxes as $box) { $boxfield = $form->getChildByName($box); if($boxfield){ $boxfield->required = false; } } });

$this->mymodule is not $mymodule

All done. @bernhard I had to modify return false to true to to keep processing other tables in the loop (if any).

I had to do something like this recently. The "include" clause in the selector applies to the whole selector - you cannot have an include clause apply only to one OR-group. So the solution is to use include=hidden outside of the OR-groups, then exclude hidden pages within the OR-groups where you don't want the include=hidden to apply. So the selector for your example above would be: $results = $pages->find("(template=x|y|z, status!=hidden), (template=a), title|body~=$searchquery, include=hidden");

Please be a bit more specific. Why is this so important to you, and how would you envision it being implemented in the context of ProcessWire? Have you considered the possible solutions mentioned in this thread, and if so, what made you decide that they are not good enough? We're always happy to discuss new ideas and suggestions, but on the off chance that you're only posting these things in order to cause an argument, be aware that such behaviour won't be tolerated here. Thanks for giving your posts a bit more consideration from now on, and have a great day!

Hi Torsden, try to use ProcessPageEdit::buildForm, do a google search for this exact phrase and see if you can get examples. Sorry, on mobile ? The principle is to get the right field in the hook and then just change the "required" setting.

Thanks @BitPoet! I thought it was something more generic, but now it makes sense why I have missed it ?

Don't have a chance to look into this right now, but is anyone having issues on PHP 7.3? Saw a comment on the module listing from Alex Capes about it breaking. In the meantime, I've opened up an issue over at GitLab: https://gitlab.com/rockettpw/seo/jumplinks-one/issues/1 @Karinne Cyphers - only saw your note now, sorry about that! It's likely due to rules 16a/16b in htaccess. 16a limits the characters allowed in a URL, so hits would never even boot up ProcessWire. Try changing to 16b (and adding the tilde if it's not there). ——— Future Development / v2 I profusely apologise for how long it's taken to get things done for v2. As some of you know, my daily responsibilities have taken over, and committing time to open-source projects is not there as it once was. I'd love to be able to say that I can try find some time to get to it, but it's simply a promise I can't make or keep, unfortunately… The way I see it, there are two options on the table. First is to wait it out (I know, I know…) – I do have a project board on the old repo, so I know what stands where and what I'd envisioned for the module, and can pick things up where I left off last (phew, haven't touched jQuery in forever – that might be a challenge), when the time avails itself. Technically, I'm about half way there but there's still quite a bit of work to do in terms of frontend. Second option would be for someone to take over the project. It'd definitely need to be someone who can commit the time to its development, and develop in line with the way in which the module has been built so far (there's a decent amount of SoC going on, and the module is built up using packages such as Eloquent, FastRoute, etc.). Alternatively, as a third option, we could take a multi-contributor approach. So, if anyone is interested, feel free to send me a DM and we can chat about it.

okay this is not an bug in the module. this happens also with native redis php session store and also with memcached. I have filed a PW bug: https://github.com/processwire/processwire-issues/issues/798

Hi, without a loop, you could use selector subfields to find your options like the following: $page->repeater->find("sub_repeater.field=value"); So for you code : $option_name = $p->shop_product_options->find("shop_product_options_option.global_text={$option['name']}"); if(is_null($option_name) || !count($option_name)) { continue; } else { // do stuff }

Very nice writeup. Thank you for sharing! There are so many different approaches to handling responsive images and it is great to see how others do it. Would love to see more approaches from others here, too. To get the concept of responsive images, I read the anatomy of responsive images which explains them very well. Then I used to implement a quite similar approach to @MoritzLost for some time utilizing the MarkupSrcset module and also my own functions. Until I stumbled upon an article about creating responsive images which shows an approach that I now prefer. In this approach you go through all your different images in the finished layout and determine their exact respective size at your breakpoints. Then you build srcset and sizes attributes for those exact values. So there is no more approximation using scaling factors. You get exactly the amount of images at the sizes you need them. I pass an array with the breakpoints and the required sizes for that breakpoint and build srcset and sizes from that array. Here's the code: /** * Builds responsive img tag with srcset and sizes attributes * @param \Processwire\Pageimage $img * @param array $breakpointsizes array of associative arrays that describe media min breakpoints and width/height of images from the respective * breakpoint to the next * Example: * $breakpointSizes = [ * ['bp' => 320, 'sz' => [500, 0]], * ['bp' => 576, 'sz' => [992, 0]], * ['bp' => 992, 'sz' => [690, 0]] * ['bp' => 1200, 'sz' => [835, 0]] * ]; * @return string */ function renderImageResponsive($img, $breakpointSizes) { $imgSrc = $img->url; // use original image as fallback src $alt = ($img->description) ? $img->description : $img->page->title; // if no description use page title // construct sizes attribute $sizes = array(); foreach(array_reverse($breakpointSizes) as $bs) { $sizes[] = "(min-width:{$bs['bp']}px) {$bs['sz'][0]}px"; } $sizes = implode(', ', $sizes) . ', 100vw'; // construct srcset attribute $srcSet = array(); foreach($breakpointSizes as $bs) { $srcSet[] = $img->size($bs['sz'][0], $bs['sz'][1])->url . " {$bs['sz'][0]}w"; } $srcSet = implode(', ', $srcSet); return "<img class='img-fluid' src='{$imgSrc}' srcset='{$srcSet}' sizes='{$sizes}' alt='{$alt}'>"; } Obviously it does not account for Retina which needs to be added. I will also extend my function to add support for other attributes like you showed it. That is a great idea.

Noone wants to blame small offices and business that are in need for a website that won't break the bank. I blame those professional scammers that sell 80-dollar-theme-based sites as custom-made [whatever buzzword fits here] website and either charge way too much or dump prices with it.

Oh yeah... I love those super creative full stack and full service brand entrepreneur happy guys agencies that sell websites this way and claiming they are the best in the market doing highly coughstomized websites and brand building. I know agencies that charge five-figure numbers for 80-dollar-theme-based sites. Only if you do basic website jobs without any real custom data. Pages and posts slightly customized with visual page builders but that's it. A win-win situation for both sites.

So let's call it a scam as we should not call it web development. Playing dirty tricks is one thing and being honest and helpful is another one. I always stick to the latter. Sure, I will never become a billionaire with my "silly" attitude but at least no hordes of angry people are chasing me my whole life. Instead, I have a bunch of friends who know they can trust me.

https://www.baumrock.com/portfolio/individuelles-crm-und-controlling-tool/ I'm happy to share my biggest and most interesting ProcessWire project so far with you It's a 100% custom office-management solution that helps my client to keep track of all their contacts, projects and finance/controlling stuff. Conception was done back in 2016 and the software is productive since begin of this year. My client is very happy with the result and so am I. Some technical insights: Everything is done inside the PW Admin. I'm using the Reno Theme with some custom colors. In the beginning I was not sure if I should stay with the pw admin or build my own admin-framework but now I'm VERY happy that I went with PW Almost all of my custom Process Pages use my RockDatatables module - there are still some limitations but without it, this project would not have been possible For the charts I used Google Charts and chartjs - both play well together with the datatables and make it possible to display filtered data instantly: also my handsontable module was created for this project to have a nice and quick option for matrix data inputs: Lister and ListerPro were no options as i needed much more flexibility regarding data presentation (like colorization, filtering and building sums of selected rows): invoices are highly customisable as well and easy to create. PDFs are created by php and mPDF by the way: all data is dummy data populated via my Module RockDummyData have a nice weekend everybody

Hi, @flydev! Recaptcha v3 came out, would you mind taking a look?

Modules > Core > ProcessUser > What fields should be displayed in the page listing?

Nik is right about this. You probably want to change your selector to something like this: $field = $user->language->isDefault() ? "body" : "body.data" . $user->language; $matches = $pages->find("$field*=$q"); That will force it to not consider the default language in the matches at all. However, most of the time you should just do this, which already takes languages into account: $matches = $pages->find("body*=$q"); So whether the user searches for "Beer" or "Cerveza" they will still get to the right page. If you exclude the default language, then that fallback never happens.