Leaderboard

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

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!

Aesthetics is something subjective, some people will like the changes, some won't. Some people like the new mac laptops, other people would prefer that they would still be like this: Actually I like both, I remember I loved those laptops at the time. What I never ever liked was this: or this: or this: And I'm oh so happy to see them go away!

HELLO! My new portfolio website is nearly finished and I would love some feedback and bugs if anyone has a moment. Built with PW using mixup.js, ajax, loaded.js, tons of css transitions and some custom slideshow and canvas bits. currently here http://benbyford.com/dev/new/ but will be moving it soon to replace http://benbyford.com Thank you!

Oops, forgot to mention the setting in /site/config.php See here : https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/config.php#L238 On mobile...sorry about the lack of details

It's supposed to be fast, up to 7 times faster than Markdown PHP 1.3, see http://parsedown.org/speed https://github.com/owzim/TextformatterParsedown

Might work, but your markup is not correct, since you have something outside the <li> tag in a <ul>. <ul> <li> <a></a> </li> <ul> ... </ul> ... </ul> not good. My code with a very small change: http://jsfiddle.net/dXxtD/9/

I've never really used a Mac. The few times I have (one time because someone had the only copy of Photoshop on it in a small company) I was told it was bulletproof and never goes wrong. I'd crashed it within a few days just using Photoshop. I suspect it was a slightly ageing Mac, but I'm quite skeptical about hype and still don't get why at either Windows or Mac launches the crowd cheers even for features that are bog-standard - especially when it's nothing new or innovative. I would love it if they were forced to launch in front of real critics. Not haters of either camp, but people with a genuinely open mind. What I really hate about the internet is you can find a zillion iPhone 6: What You Need To Know "news" posts filled with conjecture that seem to keep those news sites alive (and I bet we get a lot of hits just because I typed that phrase in here - I'll keep an eye on Google Analytics ). Everyone gets over-excited about... well... things that aren't a big deal lately, and all the big players are just suing each other. Something I do admire about Apple is free OS upgrades - certainly a good way to increase adoption of a new system. That said, you're paying way over the odds for the hardware purely because of looks, so it's nice to get something for free now your wallet is empty Personally, I have had several iPhones because at the time they were the best - right up to the iPhone 4 where "you're not holding it right" forced me to conclude "you're not building and/or testing it right" so my next purchase was a Windows Phone. Then I moved to Android because Windows Phone reminded me that less mature systems just don't have any of the apps I want (although that may have changed in the last 6 months). I develop/design and play games on a Windows PC. It's custom-built and boots in about 8-10 seconds on Windows 8.1. Despite all the hoo-hah about Windows 8, it is faster and more stable than 7 so I can forgive them their little quirks with the new design (I literally just use the Start screen for searching - what it was intended for as the Start menu replacement - and placing quick launch links, I don't have much use for the Metro apps). The desktop is still there, my apps still run, quicker in fact, so I'm happy with what I've got. "To each their own" and all that Something I have invested in recently is a Synology NAS box to store media on. It also serves as a web server so I can get it to grab website backups - not that I don't trust my hosting company, but you can never be too careful with backups so having something set up to grab me local copies without having to leave my PC on all the time is nice.

Thanks for posting. I see nowhere on that whole thread any instruction to put anything in "/wire/modules/". Ryan especially wouldn't say that ....What the post says, in short, is that if you want a menu link to appear somewhere in the main Admin menu, just create a new child page of Admin. It will automatically be listed up there with 'Setup', 'Pages', etc. Of course, that link leads somewhere...e.g. a ProcessModule. In that case, the page will normally be created within your ProcessModule on install and not you doing it manually...

Welcome to ProcessWire Jordan!

