Leaderboard

For this to happen you must be using somewhere the $user variable which is the one that refers to the user in session. I'm thinking this is what you are looking for, so when Bob is logged in, $user will refer to Bob, and when Amy is logged in, it will refer to her user: $current = $pages->find("template=secondary, page_author=$user");

Hello, interesting topic. Here is one example (please read comments inside script): // !!! configuration $desired_templates = array('basic-page'); $desired_fields = array('body', 'summary'); $stop_words = array('and', 'is', 'for', 'a', 'the', 'to', 'of'); $limit_list = 10; // most used words list $words = array(); // target templates where we search $selector = implode("|", $desired_templates); // get all desired pages $content = $pages->find("template=$selector"); // fill words array foreach($content as $item){ foreach($desired_fields as $f){ $words[] = $item->{$f}; } } // https://stackoverflow.com/questions/3175390/most-used-words-in-text-with-php function most_frequent_words($string, $stop_words = [], $limit = 5) { $string = strtolower($string); // Make string lowercase $words = str_word_count($string, 1); // Returns an array containing all the words found inside the string $words = array_diff($words, $stop_words); // Remove black-list words from the array $words = array_count_values($words); // Count the number of occurrence arsort($words); // Sort based on count return array_slice($words, 0, $limit); // Limit the number of words and returns the word array } // output var_dump(most_frequent_words(implode(' ', $words), $stop_words, $limit_list)); Bad thing in this example is if you do this query in fronted runtime, better place this in some specific template and use PW cache. Also, maybe the best option is to create some Ajax driven module in backend and generate there words list. Regards.

You bet, our Quality Assurance department was very happy to discover that! While a lot of website do not require unit testing, we try to implement those with our more complex websites.

Apologies - you are indeed correct. I can't imagine why it would actually have been changed - not sure why you'd need uppercase chars in a field name, but the description of what is allowed certainly has changed. https://github.com/ryancramerdesign/ProcessWire/blob/a210ba0b5ea67e56fef8a27a620bcfa6f96ca0b8/wire/modules/Process/ProcessField/ProcessField.module#L949 https://github.com/processwire/processwire/blob/48fe0769a4eb3d0f5b4732fd01b4b4ed8262d952/wire/modules/Process/ProcessField/ProcessField.module#L1196

Thanks Adrian. This got me more curious because I vaguely remember having a talk about lower case vs upper case. So, I went back and checked, all the way from 2.2 up to and including 2.7.3. It was only lower case in those versions. So, this must be a 3.x introduction.

@Karinne Cyphers, Thanks for the screenshots. They've helped clarify issues. I suspected as much given the error MySQL was throwing. The error itself is originating from ProcessPageLister (a core module) which Media Manager extends and uses to fetch and display media pages. As far as I can remember, ProcessWire only allows lower case letters for field names. Going by your screenshot though, it seems this changed sometime back. Back to your issue, the error is a ProcessWire error and not Media Manager's. I'm not sure whether it should be filed as a ProcessWire bug (specific to your server environment, maybe) since it now seems upper case letters are allowed in field names. I'll try and find out.

Exporting is a resource intensive task, if you have a lot to export.... In this case I would recommend cloning the site by copying all files, adjusting config.php and anything else that matters + simply cloning the database too. You can automate it by scripting or using a tool which supports such operations. There are various forum threads discussing it, for example: https://processwire.com/talk/topic/14837-best-practise-to-implement-changes-in-pw-from-development-to-production/ https://processwire.com/talk/topic/3998-your-deployment-process/ https://processwire.com/talk/topic/3113-how-to-transfer-processwire-from-local-installation-to-online/ etc...

I can confirm this behaviour, also with the latest PW version. All API-generated (resized) versions are not animated anymore. PHP Version 5.6.36. Reminds me... I should update this instance to v. 7.x as well ?

@tires I'm not sure that there is something built in for your needs in PW, but you can easily create a custom module As the starting point, you can use these example https://github.com/benbalter/Frequency-Analysis/blob/master/frequency-analysis.php

You have a 512MB limit. I guess the error says that you already used eg 511,99 MB then allocating another 0,02MB would be too much. Please don't double post

