Leaderboard

Hi guys, Been "kicking the tyres" on some UI tweaks to the PW image fields and modal windows. Many of these are in-progress designs and to be straight, none of the designs are entirely resolved. At this stage, I thought I'd throw them up (poor choice of words!) and maybe someone can take them further or offer some fresh eyes. I'm not a developer so making these a reality is impossible for me. They're flat designs. Why? PW is an amazing experience for editors. It's just so elegant and beautifully realised (especially with Reno Theme) that often, my training sessions with clients are very brief. One area which does cause friction though has always been concerned images, image fields and image modals. Especially with the latest image modules, I think a lot of inconsistency has crept into the UI. Hopefully these designs can help improve things a bit. A tiny part of the design work is influenced by a similar idea I had for MODX but which never progressed. 1A. Current Image Modal Editor has clicked 'Add image' icon in CK editor. Issues: I believe the Upload Image button can be better placed. It's not clear to users that they have a choice of two actions (Select an Image OR Upload one) To help solve this, I thought we could: Place available images under a Choose tab Create another tab titled Upload Rename modal to just Image (from Select Image) tweak slightly the Images on page path to be less prominent The following image illustrates the result. Clicking the Upload tab would result in: In the above image I've created toggle-able accordians for Drag and Drop and Manual upload. This follows closely the UI an editor is presented with when choosing Insert Link within CK Editor. IE Link to URL, Select Page and Select File and the extra Attributes tab. So overall, it's more consistent. 1B. Alternative to above - combined Select and Drag/Drop I thought it might be worth exploring what modal would look like with no tabs and a single UI for both Selecting an image and Drag/Dropping. 1C. The Image field I then moved onto looking at the Image field in PW. So currently it looks like this (below) for a simple image field called Image Gallery. So although the current Image field works great, I wondered if there was a way to simplify it by Making the drag/drop more visual and obvious Moving the Choose Files button and removing the No file chosen text and the file types allowed Here's the result. Admittedly, this treatment adds more height to the overall field. Here's how it looks when images are uploading (slightly smaller plus icon and "drag and drop..." text. To be honest, I can't recall what other changes I made there! And here's a proposed layout for when there are multiple images. This includes image titles grid layout mouse-over for edit and delete options/buttons 2. Cropping Next thing I looked at was cropping. Native cropping introduced recently is one of my clients favourite features and time-savers and I wondered if things could be improved a little. So heres the current layout (this may have changed further recently) And here's my proposal. Changes are: Width, height and X and Y fields are moved below the image Apply and Cancel placed bottom right of the image Save Crop should be titled Apply. I think that's less confusing as in some instances there are so many Save options Save and Replace should be greyed out further In addition to this, I thought it'd be neat if we had the free-form cropping function introduced by Ryan combined with some kind of list of pre-sets (displayed on right hand side). Forgive the croptions label (Crop + Options pun - I was tired!) The benfit of this I think is that Modules such as CoppableImage and native Crop would be unified in a single UI. Presets (on right) could be a few out-of-the-box presets which come natively. Croptions houses any crop ratios defined in image modules. if CopppableImage isn't installed, they just don't display.. That's it. I wish I'd more time to work on this but it's at the stage where it's ready for some initial thoughts. Hope you guys like.

Hi, I have uploaded a new version to Github that fully supports PW 2.6+ with its new naming scheme. The package now ships with two Pim versions, the older one, called Pim, that can be used until PW 2.5 stable, and the new one, Pim2 that should be used with PW 2.6+ So, if you start a new site with PW 2.6+, simply install Pim2 only! If you have upgraded PW to 2.6 on an existing site with lots of image variations, you should install Pim2 additionally to the older one, (do not uninstall it yet!) then you should start to change your API calls in your templates like the following explanation . here is a code line from the older Pim: $image = $image->pimLoad($prefix)->watermarkText($txt, 75)->setQuality(80)->pimSave(); . To start with smooth change from Pim to Pim2, you can change it to this: // use the old Pim to remove the PimVariations with old naming scheme: $image->pimLoad($prefix)->removePimVariations(); // in the copied original code line, only change pimLoad to pim2Load, note the number 2 ! in the new start method ! $image = $image->pim2Load($prefix)->watermarkText($txt, 75)->setQuality(80)->pimSave(); . This way you have some control on which parts the new creation may take effect, e.g. on a small site you can change all API calls at once and drop caches if exists. On bigger sites you may start at one template / page first, and add more changes later. . Regardless of this, you can safely let the call to the older removePimVariations() method stay in your code for a while, as they do not interact with the newer one. After a while, when you do not see any of those old filenames in your assets/files folders, you can remove those lines from your code and also uninstall the older Pim. All other methods than pimLoad / pim2Load are completly identical and can be seen here in the API