Jordan, in a bit hurry, but just wanted to quickly comment: very well said about in what position PW is regarding "heavy content" vs "easy editing". I think the best route will indeed be on building simpler tools to provide different tools on top of core, just like owzim said. I am happy to hear what kind of ideas you have regarding Fredi and making simple sites even easier for editor? Before I build Fredi, I played a lot with "real" live editing. That is easy for text and textareas, but falls short when trying to support all the different field types that PW has - and that is definitely one of the key selling points for PW.

Introducing ProcessWire ProFields: Table – it lets you literally define your own Fieldtype! This is one of the most exciting ProFields and it's something very different than any other Fieldtypes. I think it is best described by this screencast (be sure your sound is on): Special thanks to Joss for his great voiceover on this screencast. Please view the video at 720p and full screen if possible. Read more about the Table Field Table is part of the ProcessWire ProFields package now available for purchase in the ProcessWire store.

Currency Conversion for ProcessWire This module is designed for performing currency conversions among ~165 world currencies. It uses OpenExchangeRates.org (or compatible) for data so that currency exchange rates are always up-to-date. It provides various API functions that you can use to convert from one currency to another. This is especially handy for generating rate tables in multiple currencies or giving users of your site the option to see prices in their currency. How to install How to use API documentation Modules directory page GitHub Page Download ZIP Live Example Requires ProcessWire 2.4.0 or newer. To use the quick-installer from your modules screen, paste in ServiceCurrencyConversion. Basic Example $cc = $modules->get('ServiceCurrencyConversion'); $dollars = 100; // amount of currency we want to convert $euros = $cc->convert('USD', 'EUR', $dollars); echo "<p>$dollars US Dollars equals $euros Euros</p>"; For a live example of a currency conversion tool built with this module see the included convert.php file and test it out here.

Introducing the AutoLinks Text Formatter, part of the ProcessWire ProFields package of modules. What it Does This Textformatter module automatically links your specified phrases/words to your specified URLs. This is an excellent SEO and accessibility tool for creating automatic contextual links with little effort. If there are pages that you commonly link to in your site from your textarea/rich text fields, then this Textformatter can save you a lot of effort, automatically linking to those URLs. Furthermore, contextual links of this sort are also considered especially valuable from an SEO context. Because this module is a Textformatter module, the work it does happens at runtime. That means that this module can easily be applied to existing sites, no matter how large. Usage Example We'll use processwire.com as an example. Throughout processwire.com, we routinely use the terms "API", "selector", "template", "template file", "$page", "$pages" and more. In the past, I've spent a lot of time in TinyMCE manually linking these terms to the appropriate pages, as it is a helpful cross-reference for users. For example, when the term "API" appears, I want to automatically link to the API Cheatsheet page at http://cheatsheet.processwire.com. With the AutoLinks Textformatter module, I can now automatically link to all my important terms from all existing and future body copy. If one of those links happens to change in the future, no problem, as I only have to update it in one place (if at all). The benefits here are a real win win for the users of processwire.com, myself (in time savings) and our performance with search engines that analyze these contextual links. We hope that you find AutoLinks to be a huge benefit to your site(s) and time saver for you and/or your site editors. AutoLinks is available for purchase as part of the ProFields package in the ProcessWire Store.

I'd like to share and discuss some things I've come across maintaining the German translation. Ryan has outlined a way to get the translatable files in PW: http://processwire.c...__20#entry11232 — while this does work, it's not very comfortable. It would make translations much easier if there was a way to get those in the backend, as well as maybe detect which translatable files are new or abandoned. For instance, I think InputfieldRadiobuttons just got moved to a separate directory, making the previous translation file uneditable. I think it would also be good to have different "states" for empty fields in translations. As of now, "empty" could mean "not translated yet" as well as "doesn't require translation, can fall back to English value". Updating a translation would be easier if one could just skip the values which don't need to be translated, but obviously, this would be nice to have. It's definitely not a must-have. Which brings up the question as to when to actually update a translation. Obviously, doing that constantly as changes are committed to GitHub is insane. So it would make sense to update translations based on a release. As far as I have followed PW development, there is no alpha/beta stage, right? It would be nice to have some phase before a release where nothing new is added so translations could be updated to be ready along with a new release. Another thought: Let's say I install a translation for PW 2.3 in a PW 2.2 installation (or vice versa). Are there going to be any "side effects"? Should we maintain versions of the translations for specific PW releases? Most pressing issue in my humble opinion: currently (as far as I can see, please correct me if I'm wrong), there's no "protection" for additional translations added. Let's say I install a translation, then I add some translations of my own, maybe related to the templates of the site or some help texts in the descriptions of fields. Then I update PW and the updated installation. In that case, all my additional translations will be overwritten by the updated translation, right? If so, there should at least be a way to backup the additional translations, although I figure this could be hard to implement given the JSON format of the translations. Oh boy. Sorry for rambling here, I hope this makes some sense.

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!