@Robin S. Great I'll look at it soon. Thank you Robin, I would not have done anything without your help.

My apologies. It was an access issue for that user group - CI3 wasn't selected. Thanks for your help. - Marty

Hi @adrian A feature request for your consideration: please could you apply the lovely code editor to the custom PHP textarea in the module settings? Would make editing custom PHP much easier. Many thanks for your consideration! Steve

Will do that and see what happens Edit: the terminal commands as shown how to download devilbox don't work for windows (as I already expected) I leave it for a rainy day

Great, at least it turned out somebody makes use of the module ?

I could track it down and reported it as it looks like a bug in the core: https://github.com/processwire/processwire-issues/issues/650 In short: If Inputfiled Images with "Overwrite existing files" is ON then creating a cropped image yields created=1970-01-01 01:00:10, ie. when this option is on, ProcessWire does not update the "created" field in the database. Thanks for the help guys!

Give https://github.com/cytopia/devilbox a try.

Hello, here is simplified version of icons font fieldtype module: https://github.com/OLSA/FieldtypeFontIcon This module use the same icons css file like your template (set path relative to template folder, eg. styles/fontawesome5/all.css ). After module install and created field go to field Input tab to set path (and in some cases prefix classes). Examples: Font Awesome 5 IcoMoon If everything is ok you will get something like this: NOTE: "Regular expression pattern parser" input field is not required because it will be set by default (by module itself). Regards.

In my case it wasn't cropping the image which led to unexpected results it was only resizing. It took me hours without any results until I used a different image. I don't know if you test with only one or several images but if there is only one image you use, please try another one. My .jpg was more of a corrupted-Frankenstein-PNG-saved-to.jpg file. May sound ridiculous but you never know.

Ok, I just installed Ampps and imported a few website backups and started fiddling around. I must say that Ampps has a nice interface to work with, but it is clearly slower compared to Laragon.

You are hooking Module::saveConfig instead of Modules::saveConfig.

I usually post to the blog on Fridays, but I've been working on ProcessWire-based client projects this week, so nothing new to post today. I'm back to working on the core next week and continuing the 2FA development, so will have more next week. Thanks and I hope that you have a great weekend.

Clean code, less code than content (ratio), and fast content delivery aren't a guarantee of good SERP results. You can build the smallest, cleanest and bestest website ever and get outranked by a crappy WordPress instance. Sometimes other things matter more than that. Links, links, links, spammy content, PBN links, more PBN links, more spammy content... all those grey to black techniques still work for almost every site. Old domain with trust but spammy content and WordPress footprint? Perfect! We already love it. New domain with better content, better UI, better load times? Are you kidding me? We will never rank that! You build clean, fast sites as a base for more. Good SERP results are a thing you have accomplish with several other things. Spend a few hundred dollars for a good, old, trustworthy domain, create 100 pages of optimized content pages for another 200 - 300 dollars, get lots of links from trusted sources (Reddit, LinkedIn, Blogs, ...), buy 10-30 more good old domains, build spammy sites with matching content, create backlinks, outreach to other spammers bloggers, get more links and you are in the Top 10 to Top 3. Don't play fair on money keywords. That won't work.

The truth is, a simple WordPress theme modified and used in the correct way is good enough for most companies. Are they being ripped off? Probably. Will they be able to do it themselves? Unlikely. It still takes a designers eye to get the absolute best out of a theme. I worked for a company like that. 9-5, using a WordPress theme and just slightly modifying it or sometimes not at all. There's not absolute creative freedom but not everyone needs an artisan website. I enjoyed working there, the work was easy. But I wasn't crafting my skills. I now work at an established creative agency where people pay a lot of money for the designs and our designers are genius, as an aspiring designer, I'm envious. But it would never be an option for us to just use a theme. It would be dishonest to our clients that go to us for our design prowess. We find our clients find ProcessWire easier than WordPress to edit. I understand with ACF there isn't much difference between the two. But actually it's less about the forms and more about what is unique to ProcessWire - everything is a "page". The thing that threw me the most when I first moved from WordPress to ProcessWire became the absolute greatest thing about the CMS. It gives everything a level of consistency and doesn't lock you down to "taxonomy", "tags", "post types", "terms". You aren't locked down to a relationship structure and you can make a relationship structure that works for you, your clients and the website.

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.

