Leaderboard

This module allows you to automatically rename file (including image) uploads according to a configurable format This module lets you define as many rules as you need to determine how uploaded files will be named and you can have different rules for different pages, templates, fields, and file extensions, or one rule for all uploads. Renaming works for files uploaded via the admin interface and also via the API, including images added from remote URLs. Github: https://github.com/adrianbj/CustomUploadNames Modules Directory: http://modules.processwire.com/modules/process-custom-upload-names/ Renaming Rules The module config allows you to set an unlimited number of Rename Rules. You can define rules to specific fields, templates, pages, and file extensions. If a rule option is left blank, the rule with be applied to all fields/templates/pages/extensions. Leave Filename Format blank to prevent renaming for a specific field/template/page combo, overriding a more general rule. Rules are processed in order, so put more specific rules before more general ones. You can drag to change the order of rules as needed. The following variables can be used in the filename format: $page, $template, $field, and $file. For some of these (eg. $field->description), if they haven't been filled out and saved prior to uploading the image, renaming won't occur on upload, but will happen on page save (could be an issue if image has already been inserted into RTE/HTML field before page save). Some examples: $page->title mysite-{$template->name}-images $field->label $file->description {$page->name}-{$file->filesize}-kb prefix-[Y-m-d_H-i-s]-suffix (anything inside square brackets is is considered to be a PHP date format for the current date/time) randstring[n] (where n is the number of characters you want in the string) ### (custom number mask, eg. 001 if more than one image with same name on a page. This is an enhanced version of the automatic addition of numbers if required) If 'Rename on Save' is checked files will be renamed again each time a page is saved (admin or front-end via API). WARNING: this setting will break any direct links to the old filename, which is particularly relevant for images inserted into RTE/HTML fields. The Filename Format can be defined using plain text and PW $page variable, for example: mysite-{$page->path} You can preserve the uploaded filename for certain rules. This will allow you to set a general renaming rule for your entire site, but then add a rule for a specific page/template/field that does not rename the uploaded file. Just simply build the rule, but leave the Filename Format field empty. You can specify an optional character limit (to nearest whole word) for the length of the filename - useful if you are using $page->path, $path->name etc and have very long page names - eg. news articles, publication titles etc. NOTE - if you are using ProcessWire's webp features, be sure to use the useSrcExt because if you have jpg and png files on the same page and your rename rules result in the same name, you need to maintain the src extension so they are kept as separate files. $config->webpOptions = array( 'useSrcExt' => false, // Use source file extension in webp filename? (file.jpg.webp rather than file.webp) ); Acknowledgments The module config settings make use of code from Pete's EmailToPage module and the renaming function is based on this code from Ryan: http://processwire.com/talk/topic/3299-ability-to-define-convention-for-image-and-file-upload-names/?p=32623 (also see this post for his thoughts on file renaming and why it is the lazy way out - worth a read before deciding to use this module). NOTE: This should not be needed on most sites, but I work with lots of sites that host PDFs and photos/vectors that are available for download and I have always renamed the files on upload because clients will often upload files with horrible meaningless filenames like: Final ReportV6 web version for John Feb 23.PDF

Just realized that Teppo's awesome blog isn't mentioned here yet: http://www.flamingruby.com/blog/ and really recommend it's new hooks post: http://www.flamingruby.com/blog/using-hooks-to-alter-default-behavior-of-processwire/

Are you guys aware that Bitbucket offers ilimited private projects for teams up to 5 collaborators for free? It's pretty awesome actually

This is specific to the PW blog profile -- after adding the new template for the widget, you'd go to Pages > Tools > Widgets > new. Add a new page in there called Google Plus, using the new template you just added.

Trust me, Ryan, I never pop! Sorry I have not been around. Couple of distracting bits going on earlier in the year and I was away a bit (serious glamping!) and also been working on an album for a publisher. My web activity has dwindled to nothing! I do have one little project for an angling club coming up, however, and of course I will be using Drupal, Wordpress, Joomla ... PROCESSWIRE for it. I suppose I should, as an amateur, stick to those things with thousands of clunky plugins, but for some reason I want the site to work and be more or less maintenance free. Fussy me. Hugs all round.