Today the second site out of a series of 4 went online. This project is a bit different than the usual websites I do. The client had 4 websites, 3 of them running on a very old school proprietary CMS and one on MODX Evolution. I developed a layout which gets adapted by all three of them with minor differences and functions. I am running these on one installation of PW with the multi site module "Soma edition", originally by Apeisa. No problems so far with that. I imported around 1500 documents for both of the sites by fitting the CSV importer module to my needs. I could also manage to import images/PDFs which were hard coded in the shitty CMS by extracting the src from the markup. The PW-API surprised me a lot while doing this, just try&success ;-) The sites share a lot of templates, I tried to build it as modular as possible. As always, the CropImage module is loved by the clients and it also serves different image sizes for the sliders, while the picture polyfill loads the correct one dependent on the visitors screen size. The only thing I am struggling at the moment is the performace of the backend. Sometimes no problems, sometimes significant loading times. I am not quite sure if this is a server performance issue or is something related to PW. I also customized the backend a bit for quick create/edit pages: Ryan, if you read this: Do you think it is possible to get ProCache up and running for multi site environments? I think it would be a good benchmark, because the last site which gets converted will be the biggest one. And I am a bit concerned about perfomance (will be 10000+ pages). So, here are the two (warning: german and pretty boring, something with public vehicles and something with pests & ugly banners): http://kommunaltechnik.net http://schaedlings.net

Hello PW community, A website redone for a friend in my hometown. after hours and hours research in the forum, struggling with the API, answers from nice and competent people I hereby present one of the things I've created with Processwire. I've seen nicer websites, but so far we're happy with the result. Used modules: Thumbnails Text formatter BB code [just for fun - the smileys] Page Tree Childs Reserver Customn Upload names VideoThumbsmodule the whole site was originally done in another CMS, so I've used the import pages modules too.... Comments, critics, always welcome, but please be nice Thanks in advance http://www.belaey-trials.be Regards.

Not sure about EOT (so much so that I removed it from the example above) but I'm using the example to echo out a mix of HTML and PHP with loops, etc. I'll post what I've got in the original thread when I get chance if that's of any use?

Hi everyone, Thank you so much for your comments and your warm welcome to the community! @apeisa, I think you are referring to the difference between "front-end editing" versus "inline editing" (I read a forum thread about this here for ProcessWire but I cannot find the link now) -- and I agree that true inline editing is very difficult to do, but the way Fredi works now I think is very good (pop up the editing interface in a dialog box). I think it would be nice if there were more options on the $fredi object. One example is if you could set the width and height of the dialog box. Another thing is if you could utilize more complex markup (almost like providing a small template for the fredi "edit" link itself, instead of only being able to customize its text) because then you could do things like put a border around the editable area and make the whole thing "clickable" (which is how Concrete5 does it, and I think it very intuitive because people do not have to search the page for a small "edit" link, and also because it requires less tweaking of the page layout becaue it is just adding a 1- or 2px border as opposed to a new link which could push elements down or sideways on the page). Also, it would be nice if there were a way to change a page from "view mode" to "edit mode" (although I think this is possible if you write your own javascript to show/hide the ".fredi" classes, but would be nice if it were more built-in). One question I have is about "draft" or "preview" mode on pages. I know that you can create a new page and keep it in a "draft mode" (so it does not yet appear on the live site), but when you make more changes to a page that is already live, is there a way to keep a separate "draft" version of it so that the logged-in user can make some changes and save the page but without publishing those changes to the live site? Overall I see that the correct way to do things in ProcessWire is by writing modules (as oppoed to adding a lot of features to the core). I think this makes a lot of sense and when I start using PW for real projects I will keep this in mind. About the "file manager", are there hooks in the PW system that would allow me to add to the Rich Text Editor's "Image Insertion" feature so that instead of listing images on the page, it could list images in a custom "file manager" object I could create in my own module? I really dislike the 2-step process of adding images to another field on the page before you can insert them into a rich text area (but I understand that some people like this, so I am not saying it is bad -- but it is not what I prefer). Thank you all again, I look forward to discovering more about how ProcessWire works! -Jordan