Yeah keep on wp trolling, it feels good I know. But lets get real for a change, it's 2018 and not 2010 any more when wp was total crap. Plugins and safety have been improved since then. I know people who deliver websites faster than I do and make more money with wp than I do ! All they do is go to themeforest or envato and search for a cool looking template with forms, mail, client base and the whole shebang for around 50 or 80 dollar. It takes them less then a week to set it up and then sell it somewhere between 500 and 1500 dollar. And clients like the wp admin because it only takes simple mouse clicks for them to edit a wp site with new text, pics or prices. How I found out all this ? Simply because I get called by offices, real estates, photographers, etc. because their webmaster/developer took off, disappeared or they ended up with agreement conflicts. They need somebody to take over. No backups were made for half a year, cpanel access has gone, yearly domain registry has gone, etc. All they have left is the wp-admin login. So the more I got involved the more I started to see what is going on in wp land. The reason why I stick to pw ? Because working with wp dumbs you down to a copy and paster - drag and dropper. Working with pw upgrades your skills and you learn to webcode. But really, when it comes to working hours and making money, wp is the better choice.

I've always found that the easiest way to store site settings is with a dedicated template/page. I'm a bit confused by your code because it looks like the module doesn't have any config fields, but generally speaking you can get your module config data after it is saved by hooking after Modules::saveConfig (or Modules::saveModuleConfigData if you need to support older versions of PW). You hook will run after the config is saved for any module, but you can use the first argument to compare against your module classname and return early if it doesn't match.

I completely agree with everything everyone has said thus far regarding WP. If I "have" to do anything with wordpress, I use typerocket. The framework makes it a lot more enjoyable to work with (IMHO) and has repeaters as well.

It's WordPress... there must be a plugin for that!

Well, nice to see some fixed issues being closed now. I count 35+ closures since yesterday, which takes the project well below 200 open issues. I do hope that some progress can be made on other items. Can we ease creating pull requests for small items in any way, perhaps that would help the overall effort?

The only sane approach to issues on github I know is closing them as fast as possible, which can be split up into subtasks by deciding if something is a … bug => fix as fast as possible/fitting and then close directly. If there are still things to clarify this can be done in the closed issue. ryan can open it again if really needed, but it's ryans task to say "this issue is resolved" by marking/keeping issues closed. Keeping that responsibility on the issue openers side simply does not work from my experience. feature_request => should be closed immediately with a message to where feature requests should be stored not a bug => closed immediately not reproducable => ask for failing test/repo/something, close if there's no response after x (2-4) weeks

I'm looking forward to the 2FA updates. I'm hearing of more and more companies forcing 2FA with their email systems(GSuite or Office365). We've had these discussions and will probably do this at our company as well. Once people start getting used to using it with their email and banks, they will start to expect it with their websites as well. I agree with Ryan, I think it will look good if Processwire already has this security built in. It builds trust with larger organizations. As a website administrator, I currently have to set up a secure password for each of my site editors so they don't get hacked. I can't rely on them doing it. I also have to disable them from reseting their password to something easier to remember. With 2FA, I don't care what they set their password to. It would be nice if we could somehow require/force 2FA for specific roles like Site Editors. I'm not sure if this is a different technology then 2FA, but when using G-Suite, you also have the option to use the Google Prompt. https://support.google.com/accounts/answer/7026266 This makes it much easier to sign into accounts. I wonder if that is just a Google thing, or if that is something that Processwire can utilize as well? They also offer several different ways to authenticate https://support.google.com/a/answer/175197?hl=en including Yubi Keys, Google Authenticator App, Google Prompt, SMS text message codes, and backup codes.