The tutorials for getting started were excellent resources. Awesome starter to go with a solid core. loving PW.

Hi, i just launched my litte blog orkork.de It's a german blog about nerdy topics like IT, development, photography, games, movies and more. Responsive design, built on top of bootstrap. Different teaser types and widgets are configurable in the backend, for every category node. I use require.js for the internal js stuff and use gulp as a building tool for less compilation and css/js minification. unveil.js manages lazy loading of images, including retina versions. Though, it's not heavily optimized yet, but you have to start somewhere I would love to get some feedback, if you have any! Cheers

Currently the 'Name format for children' setting is limited to: alphanumeric: 'test', will turn into 'test', 'test-2', 'test-3' etc. title: name will be based on the title once filled in (at first it will make the name 'unpublished', 'unpublished-2' etc.) date: the addition of any non alphanumeric character (including space) will cause it to be interpreted as date. So entering 'test more' will lead to some date string that doesn't make sense If possible i would like this to be made more fool-proof. But ideally i would like the 'Name format for children' to have more options. Like combining the different options and maybe be able to choose from more fields, apart from title. I also think that in cases where you want to auto-populate the name you often don't really care about the page title as well. So it would be cool if one could auto-populate a page title (and maybe other possible global required fields) as well. If the format would allow for date/timestamp, fieldvalues, text and combinations of those it would be really powerful. Also probably a lot of work but it's a wish-list after all

This looks very nice. I really like consistent UI / UX and the image field did always lack by the tiny bits. My greatest bugbear was always the dropzones. E.g. if I not hit the input exactly it'll load the file as local resource and all changes to my page are gone. Also I've hesitated to use croppable image in the last months just because I really don't like the fact, that it needs to replace the whole UI, instead of gracefully building on it. Therefore I really like your proposed changes to the cropping interface. As you've asked for other opinions I've some thought for you: 1A Having tabs resolves the issue of showing the user his options, but I know it from myself, that it would bug me really soon (if I would use RTE's more often). If I want to add an image I click the image button in the ckeditor toolbar. While the modal opens I switch to Finder, drag my file to the browser and sadly notice, that the droparea is behind the tab. Then I'd try to not drop my image anywhere, where I would open it in the browser or to any wrong folder or the desktop. Change to the upload tab. Repeat first steps. Not very nice. 1B Your alternative would solve my issue with 1A, but it looks really imbalanced from a visual standpoint. Unlike all your other images this looks like a really rough mockup. Maybe a vertical layout would work better than side by side, but not necessarily. 1C Grids are nice to get an overview, but they lack to highlight the most important thing an editor need to be reminded of: descriptions. It also lacks tags, but I'm really not using those. But back to descriptions. I don't know about you guys, but I always use them for alt tags and these should really be filled if one cares for seo. I'm still not sure how this could be solved better, but I really think that only-image grids aren't the obvious way to go. 2 As said before I really like the cropping option on the side and the more tidy placement of all things. The only thing I have to critic about it are the buttons. There are two cancel buttons and the "Apply" button fails to communicate what it does. "Save and Replace" like the bigger button below? I also think the "replace" part should not be part of an button, but part of your options. The "Save" button should only have a single type of action – saving the crop with the current settings – while I may decide while cropping, that I don't want to replace the current crop, but save a new one.

There is a small glitch with the version number that leads to a version mismatch in ModuleManager, which interprets it as 0.0.2 and 2.0 and permanently wants me to update. I am not a module coder but I think that 'version' => 200, would fix this.

Processbombing, surely!