No, naming modules ProcessXxx doesn't move them to core tab. You probably saw it in core tab if you had it in wire folder first - module information gets cached. Also filename and classname should match. In your case ProcessReadCsv.module and class ProcessReadCsv

I'm also in with a little inspection and think there might be solider ways to do it. But this is now sponsored?

Bingo. That's precious, tricksy hobbitses.

I think skeumorphism maybe had a place in GUIs in the early days, but should have been gone long ago. One of my pet peeves is page turning effects - we are not reading a paper book anymore people That said, I do think Apple may be going too far in its dumbing down of the desktop OS, but I have stuck with Lion, so maybe I don't know what I am missing I like diversity: Macbook Pro (I need to be able to run both OSX and Windows, so this is a necessity for me) Android phone - awesome - love the freedom Sonos music system - again nice not to be tied into the Apple ecosystem

Please think carefully about using captchas - they are a horrible user experience and not really that great at preventing spam anymore anyways. Consider a honeypot or similar approach instead: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/?p=41795 https://processwire.com/talk/topic/960-comment-spam-filtering-alternatives/?p=8097

$user->isLoggedin() shouldn't be necessary here as $page->editable() already checks for various permission etc. So maybe do you have the guest role given page edit access? What happens if you click the link? Well I'm waiting for a facepalm here cause it's not possible.

$field->attr("disabled", "disabled");

This will echo out all the textformatters for the body field: $f = $fields->get("body"); foreach($f->textformatters as $tf){ echo $tf; } Hope that helps.

You can used a hidden field: $field = $modules->get("InputfieldHidden"); and set the value to whatever you need and process that with the rest of the form. As for collapsing fields: $field->collapsed = Inputfield::collapsedBlank; and you can use all the options from here: https://github.com/ryancramerdesign/ProcessWire/blob/03387f8283d518e9cc405eff8f05cd6a5bf77c4c/wire/core/Inputfield.php#L56

Thanks @diogo and @Soma, I'll fiddle around with the process module approach then. @pwFoo thanks but the method you're talking about is used in templates, even if it's callable in modules (perhaps it is) with $this->config->ajax, all modules other than process modules don't have a page/url per se, so neither do input fields, that's why I asked how to have some code logic that's callable via url.

@Jonathan: looks good! Thanks.

I had a dream last night that Jonathan updated the module. When i woke up i realize that was not a dream . It works now for me. Thanks for your work...

Of course, there's always the simple typo maybe? Edit: Duh to self!!! You have to use isset() to first check if a variable has been sent $pass = $input->post->awesome_password; if (isset($pass) && $pass != $page->page_password || !$pass)//....show form etc...

Thanks for all the responses guys, I copied in the code SiNNuT posted and it (almost) works perfectly. It's throwing up this error - Notice: Undefined index: awesome_password, if anyone can shed any light on what this means I'd appreciate it. On a related note, is the content on a private page going to be crawlable by Google et al's bots?