I don't plan on forcing the option, though had thought that when enabled, we'd give them a login warning notification asking them to enable it, every time they login. I haven't come across any services that forces me to 2FA yet, though I know some companies require it internally. But I think it might depend on the 2FA method being used before you could say if it would be a good idea to force it or not. There are times where you might want to disable 2FA temporarily too. So I think it's best to let the user control it, and maybe annoy them a bit with warnings when they aren't using it. But this is one of those things where I think we'll start fairly simple, but then start fine tuning the options according to what we find are the needs of people using it. I think support in the core is consistent with PW's strategy of making security the top priority. I think we are soon reaching the time (or already have in some cases) where 2FA is considered essential in order for an online application to be taken seriously as having an emphasis on security. I consider it essential for any other online account I maintain (as I imagine many do), so it should be in PW too. If we step outside the security aspect, I think it also builds trust and checks boxes for a lot of bigger companies that may be considering PW or comparing to other options. The support and interface for it will be in the core. The implementation of the interface will be in modules. There will very likely be one implementation module included in the core, though I'm not 100% positive on that yet. Either way, I'll be building and maintaining at least one of the modules that supports it. As I understand it, Google Authenticator is just a standard implementation of RFC 6238 and RFC 4226, like any number of other authenticator apps. As far as I know, they are compatible with each other, but Google Authenticator is just the most widely known/used. I think the compliant you mentioned is the nature of the technology, and not really anything about Google Authenticator in particular. But the complaint is also the reason why it's secure. Once one understands how it works and the steps they should take, I think it all make sense. I'll try to describe. The reality is that 2FA is an extra step, which you can't deny is an inconvenience. But it's like locking your door before you leave the house. Nobody likes having to take extra steps, what they like is the security benefit (if they understand it). And if you lose your keys, then yes you are locked out, unless you've got a backup method. This is why services typically provide backup 2FA methods (like SMS) or one-time use backup codes that you can store securely somewhere in case you ever lose your device. For every place where you use 2FA, you've established "a secret" between your device and the service/website (a long base32 string, which can also be represented by a QR code image). The reason it is secure is because it's not shared anywhere else. If that secret were stored up in the cloud or synced between devices and such, then it is becoming less secure. It is getting passed around networks just like your password, which kind of defeats the purpose of 2FA. If you buy a new phone, and can't restore backup data from your old phone for some reason, the yes you'd want to reset your 2FA for the new phone. If you've got your old device handy, then you'd switch the 2FA to your new device. If your old device is lost or non-functional, then this is where a backup method and/or one-time use code would come into play. If those options weren't available, when it comes to PW, one could also fix any of this by asking a superuser to reset it even temporarily disabling from $config (if nobody had admin access). As I understand it, this is simply a matter of a user 2FA off for some account, then turning it back on, so they can establish a new secret/QR code. There's already a password reset module built into PW. 2FA can be disabled for any individual account as needed. This is what the superuser account is for. ? This is definitely part of the plan. Though with the 2FA methods I've been working with, we can't enable it for anyone that hasn't set it up themselves. Maybe with Netcarver's PPP module when using email, it could work. Or maybe it would work with SMS when you've already got the user's mobile phone number stored. It needs to know the user name in order to be able to look up the user-specific secret for the codes. Technically it doesn't need the password. But 2FA without a password is no longer two-factor, and would have its own security problems, which might be even worse than not having 2FA in the first place. If someone gets a hold of your device, and needs no password for your account, then they essentially have access to your account. Whereas, the intention with 2FA is that both your password AND your device are necessary. It's that combination of factors that makes it secure.

Cool. On a related note: If you need to extract images from an MS-Word file, there's an easy "hack": Copy the Word file rename it to filename.zip. Un-zip it, and you'll see a folder "media" with all the images inside