Page Field Edit Links GitHub: https://github.com/thetuningspoon/AdminPageFieldEditLinks Direct Download: https://github.com/thetuningspoon/AdminPageFieldEditLinks/archive/master.zip This module is based on--and is the successor to--Macrura's AdminPageSelectEditLinks (https://processwire.com/talk/topic/8477-adminpageselecteditlinks-module-for-enabling-edit-links-on-multipage-selects/) Page Field Edit Links adds modal editing capability to ProcessWire's Page fields in the admin editor, allowing editors to easily view and edit the content of any page(s) that have been selected, as well as create new pages without leaving the current screen. Edit links are updated in real time when new pages are added to the field. Compatible with all available types of Inputfields including Select, SelectMultiple, Checkboxes, Radios, AsmSelect, PageListSelect, PageListSelectMultiple, and PageAutocomplete.

I missed the XML sitemap generator that I used in a previous CMS so I built my own module to achieve the same functionality. This module outputs an XML sitemap of your site that is readable by Google Webmaster Tools etc. I've generally found that it reduces the time it takes for new sites and pages to be listed in search engines using one in combination with Webmaster Tools etc (since you're specifically telling the service that a new site/new pages exist) so thought I may as well create a module for it. The module ignores any hidden pages and their children, assuming that since you don't want these to be visible on the site then you don't want them to be found via search engines either. It also adds a field called sitemap_ignore that you can add to your templates and exclude specific pages on a per-page basis. Again, this assumes that you wish to ignore that page's children as well. The sitemap is accessible at yoursite.com/sitemap.xml - the module checks to see whether this URL has been called and outputs the sitemap, then does a hard exit before PW gets a chance to output a 404 page. If there's a more elegant way of doing this I'll happily change the code to suit. Feedback and suggestions welcome On a slightly different note, I wanted to call the file XMLSitemap originally so as to be clearer about what it does in the filename, but if you have a module that begins with more than one uppercase letter then a warning containing only the module name is displayed on the Modules page, so I changed it to Sitemap instead which is fine as the description still says what it does. File can be downloaded via GitHub here: https://github.com/N.../zipball/master