Yeah, I like PW api and module / hook concept Learned a lot! rebuild my (dev) module with key features: register login, logout used hooks to create a profile page after register and send a activation email profiles handled by pages (simple pages with different template) use form api and csrf token to generate form fields, but forms rendered with template files (templateFile class) Code examples to build the module found here at various forum topics. Register, login, logout and profiles working, but its not useable as is at the moment

I'm pretty sure that I've mentioned this somewhere around here earlier, but I tend to refer to usage statistics when discussing supported browsers. Define a minimum usage percentage ("at least 4%" for an example) and if a browser is below that limit, it shouldn't be too hard to convince the client that it's simply not worth it spending a lot of your time and their money fixing things for browser barely anyone uses anymore.. or, if you prefer to be sure, discuss that with the client beforehand and make sure that it's mentioned in your contract. StatCounter is my current favourite when it comes to things like browser usage statistics; their data seems relatively trustworthy and they offer very good tools for filtering and displaying it (and even allow saving it as an image, exporting a CSV etc. for archiving or whatever other reasons). That's what the statistics from last 3 months look around here. Based on that alone I'd say that it's really not worth it to support IE8 (or 10, which people seem to have pretty much skipped). IE9 is a borderline case, so I'd only offer support for it if it's very important to the client (they're a large organisation using IE9 or have such organisations as clients etc.) .. oh, and did I mention that I just love statistics?

ASAP i will provide german language files... Great Work!

You have some problems with your html, you should clean all the useless classes and ids. the #sub id is even repeated, and ids should be unique in a page. Is this what you want to do? http://jsfiddle.net/dXxtD/1/ I kept the html as clean as it could be, but you don't have to go to that extreme

Update: Blog version 1.2 Read below before updating. For new installs, proceed as normal ------------------------------------- Changelog TL:DR: Comments visibility settings + Posts' Bulk Actions + Update Script Comments Comments visibility can be controlled 'globally' as well as on a 'per post' basis Default is that comments and comment form are visible. You do not need to specify this setting; it just applies A post's comments SPECIFIED visibility overrides the global setting except for one case (see below). Post Comments Settings are set via a page select on a Post's page (also in 'Settings' tab in Blog Dashboard - see below) No selection: Default [comments and comments form will be shown] Always Show Comments: This will enforce overriding of global setting (e.g. Disable Comments) Disable New Comments: Will show old comments but not the comments form; visitors will not be able to submit new comments & message 'Comments closed for this post' will be shown. Disable Comments: Will neither show old comments nor the comments form; visitors will not be able to submit new comments & will see message 'Comments not allowed for this post'. Old comments WILL NOT be deleted . Global Comments Settings are set via a page select on the Comments page (in Dashboard as well). Settings here DO NOT override a Post's Comments settings WHERE A SELECTION has been made (i.e. if NOT empty). No selection: Default [comments and comments form will be shown] Disable New Comments: Similar to above Post setting except will affect all Posts' comments where no comments visibility selection has been made. Disable Comments: Similar to above Post setting except will affect all Posts' comments where no comments visibility selection has been made. Global Maximum comments allowed per post. If any number > 0 is specified in this new setting, IRRESPECTIVE of a Post's comments settings, if a post's comments is greater than the maximum set here, then 'Disable New Comments' will kick in. So, this takes precedence. Note: If you are logged in as superuser, even PENDING and SPAM comments are counted; so, the Global Maximum may be 'temporarily reached', if that makes sense Recap of comments visibility, in order of descending priority: 1. Global Maximum comments allowed for posts (/blog/comments/) 2. Any comment visibility SPECIFIED on a post (i.e. not empty) (/blog/posts/your-post/) 3. Any Global comment visibility SPECIFIED on comments page (/blog/comments/) 4. Default. 'Settings' Tab You can also set both the Global comments visibility and the Global Maximum comments allowed per post on this tab. The current setting will always be selected in the input field. Note: A blank Global comments visibility means no setting specified . So, if you want to change to 'no global setting specified', just select a blank and save [equivalent to deselecting a page select] (hope this makes sense). Note: Where no Global Maximum comments is set (i.e. blank), saving in the 'Settings' Tab's General Settings will subsequently show a '0' [zero]. This is equivalent to a blank, so not to worry Bulk Actions Introducing Bulk Actions for the Posts Tab! Make bulk changes to posts: Unpublish/Publish Comments visibility (as specified above for Posts' Comments visibility). In this case, also a 'Default Comments View' selection available. This is the equivalent of the 'no selection' specified in page selection field above. Trash Delete (note: no warning given before delete; careful with this one!) New column in Posts' Table also shows currently specified Comments visibility for each post. 'Default' means no selection made. Other - Some code clean-up. - See blog-side-bar.inc issue below. UPDATING I have written an update script (attached) that will add the new features in Blog 1.2 (2 fields, 1 template, 3 pages, 2 page updates, etc.). I have thoroughly tested the script. However, try this first on a test/non-essential install! If everything works, you can use it on your live environment Note: This assumes you haven't changed the native Blog paths and page names. Otherwise, it won't work properly. It won't corrupt any data but may just not install some stuff Note: You will still need to update the module as normal in your PW admin! Above is just to save you manually creating the extra fields, etc. To update: # Copy and paste the contents of blog-upgrade-version1-2.txt at the very top of one of your template files. Save the template file. # The script will only run if you are logged in as a superuser so other users won't know what's happening. # View a page using the template file you've just amended. The new fields, template and pages will be created. # Reverse the changes to your template file and save. # Update Blog via PW Admin as usual (to version 1.2) # Copy blog.css to /site/templates/css/. blog-upgrade-version1-2.txt If you are using the blog-side-bar.inc you might want to make/note the following changes. This only affects existing Blog installs! (not new ones) There was a missing <br> tag + $item->date instead of $item->blog_date. This will ensure Recent Comments widget also show the Post's date. If you are using the code from this file, you can make the following changes: OLD: $date = $blogOut->formatDate($item->date); $out .= "<li><span class='date'>$date</span> <a href='{$item->url}'>{$item->title}</a></li>"; NEW: $date = $blogOut->formatDate($item->blog_date); $out .= "<li><span class='date'>" . $date. "</span><br> <a href='{$item->url}'>{$item->title}</a></li>"; In addition, the code has now been changed not to show 'recent posts widget' on the blog home page. @Adrian idea, thanks! Screens Happy blogging!

