Leaderboard

some recently launched pw-powered sites... Roger Shapiro Fund for New Music Custom blog & news, projects listing and works w/ dataTables... using Soma's social share for the sharing buttons http://www.rogershapirofund.org/ Daniel Lippel, Guitarist http://danlippel.com/ Flowers by Selina Website for floral designer in Westchester, NY. Features custom blog, homepage featured portfolio and full masonry portfolio. http://www.flowersbyselina.com/ Eric Huebner, Pianist media handled by Soundmanager2. A frontpage ajax-powered widget was implemented to let visitors browse the concert & event calendar, with a browsable month view. http://www.erichuebner.com/ Anderson Chase Gallery Simple one-pager http://andersonchasegallery.com/

Just noticed there's quite a few videos and screenshots in the docs using very old Admin themes. Screenshots should be relatively easy to update once a theme is accepted (default or Reno). Videos are going to be tricker. But as someone who initially looked at PW and then bounced off due to the look of the early admin (bloody designers!) I think these first impressions are vital and should be updated.

There is a default markup array in InputfieldWrapper ( https://github.com/ryancramerdesign/ProcessWire/blob/980ce4f0be2054dfbad4a7b334d35bdca42da7da/wire/core/InputfieldWrapper.php ): $defaultMarkup = array( 'list' => "\n<ul {attrs}>\n{out}\n</ul>\n", 'item' => "\n\t<li {attrs}>\n{out}\n\t</li>", 'item_label' => "\n\t\t<label class='InputfieldHeader ui-widget-header{class}' for='{for}'>{out}</label>", 'item_label_hidden' => "\n\t\t<label class='InputfieldHeader InputfieldHeaderHidden ui-widget-header{class}'><span>{out}</span></label>", 'item_content' => "\n\t\t<div class='InputfieldContent ui-widget-content{class}'>\n{out}\n\t\t</div>", 'item_error' => "\n<p class='InputfieldError ui-state-error'><i class='fa fa-fw fa-flash'></i><span>{out}</span></p>", 'item_description' => "\n<p class='description'>{out}</p>", 'item_head' => "\n<h2>{out}</h2>", 'item_notes' => "\n<p class='notes'>{out}</p>", 'item_icon' => "<i class='fa fa-{name}'></i> ", 'item_toggle' => "<i class='toggle-icon fa fa-angle-down' data-to='fa-angle-down fa-angle-right'></i>", // ALSO: // InputfieldAnything => array( any of the properties above to override on a per-Inputifeld basis) ); You can override this with your own array: $form->setMarkup = array( // your stuff here ); And the last note in the first code block there says you can override per field as well, so happy days - you can do InputfieldText and so on and play around and see what happens. I would suggest {attrs} would always be required for simple fields like input type=text etc as this will have the field name and so on.

That's not really something that would need to be fixed, as the file it's refering to does not use the wire() function as constructor. It's already the right way, but it seems php7 is not picking up that fact because there's no __construct() function present.

Hi @Spica, please have a look into ImageSizer. PW already calculates dimensions and compare the needed amount of ram with available ram _before_ opening an image or _before_ creating another instance of an already loaded image: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ImageSizer.php#L412 https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ImageSizer.php#L1913 Only thing what comes to my mind is to increase memory, use smaller images or upload only one after the other and not a lot in parallel. Have you tried to upload multiple images as zip-archive? ------------------------------------------------------------------------------------- You can test and call the method from the outsite of imagesizer too, if you like: $info = getimagesize($image->filename); $sourceDimensions = array($info[0], $info[1], $info['channels']); $result = ImageSizer::checkMemoryForImage($sourceDimensions); var_dump($result); EDIT: the only thing what maybe happen in your system is that PHP isn't able to read a setting for max_mem, please have a look here to this line: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/ImageSizer.php#L1934 If you use the above code for a test, and var_dump($result); will show null, PHP isn't able to read a seting for max_mem or there isn't one set. In this case, please also refer to output from phpinfo().

Sourcetree (and I believe other clients) handle the folders for the branches for you behind the scenes. Using Sourcetree I have only 1 main project folder per project (with sub-folders and files inside, of course). I start off with a master branch which I then clone to become a 'dev' branch. My dev branch then becomes my 'working' branch. Every time I edit my files, I am working on the dev branch. When I am ready to share the code, I push the dev branch to 'origin' which in many cases is GitHub (but can be BitBucket as well). Sourcetree will ask which branches in the origin I am pushing to. I push local 'dev' to origin (i.e. remote) dev. When the code is stable enough, I merge dev to master. If I switch to master as the working branch, and edit my files, Sourcetree makes sure that my text editor is editing master files and not dev. So, it is important to ensure you have the correct branch set as the working branch. Earlier in the days I used to have separate folders for master and dev branches and it was just too tedious... I suggest you Google some intro to GitHub or Git. There's some nice resources out there Edit: Check out your repository settings RE linking your local and remote branches..

I use source tree for all things GitHub...https://www.sourcetreeapp.com/

I have to say that the form API works pretty well in the frontend. I have several sites where I use it without issues. Once you get the hang of it, it is actually quite nice to interact with. Only thing I am missing is a more easy way than the current to get more control over the rendered markup. Formbuilder comes to the rescue here. If I remember correctly, when UI framework support was introduced to formbuilder, Ryan stated that the core functionality was altered to easier support UI frameworks. But I never found any hints on how to easily alter rendering of form markup (especially field wrapper's markup and attributes) other than through hooks. Nevertheless, I agree that it would be nice to have a docs section dedicated to this topic. Or at least have a link collection to relevant forum posts that deal with frontend forms, processing and saving of input values. Links I can come up with quickly: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ and, of course, Soma's great gists (big kudos) https://gist.github.com/somatonic/5011926 (build and process generic forms from page templates) https://gist.github.com/somatonic/4027908 (build and process forms manually with API) https://gist.github.com/somatonic/4150974 (upload images) https://gist.github.com/somatonic/5415646 (form with fields in table) https://gist.github.com/somatonic/5233338 (manual form markup with file upload handling)

Should probably be noted that the wire() method in the Wire class is not intended as a constructor. See the code comments for a more in-depth explanation. Edit: not the first one to note this, I see

This is a website about a label I had in the past. After a long pause it was time to set the former label website up again (with a new look) by popular demand. The whole site was set up in less than 2 months in my spare time: setting up everything, creating templates and loading the data page by page. 2 languages (with a main emphasis on German) and everything's fully responsive. Thanks to Processwire and UIkit no problem. - Ryan, thank you for this wonderful CMS. This is only the beginning. If people are using it (and it looks like that) I will expand this thing with videos and more. https://www.chrom.de

if($vessel == 2) {

So, 48 hours or so after a question that initially got the standard "PW != WP" answer, there's been a reasoned discussion, people have come round to seeing some merit in the initial premise, and BitPoet has a couple of alpha modules on GitHub. That is an extraordinary testament to the quality of PW and this community.

These are automagically called by ProcessController when an URL segment is appended to the path of an admin page. If an admin page url is http://server/processwire/adminpage/ and that page is called, the execute method is called. But if you open, for example, http://server/processwire/adminpage/edit, the first letter of the URL segement (edit) is uppercased and it is appended to the process method, resulting in executeEdit. Process methods with multiple uppercase letters (camel case) are called by passing URL segments with hyphens. The hyphens are stripped, but each letter after a hyphen is uppercased, so http://server/processwire/adminpage/point-me-to-crocodiles will look for a method executePointMeToCrocodiles in adminpage's process module. This way, one doesn't have to set up another process module for a subtasks and create a page for it or parse even more form values in execute. For a new subtask XXX, it's sufficient to add links/form targets with an URL segment of xxx and define a matching executeXxx method. A perfect starting point to learn more about creating process modules is the source code of Ryan's ProcessHello module, which can be found at github and in the module repository.

Hey guys, I finally got my first module ready to publish It's called HappyCssClasses. I know there is BodyClass module, which I used a lot, thanks to Kay Seliger! But lately I needed more flexibility. First thought about a class in prepended template file like $bodyClass = "lang{$user->language->name}"; and then could extend it in template files using $bodyClass .= " blog"; of course. But there is no fun. I want and need to learn more about classes and php so figured this could be a good use case. So what is this module doing? After installation (see readme) it will instantiate $bodyClasses variable which will be available in your template files (should work almost everywhere) Then you will be able to add/remove classes as needed Like $bodyClasses->add("className"); $bodyClasses->add("className", 'key'); // the key is only necessary to remove a class later $bodyClasses->add("className secondClass third-class"); $bodyClasses->add(array('first-class', 'secondClass')); $bodyClasses->add(array('key1' => 'first-class', 'key2' => 'secondClass')); $bodyClasses->remove('keyDos'); $bodyClasses->remove('key1 keyDos'); $bodyClasses->remove(array('key1', 'keyDos')); There are some dynamic classes build in which you can enable by just adding the key $bodyClasses->add("language") to add "lang-{langname}" $bodyClasses->add("template") = "template-{templatename}" $bodyClasses->add("published") = "published" / "unpublished" $bodyClasses->add("pageNum") = "page-1" for pages greater than 1 it also adds "not-first" or $bodyClasses->add("defaults") = adds all of the 4 above (language, template, published, pageNum) or you could define multiple like $bodyClasses->add("language template") Could be in prepended template file, e.g. _init.php, or your appended template file, or of course in specific template files lice article.php I would love to get feedback For example, I just added the possibility to get all defaults by adding "defaults" Is there a better way? Because I conditionally check if the added class is one of the 4 (or defaults) and need to cancel after one of thos got added. But because the "defaults" would add all I need to make sure only to return if not defaults.. if (in_array($class, array('language', 'defaults'))) { $this->classes['language'] = 'lang-'.$this->wire('user')->language->subtitle; if ($class !== 'defaults') return; } As I said, every hint, feedback, suggestion, request, idea or anything constructive is highly appreciated Check out on Github https://github.com/CanRau/HappyCssClasses I'm planning (like mentioned in the readme) that one can enter custom names to instantiate a second (or more) time so you could have e.g. $bodyClasses, $articleClasses, $blogClasses..thinking about implementation. And need to do some other stuff today too ;-) One question to github, I'm using the Github app for os x at the moment. I made a seperate Repositories folder for it. And then I symlinked the module into my modules folder, otherwise I would have to copy/paste everytime I change something. How'r you handling this? Are there better ways? Saludos Can CHANGELOG 0.0.6 - Changed module name from HappyClasses to HappyCssClasses - Added second parameter to $bodyClasses->add("language", "fieldname")

For me, this looks good. If this is a module and it creates all the required fields and templates and handles data / pages, what is missing? This is a lot! If you have the possibility to upload this into a GitHub repo, this would be a good start to test, if someone will laugh, I don't think so. But maybe others start to use it and contribute a bit here and a piece there. Who knows?

The idea is to have no dependencies, so a fresh install of PW would provide everything needed. Replies are stored as pages under a sub-page called "Comments". I've followed along the route of topics and comments so that comments (or replies) can also be used for other pages throughout a site. This image explains it more: The module installs all the required fields and templates expected for a basic forum, it's then up to the user in regards to the markup and how to sanitize the data etc. It doesn't really do much more than that, other than to obviously save the data through custom methods. I have some code as stated previously, but I'm afraid people will laugh at it, as I know a lot of people on here could easily do a better job.

The Imagesizer detects the settings of the Exif orientation tag and autocorrects this where needed, if it is enabled. The setting to enable / disable this for all variations can be set in $config->imageSizerOptions "autoRotation". The default is true: $config->imageSizerOptions = array( 'upscaling' => true, // upscale if necessary to reach target size? 'cropping' => true, // crop if necessary to reach target size? 'autoRotation' => true, // automatically correct orientation? 'sharpening' => 'soft', // sharpening: none | soft | medium | strong 'quality' => 90, // quality: 1-100 where higher is better but bigger 'hidpiQuality' => 60, // Same as above quality setting, but specific to hidpi images 'defaultGamma' => 2.0, // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0) ); There is an extra setting for this for AdminThumbs, default is true, too: $config->adminThumbOptions = array( 'width' => 0, // max width of admin thumbnail or 0 for proportional to height 'height' => 100, // max height of admin thumbnail or 0 for proportional to width 'scale' => 1, // admin thumb scale (1=auto detect, 0.5=always hidpi, 1.0=force non-hidpi) 'upscaling' => false, 'cropping' => true, 'autoRotation' => true, // automatically correct orientation? 'sharpening' => 'soft', // sharpening: none | soft | medium | strong 'quality' => 90, 'suffix' => '', ); Please ensure that you have autoRotation set to true for both use cases.

Hi there! Check configuration for "title" field. If you have unchecked "Global" option, the field will not be shown in the first step of page creation.

In my opinion the biggest hurdle here is building the forms and processing their inputs. There are various tools trying to solve that part, but personally they've never fit my workflow to stick. Also, while processwire does have a forms api, it's not meant to be used in the frontend and therefore does only solve this issue partly.

maybe you need this? $table->setEncodeEntities(false);

I have to agree. As first impressions go, this is excellent. Having spent years at the helm of Joomla sites and having just moved to an agency that has a WP back catalogue and have been dabbling in PW, it looks like they picked the right platform and more importantly community!

Okay, so I've done it. Two sets of modules, one for the server side, the other for the client side. There are still a lot of ToDos, like adding dedicated endpoints on server and client (I'm currently hooking indiscriminately into ProcessPageView::execute, but I'd like to go the route of only loading the listeners for this template) or adding some kind of challenge-response mechanism to keep nosy third parties out. The modules are up on github: Server component Client component There's also a screen cap in the readmes. Both module sets have lots of hooks, so component modules should be easily able to extend the basic functionality. Currently, the online functions arealdy built-in are the setup of the management connection on both sides and getting basic client information. I haven't really looked at the upgrade or db backup modules, so I've got no idea how complicated remoting them would be. But the sky's the limit. Comments, critiques and pull requests welcome!

Recently I got a brand new iMac so I needed to install PHP SQL and configure Apache. I'm using the same web develop environment for years and I'm really happy with it. Raymond is also using this and Arjen did the same recently. I love to share how I setup this environment in a step by step tutorial. Let's setup PHP, MYSQL and activate mail using gmail smtp for OSX 10.6 and up, perfectly suitable for ProcessWire. It doesn't install Apache, it uses the Apache installation, which comes with OS X. The PHP installer package is created by Liip and it is based on entropy's php package. For MYSQL we gonna install the DMG Archive (x86, 64-bit). After we installed PHP, we configure Apache & PHP so that we’re able to run the ProcessWire sites in our own ~/Sites directory. For El Capitan see Arjen's https://processwire.com/talk/topic/5797-setup-a-processwire-environment-on-a-fresh-macos-x-install/?p=103674 Install PHP We gonna use the PHP installer created by Liip. (more information) Go to: /Applications/Utilities/ Open: Terminal.app Type: curl -s http://php-osx.liip.ch/install.sh | bash -s 5.5 Press: RETURN Type: your admin password Press: RETURN ( download starts and continues with a the install ) note: If you want to have an older PHP version, replace 5.5 with 5.4. (PHP 5.5 is the current stable) After the install is completed Apache is restarted and complains about “Could not reliably determine the server's fully qualified domain name, using your-computer-name.local for ServerName”. This notice is not a problem, we only use this Mac for local website development. Setup Apache Open a new finder window. Press: shift + command + g ( Go to folder ) Type: /etc/apache2/ Press: go Open: httpd.conf Find the line: #Include /private/etc/apache2/extra/httpd-vhosts.conf Remove the # infront to enable. Press save and enter your password when asked. Enable the use of ~/Sites folder:Open the folder /etc/apache2/users/ * Duplicate the Guest.conf and name it martijn.conf Open the duplicated file that we created * Change: <Directory "/Users/Guest/Sites/"> to <Directory "/Users/martijn/Sites/"> Change: AllowOverride None, to AllowOverride All Save the file. The file should look like: <Directory "/Users/martijn/Sites/"> Options Indexes MultiViews AllowOverride All Order allow,deny Allow from all </Directory> Configure the vhosts includes Open /etc/apache2/extra/httpd-vhosts.conf Comment out the 2 VirtualHost examples by putting a # in front Be sure that NameVirtualHost *:80 doesn’t start with a # sign. * Add the include: include /Users/martijn/Sites/_vHosts/*.conf at the bottom of the file. Save the file, password will be asked. The file should at least have these two lines: NameVirtualHost *:80 include /Users/martijn/Sites/_vHosts/*.conf * ( Replace martijn with your short admin name ) The ~/Sites folder (Users/martijn/Sites) Goto your user Home folder. Create the Sites folder in your user home ( if not exist ) Create inside the Sites folder a folder called _vHosts Create the folder domains inside the ~/Sites folder Create a folder inside the domains folder called processwire ( processwire will be the domain name ) Inside the processwire folder create 2 directories: 1. htdocs 2. logs ( make this writeable by right click the folder and choose Get info ) Create inside the htdocs folder a file called index.html with some content. The folder structure should look like: ~/Sites |`-- _vHosts | `-- domains | `-- processwire | |-- htdocs | `-- index.html | `-- logs Configure PHP Open the file: /usr/local/php5/php.d/99-liip-developer.ini ( This file is the last ini file that gets loaded, so perfectly suitable for your personal settings ) Make your personal changes here. ( setting xdebug.max_nesting_level=1000 for example if needed ) Save the file ( password will be asked. ) Make an alias the this file by right click and choose: Make Alias Name the alias _settings.ini or what ever you want to name it. Move the alias to your ~/Sites folder Create a vHostIn our ~/Sites folder we created a folder named _vHosts. This folder we gonna use for the vHosts. All files ending with .conf in this folder will be loaded when we (re-)start Apache. Create a new file with your favourite text editor. Type the following in the file: ( Replace martijn with your short admin name ) <VirtualHost *:80> DocumentRoot /Users/martijn/Sites/domains/processwire/htdocs/ ServerName processwire ErrorLog /Users/martijn/Sites/domains/processwire/logs/error.log.txt CustomLog /Users/martijn/Sites/domains/processwire/logs/access.log.txt common </VirtualHost> Save the file with the filename processwire.conf in the folder _vHosts The hosts fileGo to the Finder Press: shift + command + g ( Go to folder ) Type: /etc/hosts & press return Open the hosts file with you favourite editor Type 127.0.0.1 processwire below 127.0.0.1 localhost but above 255.255.255.255 broadcasthost Save the file Right click the file & choose: Make Alias Move the alias that you created to your ~/Sites folder Rename it to _hosts The file should look like: ## # Host Database # # localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 127.0.0.1 processwire 255.255.255.255 broadcasthost ::1 localhost fe80::1%lo0 localhost Test the Apache & PHP setup Go to: /Applications/Utilities/ Open: Terminal.app Type: sudo apachectl restart Press: RETURN Type: your admin password Press: RETURN At this point Apache & PHP will be up and running.Go to a browser and type: processwire/ in the address bar and press enter. MYSQL For managing MySQL databases I use Sequel Pro it's a very handy tool and in this tutorial we set the root user password with it. For the SQL server we gonna use the MySQL DMG Archive (x86, 64-bit) Download the following: MySQL DMG Archive (x86, 64-bit) Sequel Pro Open the mysql-5.6.16-osx10.7-x86_64 image * install mysql-5.6.16-osx10.7-x86_64.pkg, MySQLStartupItem.pkg & install the prefPane * if MACOSX complains about: ( mysql-5.6.16-osx10.7-x86_64.pkg” can’t be opened because it is from an unidentified developer. ) You should open your System Preferences, go to Security & Privacy and Allow apps downloaded from: Anywhere Set the root user password Double click the sequel-pro-1.0.2.dmg. The disc image will mount Drag'n'drop the Sequel Pro.app to your /Applications/ folder. Open Sequel Pro Type by name: 127.0.0.1 Type by host: 127.0.0.1 Type by username: root Login Press command + u Select the root user on the left side Fill in the password Press apply We're Done ----- Todo how to use it after the setup is complete

A collection of links and information for front-end development. Front-end forms Create simple forms using the API https://processwire.com/talk/topic/2089-create-simple-forms-using-api/ Gist code for the above link https://gist.github.com/somatonic/4027908 Build and process generic forms from page templates https://gist.github.com/somatonic/5011926 Build and process forms manually with the API https://gist.github.com/somatonic/4027908 Upload images https://gist.github.com/somatonic/4150974 Form with fields rendered in a table https://gist.github.com/somatonic/5415646 Manual form markup with file upload handling https://gist.github.com/somatonic/5233338 Form Builder (module) Building front-end forms on your website has never been so simple. ProcessWire Form Builder lets you create, edit and publish forms with no development necessary. http://modules.processwire.com/modules/form-builder/ Front-end member management FrontendUser: login, logout and register users / members (module) https://processwire.com/talk/topic/9811-frontenduser-login-logout-and-register-users-members/ Member login, logout, password reset https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=15919 Popular front-end UI frameworks UIkit http://getuikit.com/ Semantic UI http://semantic-ui.com/ Foundation http://foundation.zurb.com/ Bootstrap https://getbootstrap.com/ Materialize http://materializecss.com/ Skeleton http://getskeleton.com/

This week we're going to look at our path for growth in 2016, which is already off to a nice start! This includes where we've been, where we're going, and how we will get there–with your help. We actually do have several core updates prepared too, but mostly smaller things that will fit better in next week's post. This post originally started as a section of our 2016 roadmap, but I decided it really deserved its own post, so saved it for this week so that we could cover it more in-depth. However, you might consider this part of, or a continuation of, our 2016 roadmap. But rather than looking internally, much of this post looks externally, outside of our software and community, and into the bigger picture of ProcessWire in the web development/design world. https://processwire.com/blog/posts/growing-processwire-in-2016/

I will upload it to Github this week for people to try. I'm just cleaning up the coding errors I decided to implement while drunk over Xmas Also I'm not totally familiar with Github, but I should be able to get something useful up before the weekend.

Yes there are, but they don't have time to do everything

ok, I was setting up the wrong config.php: the one in the "wire" directory instead of the one under the "site" directory. Shame on me. Thank you for your help

What PW version do you use?

If you take a look at the html that is rendered for every form, you will see, that the fields are wrapped in li elements which are inside an ul container with class Inputfields. <ul class="Inputfields"> <li id="some_id" class="Inputfield ...">The form inputfield html</li> </ul> 'list' => "<div {attrs}>{out}</div>" refers to the ul container. So in this example ul would become div 'item' => "<div {attrs}>{out}</div>" refers to the li elements inside the ul. So in this example the li elements would become div elements. {attr} refers to the ids and classes and {out} to the inputfield markup. You can change id, name and class of an inputfield with $field->attr("class" , "myclass"); $field->attr(id+name , "myname"); But you cannot change the ids and classes of the inputfield wrappers in this way. You'd need custom hooks for that. EDIT: yes you can, see Pete's post below Or you get formbuilder which makes it really easy to generate forms for uikit and other frameworks.

I also want to mention that you also can use a file name as PageProcessEditChangeView.js, it's a little more verbosity in the filename but it gives you the flexibility to separate different tasks in separate files.

Again and again i've to write how awesome this module works....thank you Martijn.. it's a kind of JS/CSS captain hook for the admin! Here a little example for a easy solved problem at least for me: Have a events page that works like a timeline - and the event template itself contains the data and provide a .ics format file on the URL of the "page" there is no kind of single view and the template works as iCal generator for the event itself. So the little big Problem is if a user/autor clicks in the backend on "View" he get the eventxyz.ics file and not to the frontend page for the events.... so i need one line in the PageProcessEdit.js that solves this issue with a breeze of jquery. $("a#_ProcessPageEditView[href*=events]").attr("href", "/event-overview-page/"); best regards mr-fan

Ii is kind of hard to answer such a broad question. Maybe we should narrow it down to something managable? And of course this "already have been asked and answered" a number of times. pwFoo seems to be persistent in building modules related to this problem.

Update: Version 5 (dev branch only) Changes Added pagination to coordinates' table (adaptation of this easy table pagination script) [@note: (i) selecting trash all will trash all rows whether in view or not: (ii) *clicking on a marker whose table 'page' is not in view will not bring that page into view. I need help with this] If using AsmSelect, made it so that selectable pages that are already markers (i.e. already in the coordinates' table) are greyed out and are un-selectable (similar to normal page field behaviour) [@note: the JS I am using may not work in some (older) broswers] * need help with this please, thanks. I've noticed that IE does not seem to understand element width() [only innerWidth()]. This results in very massing coordinates' values. I'll see if I'll sniff user agent to accommodate IE. My policy in respect to free modules is I don't bother with IE ) Screenshot

Nice, thank you If this is for your memories, this is not a bad thing. A lot of knowledge has just disappeared from the web. Not every band was organized enough to catch up with the internet early and left almost no traces. So they, and their audience (and me), have their platform back, finally. Since this is my Processwire 3 testing ground, I will probably do much more with it, if I have the time.

Thanks for sharing, looks Good. Some nice memories are coming back. Chrom Records was one of my favorite labels back in the 90ies. But I am feeling old now..

Hmmm... I'm looking for a module that can clean my house and can make me coffee...

Good job! Starting to write modules is like a rebirth - a few lines and suddenly you are a programmer. Congrats! I also mentioned inconsistency in naming. Better pick one name and go with it.

Yes, all these points would mean creating a monster. In terms of database backups or malware scans, those are highly platform specific and not something easily implemented in a module. A centralized overview actually makes sense to me. Showing.PW and module versions and outputting some statistical information is also quite doable. Displaying a momentary status can be done, but continuous monitoring is not something that you can build on top of PW - for this, you'd need to add some layers under or next to it. I've started tweaking together a set of modules that could serve as a base. I'll try to add the necessary hooks to allow extending it tomorrow and put an alpha release on github. If nothing else, it's an interesting conceptual challenge

You should take a look at Soma's great gist about building frontend forms from fields of a template (or page). This code also pulls in all the dependencies you need for asm page fields, image fields etc. It also takes care of server side form validation. Only thing you need to add is sanitation of the form values. I have used this code as a base for several frontend forms (even complex ones) and it is working great.

Ryan - you're the twinkly fairy atop our ProcessWire Christmas tree. But seriously, I wonder if you should include a screen grab from GoogleTrends too? It does a great job of showing the increase in Searches for ProcessWire on Google. BTW, your clarity and openness here just highlights the WTF-fest surrounding another platform I use. Nobody knows the number of the next version, they can't agree on the product name, there's no public (if any) roadmap and it's probably over a year since there was any type of public info. I wish them well but reading great posts like yours on how solid PW is and how bright it's future (and present) is, clarifies for me that banking on PW has been the right decision for my business and clients too. And that's not because the other CMS is headlining at Confusion-Palooza but because PW on its own merits has a bright, long road ahead. You've written too a post which I'll happily send clients to when they ask "well, what is ProcessWire"?

While I agree with earlier posters about not needing to update PW installations, honestly I agree more with teppo - I want older customers to reap the benefits of improved admin functionality. And course we are not just talking about the PW core here - there are also often 3rd party module updates - sure these updates might just add new functionality and there is always the chance that they might break something, but if you do your due diligence in checking the revised versions, it is nice to be able to update across all your sites at once. I actually had/have some plans to build something like this - but am waiting to see if the demand is going to be there. Module Toolkit is something I use in the meantime for updating all 3rd party modules on a site at once - it can be a significant time saver. But be aware that this module is currently alpha/early beta - I would like to get back to it and release it properly, but juggling priorities as usual

That's true. Still, there are some reasons why you might want to update sites anyway: If you're hosting and supporting multiple sites, it's more overhead when they have different versions of the system running Updates often bring in new features – such as hugely improved image management tools – that your customers might want to use Not having known vulnerabilities in the core or third-party modules in the modules directory so far doesn't mean that these can never ever appear; especially when you're working with third party code, it's good to keep track what you're using and where, and for this reason alone a centralized management platform can be quite useful We're hosting quite a few sites and for this purpose I've built an in-house solution that does pretty much what you've described here. The focus is on making management of a large group of sites effortless and providing automation for common tasks, but this platform is also used to keep track of site-specific features, versions, usage, and so on. There's little chance of opening our in-house solution to larger community, but the thought of building something similar and open-sourcing it has crossed my mind a few times. Potential user base for this would be somewhat limited for the time being, but this is definitely something to keep in mind in the future

I'm guessing that some new rewrite rule the SEO guys added caused it to start using those ?it= URLs, revealing them when it usually wouldn't. For instance, maybe they setup a rewrite rule that makes /index.php redirect to "/" without getting it quite right, thereby interfering with PW's own rewrite rules. I would suggest removing whatever rule they added that's causing the interference, and then putting your own alternative in a /site/ready.php or /site/templates/_init.php (if using one), like this: if(preg_match('/(index\.php|[?&]it=/!', $_SERVER['REQUEST_URI'])) { throw new Wire404Exception(); } Or if you just want to make it redirect to the homepage, replace the exception line with $session->redirect($config->urls->root); I will add something similar to the core ProcessPageView module to prevent that possibility too.

Example for a use case with importing things. This is a raw draft with a bit pseudo code: // you have created a queue in PW, the ID of the page is 2000 for example // here is some skeleton code for an importer that uses this queue // get and validate the queue handle if(! ($queue = $pages->get('id=2000')->wireQueue())) exit(); // we could not get the Queue page // now start to scan / read data for your imports, wrap each record into an array and put it into the queue foreach($pages->find(YOURSELECTOR) as $p) { $data = array($p->field1, $p->field2); $queue->addItem($data); } // now start to process your items by pulling one after the other from the Queue while($timer < $maxtime) { $data = $queue->getItem(); // process the $data ... } $session->redirect('./');

Thumbs up for this parallel

I wrote up a detailed tutorial on how to use this: https://processwire.com/talk/topic/11806-tutorial-building-a-simple-rest-api-in-processwire/

Here is something I hacked together quickly for automatically adding new child pages to the pagetable field. This is only if you are using the page as the parent. It also handles deletion of items if they are trashed externally. I also disabled the internal check for orphans - because they have been automatically added already, there is no need for the "Children were found that may be added to this table. Check the box next to any you would like to add." option. I seems to be working great here, but please test carefully!! Add this to your admin.php file: wire()->addHookBefore('InputfieldPageTable::render', function($event) { $pp = wire('pages')->get(wire('input')->get->id); $ptf = $event->object; //remove pages from pagetable field if they were externally trashed foreach($pp->{$ptf->name} as $item) { if($item->is(Page::statusTrash)) $pp->{$ptf->name}->remove($item); } //add pages to pagetable field if they were created externally foreach($pp->children as $child) { if(!$ptf->has($child->id)) { $pp->{$ptf->name}->add($child); $pp->of(false); $pp->save($ptf->name); } } //reset orphans property so that we don't get a message asking to add new pages that are now already automatically added $ptf->setOrphans(new pageArray()); });

slightly ot but whenever i get a chance i like to hotlink this xkcd classic

ProcessWire's API doesn't use SQL queries -- it uses selectors. SQL injection is a non-issue in ProcessWire. ProcessWire does not get involved with database abstraction layers, so if you are executing SQL queries then you are using PHP and MySQL (mysqli). You can always add your own database abstraction layers to do whatever you want. But typical usage of ProcessWire for developing a site does not involve SQL. If you are using SQL for something and you want to stick with the DB driver PW is using (PHP's mysqli) then you eliminate SQL injection by either using prepared statements or escaping your strings before putting them in a query. Use it the way you are supposed to and SQL injection is a non issue. Is it possible your company was asking about the security of the software itself? ProcessWire's own queries are well protected against SQL injection, of course. SQL injection is a problem of bad code. If one uses the database driver in the way it is supposed to be used, then you are never subject to SQL injection. Btw, I don't know about what CakePHP is doing, but the whole idea of trying to protect the user from SQL injection (outside of the DB driver) sounds like a security problem in and of itself. We've seen this with PHP's magic quotes, which was meant to protect the user from SQL injection. Anything that tries to protect you from yourself ultimately encourages bad programming practices by making security a grey area. That fosters an environment where many think they don't have to sanitize and validate input, which becomes an even bigger security problem.