Leaderboard

I've made a module for checking a password against a banned list. The list comes from the 10,000 most common password list and when input will produce an error informing the user that their password is in the list and a more secure password should be used. The module was based on a question I asked in the development section (over here). The banned list is found in the module as banned.list so passwords can be added/removed as required. The module should be in the Modules section once it has been approved. PasswordBannedList.zip

Hi xvda Please feel free to have a look at the code for my LoginPersist module, where I create a hook for Session's authenticate() method for that request. I store a temporary password for the user in the session, and in my hooked authenticate() I check the temporary one rather than the one in the database, and return true if it matches. I've also created a TwitterLogin module (like the Facebook one you're using) using the above method, but it hasn't been fully tested yet. You're more than welcome to have a look at it though.

see you there, then

This module adds a preview and zoom button to InputfieldTextarea for live previewing the content after being formatted by the text formatters assigned to that specific field. It's pretty alpha still but it already works. For now I was only playing with the Parsedown formatter, but it should work with every other formatter as well, even with Hanna Code, not sure though, haven't tested it. It's restricted to regular textareas, meaning TinyMCE et al are not supported yet, because they need specific change listeners. Will look into it though. The result is fetched via ajax from a process page, the default style sheet contains some Github-like styles but the style sheet is configurable, see module settings. Github: https://github.com/owzim/ProcessTextareaPreview Open for suggestions

I do think setting up virtual hosts (in most cases) is a good practice and there really isn't that much to it. However, it seems you have your VirtualHost setup wrong. Localhost will already be defined by wampserver and probably has precedence over your vhost entry, hence localhost shows the wampserver startpage. I'll show and example of a working VirtualHost entry: <VirtualHost *:${AP_PORT}> ServerAdmin webmaster@mysite.dev DocumentRoot ${US_ROOTF}/vhosts/mysite ServerName mysite.dev ServerAlias www.mysite.dev *.mysite.dev ErrorLog logs/mysite.dev-error.log CustomLog logs/mysite.dev-access.log common <Directory "${HOME}\vhosts\mysite"> Options Indexes Includes AllowOverride All Require all granted </Directory> </VirtualHost> In this case my PW files are in a /vhosts/mysite folder, but this can also be a full path like you did, as long as Apache can reach it. No need for a trailing slash in the document root. For vhosts to work you should also edit your Windows hosts file to match the vhost, in this case example adding a line "127.0.0.1 mysite.dev" to it. I can, and need, then approach this project via typing mysite.dev/ (or www.mysite.dev/) in a browser. So i think you have to change servername and serveralias to something that makes sense to you; for example sitedomainname.dev, or anything you fancy. You will also have to add a line to the windows hosts file, like described above. Restart everything and it should work. - dagnabbit, just when i was typing this you read my other post

Hi girls and boys, I just wanted to write some more details on this module, how it's working, why it's not implemented differently, downsides, how it could be improved and so on. Why Just recently I had an interesting chat with @marcus on how ProcessWire lacks of some markdown capabilities, for the editor in particular. Of course there is the markdown Textformatter (and now Parsedown) but the actual usability of entering Markdown was not yet taken care of in an extend I wished for. The Ghost blog system ships with pre-installed side-by-side Markdown preview capabilities, the Atom editor by Github also has this feature built right in. All in all, Markdown seems to be on the verge, when it comes to have clearly structured text data in Databases and especially in CMSs or blog systems. The folks at Perch CMS even make it one of their core mantras to never ever store any HTML in the DB. RTEs like TinyMCE or CK Editor have their places but as we all know, editor tend to wreck all our carefully structured markup and CSS with their text pasted from Word and the like. Why not client side parsing, upside of server side parsing The initial idea was to merely preview Markdown, but then it came to me that any Texformatter should be able to be previewed, so client side parsing was out of the question pretty early on. Also a JS Markdown parsing implementation could be inconsistent with the actual server side parsing. Downside of server side parsing The major downside obviously is that any text data has to be sent to the server and back so latency is inevitable. Also, you would not want to send data back and forth on every single change immediately (that's why data is send at most once per second, or not at all if no changes are taking place). Upside of current implementation with Ajax, downside of iFrame implementation Since the parsed text is loaded via Ajax and just replaced when the request is finished flickering of the refreshing text is pretty minimal. You cannot prevent images from flickering since they will be re-rendered every time the parsed text is injected. If it would be implemented with an iFrame the thing would be refreshed and flickering would be dominant and annoying. Downside of current implementation with Ajax, upside of iFrame implementation Clashing of CSS rules. If you want to display the elements properly you either have to work with many !important statements or make the rules overly specific with lengthy selectors, otherwise your current admin theme could wreck the display. With an iFrame all the styles are scoped properly, and you could even use styles that are actually used on the site, so the preview would be way more accurate. My questions I'd love to hear some suggestions on how to tackle the listed downsides, or if those should even be considered downsides. Perhaps those are out of scope of this module. The scope could remain to merely preview basic markup, so the editor has an idea how the text would turn out, focused on Textfomatters like Markdown or Textile, Autolinker and so on (so a text-focused scope). Since there already is a great module by Nico which aims at full blown previews. If so, the default hacky overwrite styles could stay as they are (could use some polish) and custom styles could be thrown out as a feature.

Hello, My name is Jordan Lev, and I've primarily been using Concrete5 for the past 5 years to build websites for clients. I just came across ProcessWire the other day (not sure how I missed it for so long), and it is very impressive and really jibes with the way I think about building sites. I actually have created several Concrete5 plugins that offer functionality similar in spirit to the way one constructs fields and templates in PW, so it was pretty incredible to discover an entire CMS that embodies those principles! I have been playing around with ProcessWire a little bit, and reading through some forum threads. I'm hoping a project comes my way soon that PW would be a good fit for, so I can actually use it for a real-world website. For those of you who have never built a site with Concrete5 before, I encourage you to check it out (if for no other reason than to get some ideas on a slightly different model of how a site can be put together). I think what C5 is most well-known for is its front-end editing, but I would say that there is a deeper reason C5 is so well-loved by people like me: it really allows you to "design the editing experience". I think PW is somewhat similar in this regard, although it seems that PW is more about "designing the content structure" (which often overlaps, but not entirely). I've read some posts by Ryan that indicate he is concerned with separating the definition of the data from the display of it (for example, https://processwire.com/talk/topic/4189-flexibility-in-page-design/#entry41205 ), and that is a fantastic way to think about things (and very refreshing if you've every worked with less modern systems like Wordpress)! But I also think that philosophy is more well-suited to larger sites that have a lot of structured content. The places where I think PW could be made even better than it already is are for the smaller-scale marketing/informational sites, where tying the content and the display more closely together actually makes sense (especially for the non-technical users who have to manage the content as time goes on). For example, I think the much-discussed "file manager"/"media manager" feature is pretty critical to an easy-to-use workflow, and I feel like there are ways it could be done that honor the underlying spirit and simplicity of PW. Also, I think front-end editing is a HUGE win in terms of ease-of-use, and the "Fredi" module seems to offer that functionality (and there are a few minor tweaks I'd love to make that would allow the site editing experience to be even more "designable"). I have seen comments in the forums that are both "pro" and "con" on the things like file manager and front-end editing, and I think the difference in opinion stems from the difference in the kinds of sites people are building (larger, more structured sites that are served better by PW's existing dashboard versus smaller, less-structured sites I think are better-served by a tighter integration with the pages themselves). What I would love to know is how interested the ProcessWire community is in even attempting to make PW a better fit for these smaller-scale websites. Are people interested in discussing these ideas, and possibly even working towards making them happen? Or is the community primarily concerned with the larger / more structured sites and not interested in rehashing this line of discussion? Or perhaps I'm making some assumptions and generalizations here that aren't true? I just want to share with you all that some of the things Concrete5 has are incredible (pretty much every client has been blown away at how easy and intuitive things are with Concrete5 when I first show them the sites I've built), and I am interested in understanding more about how to make this happen with ProcessWire, and also sharing my experiences and insights with you all in the hopes that ProcessWire can be more appealing to a wider set of users without sacrificing its underlying simplicity and design philosophy. So I'll leave it at that, and am looking forward to hearing what people have to say! Thanks, Jordan

Hi folks, I read some posts where people seem to struggle with setting up config values for their modules. Since I am currently working on some boilerplate code for modules I created a helper class that makes handling of config values a peace of cake. on Github: https://github.com/owzim/PWModuleConfigHelper from the README.md Define a default array in your module: protected static $defaultConfig = array( // example with just one option 'prettySetting' => array( // the label for the form 'label' => 'Pretty Setting', // the default value 'value' => 'I am pretty', // optional, defaults to 'InputfieldText' 'inputfieldType' => 'InputfieldText' ), // example with multiple options 'awesomeSetting' => array( // the label for the form 'label' => 'Awesome Setting', // the default value 'value' => 2, // optional, defaults to 'InputfieldRadios' 'inputfieldType' => 'InputfieldRadios', // each key is for the input label, each value will be saved if selected 'options' => array( 'Option 1' => 1, 'Option 2' => 2, 'Option 3' => 3 ), // set any additional attribute to the input field 'attributes' => array( 'optionColumns' => 1 ) ) ); Apply the defaults to your module: public function __construct() { PWModuleConfigHelper::apply($this, self::$defaultConfig); } Render out the form: public static function getPWModuleConfigInputfields(array $data) { return PWModuleConfigHelper::renderForm($data, self::$defaultConfig); } Result: Access any of the config settings from your module: $this->awesomeSetting; Stuff to be aware of If you're using this in your module and you don't want it to clash with other modules using this, you have the following options to include it: use spl_autoload_register to autoload it, so it only gets loaded once only include the class if it has not been loaded yet, via class_exists('PWModuleConfigHelper') Option 1 and 2 require the class not to change (updates etc.) so the following options are more stable: Namespace to class via renaming it, prefixing it with you module's name Namespace it with PHP namespaces I could make a module out of this but this might be overkill Cheers!

Nico In this post https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/ I attempt to explain various approaches for handling categorisation....Maybe it will help...

Here's my way of organizing AJAX. It's just another way of doing it. There's a module with some functions for handling AJAX requests. Mine's called 'fjax' and has some extra code for optionally sanitizing arguments to the functions. There's a 'fjax' template too. The fjax page (using fjax template) can be very minimal. I suggest putting it in /tools/fjax/ and setting tools as hidden. Having a Page gives us a handy URL to send requests to and the template file becomes the place to put the application's server-side AJAX code. The fjax template doesn't need anything more than the required title field. On the client side we use jQuery's AJAX tools. If you POST the data, use the query string on the URL to indicate the function you want to call (tools/fjax/?fn=function) and the module will simply pass the POST array to the function and return the result JSON encoded. If you use GET you pass the arguments on the query string too (tools/fjax/?fn=function&arg1=foo). In the template file you have 5 lines of code plus your function definitions. It's a simple PHP file so you can easily pull in code from reusable files etc. The fact that it's used with a Page means you can use Page fields as easily configurable data for your server-side AJAX functions.

Ty Craig, your code saved my life here what i did was ... i added your function to FacebookLogin.module public function authenticate($event) { if ($event->return) return; // already authenticated $sess_name = $this->wire('session')->get('tmp_name'); $sess_pass = $this->wire('session')->get('tmp_pass'); $user = $event->arguments('user'); $pass = $event->arguments('pass'); if ($sess_name == $user->name && $sess_pass == $pass) { $this->wire('session')->remove('sess_name'); $this->wire('session')->remove('sess_pass'); $event->return = true; } else { $event->return = false; } } and at the bottom i replaced $session->login($u->name, $u->pass); with: $name = $u->name; $this->wire('session')->set('tmp_pass', $pass); $this->wire('session')->set('tmp_name', $name); $this->wire('session')->addHookAfter('authenticate', $this, 'authenticate'); $this->wire('session')->login($name, $pass); if i find user on my site i also removed all instances of. $u->pass = $pass; $u->save(); and its working ty again

Or simply type skyscraper.dev/ in your browser address bar. Notice the slash; this will also make the browser aware of what you are trying to do the first time. Also, did you not manage to get things going with UniServer? Using the controller program that comes with it to create a vhost and edit the hosts file might be less confusing and less error prone for you. When going that route be aware that by default this will create a vhosts directory inside the UniServerZ directory where it expects you to place you project files (i.e. document root).

You could set the image field to be required, that way you're sure there's an image. However, checking it will be a good practise.

Thank you for your message, it was inspiration for me, when there is no image it gave error and i added if .. i did some thing like this and it works fine..... just can you check if its good?

// without testing, but you can get the idea here foreach ($page->children as $child) { $image = $child->image_top; $thumb = $image->size(300,300); echo "<li>"; echo "<img src='{$thumb->url}'>"; echo "<p>"; echo "<a href='{$child->url}'>"; echo $child->title; echo "</a>"; echo "<br />"; echo "<span class='summary'>"; echo $child->summary; echo "</span>" echo "</p>" echo "</li>"; }

I've been a long time fan of The Uniform Server. No installation, no registry settings. It just unpacks to a folder and is ready to go. You can setup vhosts from within the controller program, including editing the windows hosts file. You could just put it on a USB stick to always have a wamp environment with you.

Hi owzim, thanks for your reply. Maybe i should add, i installed multilanguage support after setting up the site & using hanna codes. Yes, exactly. The pasted code works everywhere but through Hanna text formatter after i installed multilanguage support. Multilanguage itself seems to work properly. I removed the closing tag but with no difference. Yes, thats right. Unfortunately, i guess my problem lies somewhere else since it seems to strip/add them anyway. Also, it did work before multilanguage. Just a simple loop here. *** I just figured out, the (body/textarealanguage) field seems to strip all html entities. No matter which formatters are applied and if content type: Markup/HTML is selected. Same with tinyMCE or Textarea Editor. Strip tags is disabled. **** another detail: the code (used with hanna) works with any other field like name instead of title (PageTitleLanguage works fine in any other usage on the site). echo "<li><a href='{$s->url}'>{$s->name}</a>, {$s->event_beginn} : {$s->event_ende}</li>";

Perhaps the core would be the best place for this - rather than having 3rd party modules depend on a helper class? Regardless of location of the helper class (core or via a module) I'd love to see an option for defining this via yaml or json as an alternative to PHP. In particular yaml is a very terse way to describe options. If the 'inputfieldType' entry had shorter 'type' alias and if you prepend 'Inputfield' to the type, you could get to something like this... prettySetting: label: Pretty Setting value: I am pretty type: Text awesomeSetting: label: Awesome Setting value: 2 type: Radios options: 'Option 1': 1 'Option 2': 2 'Option 3': 3 attributes: optionColumns: 1 But yaml does have some drawbacks - it's whitespace sensitive and not supported in PHP by default.

Yeah, I'll be there.

Ticket sale for Beyond Tellerrand Berlin (Nov 3-5, 2014) just started - let's try this mini ProcessWire meetup again!

When I skim through the existing modules I see some mundane tasks repeated over and over again. The implementation of tasks are quite different between the modules. Install pages, install templates, assign processes, making fields configurable, making modules configurable and so on ... I just stumbled upon a need to abstract common tasks/methods when I tried to have two process modules share similar functionality, so I created a base class. Then this module config thing came up and I created yet another class to abstract that stuff away from me and make it more flexible and easier to extend/update. Both methods would require me to boilerplate code, for use in every module I will create in the future. I hate boilerplate. It can get pretty messy. If I update the boilerplate it's outdated in places it has been used in. So a way better approach, I think, is to have the module helpers have in a separate module and my modules would depend on that. My question to you people is, would you use a Module Helper Module in you Modules? It certainly adds another dependency which might not be desired, so you modules can only be installed if the helpers are installed first. Is that too much? If not I would like to know what common tasks are out there when creating modules so we can create some kind of module helper suite. I am quite new do module dev, so I am only considering the stuff I stumbled upon already. Please share your thoughts on that. Cheers!

Hi apeisa! Thanks for your great feedback. Such good thoughts really help us, creating just the service, developers want and need. I totally agree with you. Minimize.pw was our first step in the ProcessWire ecosystem. We learned a lot from it, especially creating performant web services, that just work. With things like replication and auto-failover, I think we can guarantee a 99% working service. In the coming days, I'll post more information about how the service is going to work. And opposite to ProcessImageMinimize / minimize.pw, PassiveCron / cron.pw will have an extended open beta period before the first final release. We want to help web developers creating the site with everything they imagine, so this is the way to go. On this one, I'm also right there with you. If everything works fine - and I do think so - we have great ideas to follow up for large projects' needs.

Little update on the module. You can choose to list folders and or files. If you already had this module installed, be sure you check Hide folders and and save the field settings. Updated the first post in this thread.

@Manfred62 Thanks for bringing that up - gets me every time. Pushed new version with your change added.

tested latest version: the optimizing is nice and function well. for better translation use new line for the second string and better place the blank after the closing a (see code) 136: $warnings[] = '<a href="?owner='.__CLASS__.'&action=optimize&table='.$t_Name.'">'.$this->_('Optimize').'</a> ' . 137: $this->_('table to reclaim space and reorganize indexes.');

Being one of those rebellious few many that ignores the "cookie law", this amused me: As did their site here: http://nocookielaw.com/

Welcome! You are right, PW is more aimed at complex content structures but by no means limited to that. AFAIK most of Ryan's client sites are huge data behemoths (not meant in a negative way), so the core will never ship with built-in features you're talking about, and nor should they (keeps the core lean and fast), but that's not a disadvantage in any way. PW provides an amazingly flexible and powerful foundation, and that's where modules come in (in fact many of the core features are packed into modules themselves, core modules). Many of the PW users/devs here also use it for small sites, so I think there will always be an interest to serve those well too. There are couple of modules, that focus on small sites. Some that come to mind are those which provide dashboard like UIs, the Blog Profile, or the Blog Module and as you mentioned, Fredi. Also there is a very new InputfieldType, called InputfieldPageTable which essentially gives you huge amount of flexibility when constructing sites with content blocks, like for campaign sites or landing pages. Of course you are welcome to dig into Module development and enhance ProcessWire with those or contribute to existing modules. The API is incredible and you can hook into almost any functionality or process. Cheers!

https://github.com/adrianbj/ProcessMigrator and since you are coming from Wordpress, you might enjoy this plugin module for taking WP XML exports and importing them into PW: https://github.com/NicoKnoll/MigratorWordpress They are still possibly not quite release worthy yet, but with a little more testing, hint hint we might be ready to add them to the modules directory.

Continuing from my previous post in this thread about some selector enhancements available on the dev branch, we've got a couple more advanced options for use in selectors in case anyone is interested: OR-groups These let you specify multiple expressions and only one of them has to match in order for the selector to match. It's a way of saying "either this has to match OR that has to match". This is useful because selectors always assumed AND – meaning everything has to match. While you have always been able to use the pipe "|" to specify ORs for fields or values or both, the scope of it was just that field=value statement only. Now we have something new called OR-groups. These let you create multiple selector groups and only one of them has to match. You can specify OR-groups by surrounding selectors in parenthesis. An example demonstrates it best. Lets say that we wanted to find all "product" pages that were in stock, and either in a featured date range, or had a highlighted checkbox checked. Previously we would do like this with two separate find operations: $items = $pages->find("template=product, stock>0, featured_from<=today, featured_to>=today"); $items->add($pages->find("template=product, stock>0, highlighted=1")); Now we can do it in one find operation: $items = $pages->find("template=product, stock>0, (featured_from<=today, featured_to>=today), (highlighted=1)"); Above are two selectors surrounded in parenthesis. Only one of them has to match. You can specify as many of them as you want. This type of OR expression is something you couldn't previously do with selectors. Think of the parenthesis as a way of saying "this is optional". But of course, at least one of your parenthesized selectors has to match in order for the full selector to match. I'm guessing the above usage probably covers 99% of the situations where you might need it. But lets say that you want to have different combinations of OR expressions. You can create named groups that OR with each-other by specifying: foo=(selector1), bar=(selector2), foo=(selector3), bar=(selector4) In the above you'd replace "foo" and "bar" with names of your choice. And you'd replace the "selector" with any selector strings. Those foo/bar names aren't referring to fields, instead they are just named groups that you can name however you want. In that selector, at least one of the "foo" named selectors would have to match, and at least one of the "bar" named selectors would have to match. If you didn't use the foo/bar named groups here (but still used the parenthesis), then only one of the 4 selectors would be required to match. Sub-selectors Some of you are already familiar with these because it was committed to the dev branch a couple weeks ago (and I think may have been outlined elsewhere in the forums). Sub-selectors let you put a selector within a selector, enabling you to perform more complex matches that used to require you to use separate API calls. These can be used on the 'id' property of any field that maps to a page. The 'id' property is assumed when referring to a page reference or a parent, so it's not necessary to specify it unless you want to, i.e. "field" and "field.id" mean the same thing in this case. Sub-selectors are specified between [square brackets]. For example, lets say we are matching products and our product template has a "company" page field. Each company also has it's own page field where all the company locations are identified. Lets say we want to find all products that are made by a company that has more than 5 locations and at least one of those locations has "Finland" in the title. Previously we would have had to do it like this: $companies = $pages->find("template=company, locations>5, locations.title%=Finland"); $items = $pages->find("template=product, company=$companies"); That's easy enough. But now it's even simpler, as you can do it in one operation: $items = $pages->find("template=product, company=[locations>5, locations.title%=Finland]"); When you've got a "field=[value]" selector, any properties you refer to in "[value]" assume the "field", so "locations" above is referring to a property of the "company" field.

I'm under the impression that the Processwire license now requires you to narrate screencasts like a pirate so you might want to check that little detail.

Something like?: //populate a PageArray $articleList = $pages->find("template=article, limit=25") //next $page->next($articleList) //prev $page->prev($articleList) This assumes your articles have their own template. You can put more options, like sort, in the page selector. The http://cheatsheet.processwire.com/ is always a nice thing to check for options available.

Ok, I have added support for rendering the video in a Sublime Video player with: echo $page->video_field->eq(0)->play; Just register at sublime and enter your token on the config settings page of this module and that's it. I am not sure I am convinced about Sublime at the moment. I like the idea of a CDN approach to including the required file, but you can get mediaelementjs and other libraries through services like: http://www.jsdelivr.com/#!mediaelement Admittedly there is a lot more to include this way though. I think the main thing that puts me off about Sublime is how the process they take you through is designed to set up each video separately. Certainly you can just get the token for your domain and forget about the rest, but I would like it to be simpler. I have pushed this version to github, although I think maybe I should have made a separate branch - oh well. I am contemplating the idea of supporting several different players. Any thoughts on this, or how this new version of the module works?

Pete, this is possible and will show you one of the most powerful features of processwire. Doing this first time feels little strange, but soon you will see how convenient and flexible this is. You can achieve this with "Page" field. First you create page called "Type". This is just a container page and might be something you do not want to be accessible for public (maybe only for superadmins?). Sometimes you want to keep these under some other page, so url would be /tools/type/ or /settings/type/ etc. Under that page you create all your selections as pages. Developer, Publisher and Current Rights Holder would all be pages under "Type" page. It works with any template, but I usually have one "referencepage" template for pages that contain only title field. You might also create template called "type" (you might wanna add more details for type, like small description or icon.. anything). Now that you have your pages somewhere, it is time to create page field. Page field allows you to create one-to-many or many-to-many relationship between your pages. Add new field, and choose "Page" as a type. Then you just choose that "Parent of selectable page(s)" is your /type/ page (or /tools/type/ or wherever you put it). Alternatively you could choose "Template of selectable page(s)" if you have dedicated template for wanted selections. And finally you can select "Input field type" where you find "Checkboxes" or "SelectMultiple". There is also asmSelect which is custom field that pw uses a lot internally. It also allows multiple selections. This might seem like a lot of work or complicated, but once you do this and realize all the superpowers that it brings, you'll never look back PS: If you already knew this all and you were just looking for quicker alternative, then I'll keep my answer as a future reference.