Hello, I created this website just for fun. It's a collection (very small right now) of free high resolution photos, free to download and free to use also for commercial purpose. I hope this website will grow with a contribution of other photographers. http://lymeta.com

It's more efficient to do it in one find() operation, using the new options available. When using two separate find operations, all the pages from the first find() operation have to be loaded. When you do it in one find(), then those pages don't have to be loaded. So it can actually be a whole lot more efficient, especially if dealing with larger scales. There is still some room for optimization so I'll be working on that, but regardless they should be a lot more efficient than multiple find operations. Another good reason to use OR-groups (and sub-selectors, depending on the case) would be for pagination. You really can't achieve paginated results very easily if splitting into multiple finds.

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.

BBEdit from time immemorial.

Hey, I finally had the chance to use PW for a german shop. And let me tell you setting up an online shop under german law is the worst. For example there are different taxes for different products (7% on book and stuff 19% on everything else). And you have to apply this tax even on shipping costs (like shipping costs tax for books 7% ...). And you need to have checkbox you have to check that you "read and understood the "general business terms". And your bux button has to say "buy" not "complete checkout". It has to be "buy" (or something similar). So I had to do some core hacking of the shop module. but it works now. Take a look: www.oliver-mark.com/shop/ -- Nico

I'd love for ProcessWire to have this feature. Are there any plans for work on this module to continue?