This is a conversation that comes up quite a bit in our shop. It's a valid point you make especially from the perspective of first-timers. I have ran into this a lot of times with people new to PW or even just in general web design dev conversations where PW comes up. I preach PW to all my fellows (of course) and I am often met with the same reaction... something along the lines of "we would have chosen PW because it seems perfect, but we needed to get something done [fast, easy, simple, etc.]..." I am fully in the camp of the reason I love PW is that it doesn't force me into some frontend hell like other platforms (not mentioning any names). Of course, this is ideal for me as I am a frontend design/developer. So I see how there is this big gap in perception. I think there could be a strong market for prebuilt PW site profiles that are robust and full-featured. Especially if they focus on a specific demographic or genera (for lack of a better term) like real estate or business sites or hotels. With tools like the Repeater Matrix, we almost always build a WYSIWYG experience for all of our customers. So they can choose, drag and drop, and combine site elements however they want. They love it. Buuuutttt.... this is where the whole conversation gets tricky. The beauty of Processwire is that it's "an un-opinionated CMS/CMF". that literally is the magic sauce. So every time we break out this discussion and go down the idea phase of how we could actually create the type of experience you are suggesting... we end up at the same conclusion. That by making those content/layout/structure/design/ decisions in advance, we end up sacrificing the very thing that draws us to PW in the first place. I agree that PW is missed in a lot of cases. In my experience it goes like this: Developers: it's too simple - can't handle what I want to do. And they go a more "complicated" route. Designers: it's too hard, I can't seem to get something to appear instantly... it's too hard/slow/complicated. I feel like I have been in that conversation 100 times. I find that the people that take to PW are almost always people who have crafted their frontend chops and care enough about that part of the experience that they value PW's way of staying completely out of your way. At the same time giving you full control over the design of your admin/backend experience as well. I think making an out of the box solution to websites with PW ends up missing the reason it works so well in the first place. But, this is probably not the last time I jump into this conversation or start to think of how I can make some killer templates/site profiles for sale. hahaha. I hope this discussion continues because I think there is a piece of magic here... just haven't cracked the nut on it yet.