In the last few weeks I've notices some request (e.g. here and here) to be able to get pages based on if they are selected in page fields of other pages. I think adding a method for this would be a nice addition to ProcessWire, as it's often the case that the pages itself are options we just want to get, if they are used somewhere. Currently the task "Get all tags used by some blogposts" has to be done manually like this: $tags = $pages->find("template=tags"); foreach($tags as $tag){ // Filter unavailable if(! $pages->count("template=posts, tags=$tag") ) continue; // Do stuff with it } Now it would be nice to have something like this, where we don't need to have a selector for tags (this is done by the pagefield already). // Find all pages, which are selected in the "tags" field of the selected posts $available_tags = $pages->findSelectedPages("template=posts", "tags"); I'm not that big a MySQL guy, but I can imagine this not only improving readability, but also reducing database calls.

You can make your custom sharing widgets using sharrre and PW.. doesn't take long! 1.) Download http://sharrre.com/ 2.) put sharrre.php in templates 3.) put jquery.sharrre.min.js in your scripts folder. 4.) add the new template to PW 5.) add new hidden page using that template; call it anything (example 'sharrre') 6.) include the script in your output; 7.) in your custom js file setup your js; make sure to put in the correct urlCurl to your page using the sharrre.php for example: /*-----------------------------------------------------------------------------------*/ /* SHARRRE /*-----------------------------------------------------------------------------------*/ $('#shareme').sharrre({ share: { twitter: true, facebook: true, googlePlus: true }, urlCurl: '/sharrre/', template: '<div class="box"><div class="left">Share</div><div class="middle"><a href="#" class="facebook">f</a><a href="#" class="twitter">t</a><a href="#" class="googleplus">+1</a></div><div class="right">{total}</div></div>', enableHover: false, enableTracking: true, render: function(api, options){ $(api.element).on('click', '.twitter', function() { api.openPopup('twitter'); }); $(api.element).on('click', '.facebook', function() { api.openPopup('facebook'); }); $(api.element).on('click', '.googleplus', function() { api.openPopup('googlePlus'); }); } }); Note: there are other themes - see the website... grab the CSS that goes with this JS setup: http://sharrre.com/example2.html 8.) somewhere on your page, put the relevant markup: <div id="sharrre"> <div id="shareme" data-url="<?php echo $page->httpUrl?>" data-text="Share this page"></div> </div> works for me on 3 sites so far.. - - - N.B. There is now a comprehensive module for social sharing buttons by Soma which is probably easier to setup and more flexible, though using Sharrre can still have some applications. Also, it is possible that Sharrre is no longer maintained and may not still work without some intervention... not sure as I have not researched this issue..

Hey, if I'm using the Language Translation Tool strings automatically get deleted if they match the original string. This is really annoying because it shows those strings as "blank" in the overview but you can't fix them. Why not just let them be as you type them in? - Nico

Thanks LostKobraKai, I look forward to learning and sharing as well. So glad my old CMS forced me to move on. So far it is fast, user friendly and the Forums are a HUGE wealth of great information.

I just dropped in for a quick minute, but wow! I'll look closer at these later tonight when I have time.

Thanks for spotting that. I just needed to quote it properly, i.e. '2.0.0' I updated the version to 2.0.1.

Did you try to prototype your ratio between number of pages for default and additional language ? Once you have it prototyped it is easy to fill in the parts of processwire to make it up. There are many ways to prototype e.g. http://pencil.evolus.vn/

I wanted to note that all those nice "page" features and custom php code and workarounds don't work when you use them with PageTable pages using different parent (some only if you save the the page and reopen it). https://github.com/ryancramerdesign/ProcessWire/issues/699

For those who want to upgrade to the latest core version like me, I added the following command: Common Upgrade Checks and optionally installs core upgrades. $ wireshell upgrade Available options: $ wireshell upgrade --dev --just-check --just-download Output Example ❯ wireshell upgrade A ProcessWire core upgrade is available master 2.6.0 Downloading ProcessWire Version 2.6.0... 9.35 MB/9.35 MB ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ 100% Preparing new core version... Upgrade files copied. Installing new core files. Your index.php file is confirmed identical to the one included with ProcessWire version 2.6.0 so it should be safe to replace without further analysis. We have detected that your .htaccess file may contain site-specific customizations. Please double check before replacing it. Upgrade completed. Now double check that everything works. You have to replace htaccess.txt manually. A lot of the code is taken from Ryan's ProcessWireUpgrade Module.

Consider yourself very happy

The font is open sans, right? Ryan, if the problem persists, maybe you can switch it to google fonts to try.

We think it's an issue between the latest Chrome and TypeKit, as we haven't heard of it occurring in any other browsers. Also haven't heard of it re-occuring after a refresh, so most likely they made some change at TypeKit that needed a JS refresh. Though please let me know if it continues to recur, or if anyone else sees it occur in any other browser.

pretty interesting - what would be a good use case for this method, as opposed to making the field itself an AceExtended field? I might be being thick, but am not getting that...

Btw.: I would like to see the wiki shut down to prevent confusion. The texts should be merged in the main site and tutorial section somehow.

Posted an issue: https://github.com/ryancramerdesign/ProcessWire/issues/1172

At 1:49: me wearing a ProcessWire shirt https://it-gipfelblog.hpi-web.de/2015/05/17/alexandra-quiring-tegeder-ueber-schulische-bildung-im-bereich-it/

I think another good way would be using a PageTable (core module, but uninstalled by default), which would get you a more visual list than a classic pagefield.

That's not possible right now, you could only use InputfieldMarkup before and after your inputfield to add wrapping markup around the whole inputfield.

Just tried a few similar jQuery plugin (including Freewall) to substitute the Uikit dynamic grid on a site but finally I went back to Uikit. It is very basic but easy to use.

I hear ya - sometimes the brain reaches boiling point and I swear it just goes to mush I see masonry mentioned quite a bit around here, but just to add another option in case folks haven't seen it, I really like Freewall (http://vnjs.net/www/project/freewall/)

I agree and think it is something that is possible if the time and effort is put into it. For me this is one area and advantage that other cms's such as Wordpress with Woocommerce have over Processwire. Maybe something like woocommerce could be taken as an example of how to do it. I dream of the day that Processwire has such an E-commerce solution so I don't have to look outside of Processwire.