I've never come across a client that didn't prefer a rich text editor to the alternatives. The reality is, they like RTEs because it's something they are already familiar with and it's easy for them to use. So I think a better goal is to give them what they want, but place limits upon it so that it can't produce a mess. Just because RTEs+clients can create a mess doesn't mean we have to let them do it. Both our TinyMCE and CKEditor rich text inputfields come very much restrained and prevent the client from creating a mess. CKEditor4 and it's ACF (advanced content filter) seem particularly adept at solving this problem. If you can convince a client to use an LML (Markdown, etc.) or some method of creating content in blocks, then that's fine. But once the next guy comes around showing them "look what you can do in my CMS–it's like using Word", you may be at a disadvantage. Other factors to consider: 1) content maintained by blocks may be significantly less portable through future CMS changes, web service/syndication feeds and such; 2) it may be more difficult to maintain site-wide consistency with the designer's original vision if a site's main content area is a mashup of content blocks. Personally, I would avoid trying to pursue a blocks strategy for most content editors, whether in a CMS that is built around the concept, or via trying to build everything around Hanna Codes. Instead, let the designer do their job and determine consistent and well thought placements for photo galleries, navigation, etc. I see Hanna Code as being better for the exceptions of needing something somewhere, and not something that editors should have to keep as part of their vocabulary.

Just curious - you say that you want to make the title field unique, but in your code you are trying to set the value of the invoice_number field. This should do what you want, assuming you actually want to set the title field. <?php class MarkupTitleField extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'Markup Title Field', 'version' => 100, 'summary' => 'Set the title field to predefined value', 'singular' => true, 'autoload' => true, ); } public function init() { // add before-hook to the inputfield render method $this->addHookBefore("Inputfield::render", $this, "renderField"); } public function renderField(HookEvent $event) { // // get the current field $field = $event->object; if(($field->name == 'title' || $field->name == '_pw_page_name') && $field->value == '' ) { $last_page_id = wire('pages')->get("include=all,sort=-id")->id; $id = date("Y") . "/" . ($last_page_id+1); // example for a possible id value $field->set('value', $id); } } } Edited code to get the id of the page that is about to be created. Not sure if this is completely robust. You might want to consider a different unique identifier.

Just found another really interesting lightbox. Magnific Popup is a free responsive jQuery lightbox plugin that is focused on performance and providing best experience for user with any device. It's build for speed and seems highly customizable through css (and not javascript like most).

I was thinking this at one point, but the project was cancelled so I didn't get into implementation part. It had the special need, that the recurring event need to be it's own entity (it might be same event, but different time - but also it might be in different place, have different price etc). How I started to approach the problem was to have "events-item" template which could have children with template "events-instance". Events instances would inherit most of the data from their parent event, but could override some parts of it. And how I would have implemented is that when saving the "event-item" you could make some selections "Repeat once a week, until <date>" and that would create the required amount of instances as children. Pretty simple actually that way.

I'm working with a events calendar myself, though I elected to take a more service oriented approach using google calendar and outlook generated *.ics feeds. If your calendar is going to be as simple as you describe, you might be able to get away with the following approach. Set up three datetime fields - event_start, event_end, and recurrence_end. Set up a text field, recurrence_rule (rrule). Add the PHP When library to your project. For recurring events, set your rrule based on byweekday, bymonthday, etc. You can generate rrules with a google calendar (add a recurring event and look at the ical feed) if you're new to them. For the range to be displayed (e.g. today + 3 months) you can use the api to get all events that have start/end OR start/end-recurrence overlap with the displayed range. Set up an array and loop the events, using PHP When to generate a list of occurences if an rrule exists, push rule occurences and non-rrule events in as as siblings, sort by event_start/occurence_start. Render the list of occurences. That's the basic formula anyways.. If you are avoiding google only because of the look of thier embeded calendars, you might consider rendering your own calendar of events with PHP When and the raw icalendar (*.ics) feed they provide. Edit: grammar.