Hi Everyone, the last days i read a lot about the ongoing process of "modernizing" the admin theme, adding some features and getting some marketing buzz from people who aren't currently aware of processwires awesomeness due to the fact they didn't like the current admin theme. I must admit that at first was one of those "design oriented" guys and didn't dig deeper into the system because i didn't liked it's look & feel (or at least i thought it doesn't look "professional" enough to present it to our customers). Fortunately a colleague of mine finally managed to convice me giving pw a second try. After digging deeper i started to really like the concepts behind it. I tried different admin themes and git stuck with "ergo" which we currently are using on several pw instances. Although i weren't completely happy with it's look and feel on several details (but that's just me: i never heard one of our customers complaining ). The Idea of doing a theme by myself started to grow in my mind. After doing several layouts that "just beautified processwire to my taste" (i can post a "design evolution summary" if anyone is interested) i took a step back and started doing some more conceptual work and research. Specifically i thought about which "personas" are using processwire and for what reasons they are using it. Also i tried or looked at screenshots of some more "hyped" systems (ghost, anchor, craft...), asked out some (dev) co-workers and others who are content editors (which are the two main "groups" of personas imo) what parts of processwire could be done better or used in a more efficient way. The good (but not surprising) news is: There were almost no complaints about the current features. Long story short: With the "benchmark" in mind and some feedback i again started layouting. I rearranged some buttons, menus and tried to give processwire a more modern, clean and "up to date" look. But before i'm going to code all of this i wanted feedback from a broader audience so i can propably fix or correct things that you as everyday users aren't happy with. Here we go: I used the "w" of the processwire logo as a "picture mark" as it is pretty unique and can easily be recognized and remembered (You could also use this as a favicon). I kept using "processwire colors" for brand/product recognition (i know ryan stated people are complaing about them) but also tried to use them in a very minimalistic way so there is nothing that distracts editors from the content. I chose the menu to be positioned right for two reasons:1) Content first! The most part of work in processwire is editing and creating content. So why shouldn't content "rule" and be the first and most important thing (at least for LTR Readers)? 2) With the buttons and the menu both at the right side there is a "cluster of functionality" which makes it more efficient: Shorter ways for eye- and mouse movement, less things to "overlook" when actually editing content. The pages options within the tree are hidden (again: reduce visual complexity) into a dropdown with only the most commonly used one (edit) beeing shown (this should be configurable). The Font is the beautiful Fira from Mozilla <3 The messages are displayed "growl style" and can easily be closed by the user (or close themselves after a certain amount of time) I chose to use the content of ryans "new theme" example screenshots to make it easier comparing them in terms of visual hierachy. As you scroll, the buttons on the top will pin and scroll with you. This way it's always possible to save or view the page at any scroll position (the save/publish buttons are part of a module that's currently in devlopment here). The bar at the bottom will contain some shortcuts as well as less frequently used / system related stuff (i.e: user profile and logout). "Zen Mode" with closed menu. Just you and your content For those who like it bright: An example of an alternate version which is even more minimalistic.From my point of view there are some things still missing. I thought a lot about including a possibility to open the page tree from everywhere (as in Nico Knolls Dark Business and the ongoing Discussion in the Two column admin theme concept). I think this might be more effective to just test it from a ux perspective when actually coding the theme. My Idea is to build a static clickdummy and put it on github before actually releasing a "real" theme (with all the logic / js work to be done) to do some usability testing. Thanks for reading and i hope there will be some feedback! Best regards, Felix

I'm sure someone may already have posted this somewhere but I've only just come across it myself: http://www.opera.com/developer/tools/mobile/ Very handy as I only have an iPhone to test mobile sites on, plus this will test some tablet sizes too

Ok, I was mistaken by this If bfd_month is a page field bfd_month=11 will search for the page with the id 11. If 11 is the name of the page you should use bfd_month.name=11 instead.