Lets see if we can get a quick-start tutorial going here. We'll start with something really simple and then work up from there. Tell me when something makes sense and when it doesn't and we'll adjust as we go. My thought is that we'd make a tutorial that plays on the 'hello world' phrase and lists information about planets in the solar system, starting with Earth. To keep it simple, we'll assume that the basic site profile is installed, as that's what comes with ProcessWire (so there's no need to uninstall anything). But we won't start using any of it's files tat this stage. Instead, we'll start out by creating our own files. STEP 1 – Create a template file Create a new file called: /site/templates/planet.php, and copy+paste the following HTML into that file: <html> <head> <title>Earth</title> </head> <body> <h1>Earth</h1> <h2>Type: Happy planet, Age: Millions of years</h2> <p>Earth (or the Earth) is the third planet from the Sun, and the densest and fifth-largest of the eight planets in the Solar System. It is also the largest of the Solar System's four terrestrial planets. It is sometimes referred to as the World, the Blue Planet, or by its Latin name, Terra.</p> </body> </html> The above is just a plain HTML file with nothing specific to ProcessWire. We will use this as the starting point for our template, and we'll go back and modify it later. STEP 2 – Add a template to ProcessWire Login to ProcessWire admin and go to Setup > Templates. This page shows a list of templates currently in the system. Click the Add New Template button. On the next screen that appears, you'll see it found your "planet" template file. Check the box next to the planet template and click Add Template. You may ignore any other options that appear on this screen. STEP 3 – Creating a page using your template Your planet template is now in the system and ready to use, but it's not being used by any pages. So lets create a page that uses the planet template. In the ProcessWire admin, click Pages in the top navigation. This is a site map if your page structure. We want to create a new page under the homepage, so click the new link that appears to the right of the home page. The next screen has 3 inputs: title, name and template. Enter "Earth" for the title, and the name should populate automatically. For the template, select planet. Then click Save. Now you have created a new page using the template that you added. You are now in the page edit screen and you should see your title field populated with "Earth". Click the View link that appears on this page edit screen. You should see the output of the HTML from step 1. Click the back button in your browser to return to the edit screen. STEP 4 – Creating a new field Now you know how to create a template and a page using that template. You could create more pages using the same template if you wanted to. But that wouldn't be particularly useful – this template file is just a static HTML file. Lets make it dynamic by creating some fields and adding them to it. We are going to create 3 fields to represent the pieces of data that currently appear in our static template. These include the planet's type, age in years, and a brief summary. We will call these fields: planet_type, planet_age and planet_summary. In ProcessWire admin, click Setup > Fields. This screen shows a list of fields currently in the system, most of which are general purpose fields for the basic profile. For the purposes of this tutorial, we are going to ignore those and create our own. Click the Add New Field button. On the next screen, enter "planet_type" for the Name, select "text" as the Type, and enter "Planet Type" for the Label. Then click the Save Field button. Now that your field is saved, you are on the Field Edit screen. At this point, your field is created and ready to be added to your planet template. Optional: While editing your field, click the details tab where you'll see a select box for Text Formatters. Select "HTML Entity Encoder" – this ensures that characters like "<", ">" and "&" will be converted to HTML entities and not confused as HTML tags. While not required, it's a good practice for text fields like this. After you've done that, click the Save Field button. STEP 5 – Creating more new fields In step 4 we created the planet_type field. Now we want to create the planet_age and planet_summary fields. So in this step, you'll want to do the same thing for the remaining two fields: Create the planet_age field exactly like you created the planet_type field, but enter "Planet age in years" for the label. Create the planet_summary field exactly like you created the planet_type field, but chose "textarea" as the Type and enter "Planet summary" for the label. Note that a "textarea" field is just like a "text" field, except that it can contain multiple lines of text. STEP 6 – Adding new fields to your template Now that you've created 3 new fields, you need to add them to your planet template. In ProcessWire admin, click Setup > Templates > planet. You are now editing your planet template. In the Fields select box, choose planet_type, then planet_age, then planet_summary. You will see each added to the list. Cick the Save Template button. STEP 7 – Editing a page using your template Now that you have new fields added to your template, go back and edit the Earth page you created earlier and populate the new fields that are on it. In ProcessWire admin, click Pages at the top, then click the Earth page, and click the edit button that appears to the right of it. You are now editing the Earth page you created earlier. You should see the new fields you added, waiting for text. Enter "Terrestrial planet" for Planet Type Enter "4.54 billion" for Planet Age in Years Paste in the text below for Planet Summary and then click Save. STEP 8 – Outputting dynamic data in your template file While still in the page editor from step 7, click the "View" link to see your page. Note that it still says "Happy planet" for type (rather than "Terrestrial planet") and "Millions of years" rather than "4.54 billion years". That's because the page is still being rendered with just the static data in it. We need to update the template file so that it recognizes the fields we added and outputs the values of those fields. Edit /site/templates/planet.php and replace the static text in there with tags like this, replacing field_name with the name of the field: <?php echo $page->field_name; ?> If supported by your server, you may also use this shorter format which some people find easier to look at and faster to enter: <?=$page->field_name?> Here is the /site/templates/planet.php file updated to output the content of the page using tags like the above: <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <h2>Type: <?php echo $page->planet_type; ?>, Age: <?php echo $page->planet_age; ?> years</h2> <p><?php echo $page->planet_summary; ?></p> </body> </html> After making these changes, save your planet.php template file. Now view your Earth page again. You should see it properly outputting all of the content you entered on the page, including "Terrestrial planet" for Type and "4.54 billion years" for age. Any changes you make from this point forward should be reflected in the output. STEP 9 – Creating more pages, reusing your template For this last step, we'll create another page (for Jupiter) using the same template just to demonstrate how a template may be reused. In ProcessWire Admin, click Pages and then click the new link to the right of the home page. Enter "Jupiter" as the Title and select "planet" for the Template. Click Save. Now that you are editing the Jupiter page, enter "Gas giant" for Type, enter "4.5 billion" for Age in Years, and copy+paste the following for Planet Summary: Click the Publish button and then View the page. You should now see your planet template being used to output the information for Jupiter rather than Earth. CONCLUSION In the above, we covered the basics of how to develop in ProcessWire, including the following: Creating templates and their associated template files Creating basic text fields and adding them to templates Creating and editing pages that use your templates Outputting the values of fields in template files If all of this makes sense so far, I thought we'd follow up next with a tutorial to take this further: Adding and outputting photos for each planet Creating navigation that lists all the other planets that have pages in the system …and we'd keep building upon the tutorial from there. If you all think this tutorial is helpful, then perhaps this can be a draft for a real tutorial we'll put on the site, so all of your help is appreciated in making this as good as it can be.