That rule was added to correct the input fields funky behaviour because of the borders, so maybe the best things is to apply the border-box only to them. input, textarea { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; } We could go a bit further and apply it to all the direct children of .InputfieldContent. I think I prefer this option. .InputfieldContent > * { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

If I'd have said Comic Sans, then I would agree with the last part I do see your point of view, and I am not a designer per-se. But I often take a more functional approach, rather than purely aesthetics. The Arial, Helvetica, sans-serif font stack works, and has done for a long time and in many designs and situations. Its use case here - in the control panel - (in my opinion) is not one of the situations that demands or calls for a webfont just because.

Using the latest dev branch, it still renders badly on Windows in Chrome and FF (but FF being the better of the two), particularly the bold sections. If the CSS is changed so that the SVG file is referenced before the others (I think this was mentioned/linked to earlier in this thread) then Chrome handles it a bit better; but with the side effect of the text not quite as clear as it should be. See the screenshot attached. On the left is the "Edit" page with the SVG font reference at the top in the CSS, and on the right is the same page, but with all of the webfont references removed from the top of the CSS - falling back to the default system fonts. In my opinion, there's nothing wrong with Arial, Helvetica, Sans-serif CSS example: @font-face { font-family: 'Arimo'; src: url("fonts/Arimo-Regular.eot"); src: url("fonts/Arimo-Regular.svg#Arimo") format("svg"), url("fonts/Arimo-Regular.eot?#iefix") format("embedded-opentype"), url("fonts/Arimo-Regular.woff") format("woff"), url("fonts/Arimo-Regular.ttf") format("truetype"); font-weight: normal; font-style: normal; }

This should do it too (slightly modifying what diogo proposed at first and what I guess Wanze was saying as well): $q = str_replace(" ", "|", $q); // find pages having at least one of the words both in author field AND in title field $results = $pages->find("author*=$q, title*=$q"); Plus some sanitation probably.

Good to see you here Joss!! If Teppo keeps this up, we'll just have to add a new docs tab on processwire.com that goes straight to his site.

Are you wanting to store just the selector (text) or both the selector (text) and the resulting page IDs? I'm thinking just the selector text, since the resulting pages may change ... that's what's kind of unique about storing the selector string, as the results of it really couldn't be known until runtime. If that's the case, then I don't think there would be any reason to extend FieldtypePage, as it is heavily geared towards storing IDs of page (references). Your own Fieldtype could store just the selector string, but expand that to a PageArray in the Fieldtype::formatValue function, as one possibility. The main disadvantage of storing just the selector is that you couldn't query the field from another selector to know what pages were stored in it... since the results are determined at runtime and not stored on disk. If you only need the selector string as a way to determine which pages are selectable (as opposed to which pages are selected), then this is pretty much in-line with what the PageAutocomplete inputfield does. Only it sounds like you need to define this selector on a per-page basis, rather than a per-field basis. Your Inputfield certainly could create its own DB table if you wanted it to. While it's true that dealing with the storage-side is exclusive to Fieldtypes, this one would be kind of a grey area. If it suits your needs and is ultimately simpler, don't be afraid to have your Inputfield create it's own DB table and store whatever it needs to. But keep in mind that by taking this route, it may prevent the Inputfield from having much value in other contexts like other Inputfield forms or FormBuilder (which may not matter) ... this is already the case with PageAutocomplete and PageListSelect Inputfields.

@ teppo I like the straightforward design of that site! It must display well on mobile devices, also because it uses graphics very sparingly. Remains the question about testing. Obviously the best approach would be to use a large stack of all the latest smart phones and tablets of all varieties. Lacking those I guess some of the services mentioned here will be valuable (to evaluate the visual result, not the code as you are pointing out). I suppose the simplest thing is to just adjust your browser window to a very small size, it already shows a lot. But it won´t show you how your website reacts to touch commands for example. I just downloaded and installed http://www.opera.com...r/tools/mobile/ mentioned at the top of this thread. Seems good. But again it can´t emulate all the latest devices (Samsung Galaxy S4 not on the list). Obviously this is not really possible, as they keep cropping up so quickly. I´m really no mobile-expert and find this quite challenging. The best approach might be to find out as much as possible on standards for mobile devices and then check your code against those (with http://validator.w3.org/ maybe?) plus some testing?

Ya, there were some problems in the previous code. This one is tested and should work: $queryArray = explode(" ", $q); // create an array with all the words $authorPages = new PageArray(); $titlePages = new PageArray(); $results = new PageArray(); foreach($queryArray as $word) { $authorPages->import($pages->find("author*=$word")); $titlePages->import($pages->find("title*=$word")); } // intersect both arrays by importing common pages to the $results array //foreach($titlePages as $p) { // if ($authorPages->has($p)) $results->import($p); //} // forget the above 3 lines, this is so much better for intersecting two arrays $results = $titlePages->find("id=$authorPages"); echo $results;

Hi guys, i finally finished my personal website. PW and jQuery as always and Bootstrap as css framework. English version coming soon... http://complementaryart.com

Just rediscovered an 'old' movie about Adobe Flash from alanbecker. Funny

@Joe: I gave ready.mobi a try too, and was actually about to write that it really proves why certain tasks cannot be automated Our company site was built from scratch with a mobile first approach. I'm not saying that it's "perfect", but I am saying that it works on mobile devices pretty damn well. According to that service "t will probably display very poorly on a mobile phone." Taking a closer look at the issues found, this service is actually testing things quite thoroughly and some of it's conclusions are similar to what a human might still reach.. just by looking at the source, that is. Yes, there's one table used for layout. Yes, CSS file contains pixel widths. What it can't see is where, how and in what role those elements are used and how they are handled in various situations -- something any robot, at the moment, would have trouble understanding.

I just updated the sheet to 0.3 with hooks from latest dev version. + 22 hooks registered. - added teppo's article to info section links (http://www.flamingruby.com/blog/using-hooks-to-alter-default-behavior-of-processwire/) - added link to ryan's tutorial using hook to add method to PageArray (http://processwire.com/talk/topic/4834-simple-hooks-tutorial-turn-a-pagearray-into-a-list-of-links/)

What I did in the past is to hook on InputfieldForm::render and check for if the form is the add page form. Works fine.

Agreed on the notifications, kinda how I did it in my version? Though I think the nav is a tough one, the numbers of items can very greatly from site to site, and often clients will see far fewer links. Maybe some type of "responsive javascript" will need to be used to determine if the links are overflowing, was the image you posted a working example or just a mock-up?

Totally agree, I usually do that and added it to my version.

Made a compromise that I'm happy with. Same technique might be a happy medium for Ryan's theme as well. The more I look at it the more I like it. Awesome!

Just thought I'd share some work I've been doing on a "version" of this theme. I was recently inspired to make a theme that had a "killer" page tree and decided I would merge that code with some alterations to Ryan new 2.4 theme and port it to SASS (I usually use LESS). Anyway below are some screenshots. Dots indicated status, compatible with PageTemplateIcons though I will offer a version without if I finish this and release it as a theme. During drag and drop. Note: helpful arrow, I've used this on my Unify theme, clients seems to like it Fixed placeholderitem styling (not everything has been brought over yet)

A couple small updates today to InputfieldImage and InputfieldFile, on the dev branch. You can now double-click the trash icon associated with a file/image, and it will select (or unselect) all files/images for deletion. The image inputfield now has a grid-view option. To switch to it, click the grid icon seen in the upper right corner of the field. This mode makes it more convenient to sort lots of images. Below are screenshots of the regular view and the grid view. You can toggle between them just by clicking the icon. While these screenshots use the development admin theme, this all works in the regular/old admin theme as well (and 3rd party admin themes I'm assuming too). Another update to mention is something sort of like the HelperFieldLinks module, but not quite as comprehensive. This works only in the development admin theme. If you hover the little down pointing angle on the far right of the Inputfield, it will append the field's name to the label. This is helpful for instantly telling what the field's name is from the API side. In this screenshot the "agent_files" part you see in the label appears only when that icon on the right is hovered.

This classic thread started by Matthew will get your started with #2 and #3 (validation = sanitization + correct input) http://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/ PW $input variable: http://processwire.com/api/variables/input/ Great form examples in Soma's Gist: https://gist.github.com/somatonic

ProcessWire will do all of this, but Pete is right that you'd have to do it from the API side rather than click to setup. Probably what I will do is build some more formal workflow modules in upcoming versions of PW that do it out of the box but also give you a good starting point to modify from. Currently it's fairly trivial in ProcessWire to setup a workflow for approval of new pages to be published. But setting up the workflow for approval of modifications to already-published pages takes much more on the API code side.

you can use Markdown or Textile: http://processwire.c...text-formatter/ or, if the only thing you want is the <br> where there is a new line; you can use "nl2br" on a regular text area: http://php.net/manua...ction.nl2br.php <?php echo nl2br($page->field); ?>