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.

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

Another small, but potentially helpful module. This fieldtype references a field in a page, where the field's data is retrieved from a somehow related remote page. It's kinda like a one way symlink to a remote field. To make this description a little easier to understand I'll just add a example. Imagine you've some pages placed all over the page-tree, but you need editors to be aware of a specific setting in a single page. With this Fieldtype you would set this up like this: - Get the page (php snippet kinda like for page fields) return $pages->get("/special-settings-page/"); - Setup template to field pairing settings=my_special_field - Add this field to any template you need this on. Now this special setting is visible in the backend, if someone edits a page with this reference field, and via the api as read-only field. The field can use all collapsed modes, which do not allow editing, so it can be hidden if it's only needed by the api. This can be useful for content heavy sites, where information is scattered around multiple (parent) pages, but maybe all information needs to be available for the children. It's also nice for creating (shorter) selectors for inputfield dependencies or dynamic page fields. More elaborate examples about this options can be found in the readme of the module. Todo Add checks to prevent infinite loops Maybe make it a field, which can be edited and saved. GitHub: https://github.com/LostKobrakai/FieldtypeReference

What does bring you to that conclusion? PW maybe has the best ML support out of the box compared to other CMS systems.

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.

ProcessWire is *the* best tool to build multi-language websites. Period.

I do multi language websites all week long in PW, what exactly do you think is missing?

Jep, like any other "field=page.somefield" selector does fail with it. It's not the fault of "somefield" but InputfieldAutocomplete does not parse the "page.somefield" part, but just reads it as textvalue. I posted my changes to github so we can see what Ryan thinks of it. https://github.com/ryancramerdesign/ProcessWire/issues/1179

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

I just pushed ProcessWire v2.3.1 to the dev branch. This is a fairly major change in that it switches the DB driver from mysqli to PDO. It meant changes to a large percentage of core files. ProcessWire still supports mysqli, but doesn't attempt to use it unless a module or a template asks for it via the $db API variable. The new API variable (for the PDO driver) is $database. More about PDO at php.net If you are using the dev branch, be careful and test thoroughly with this latest commit to it. Before upgrading, you may want to double check that your PHP supports PDO by looking at your phpinfo (CMD-F or CTRL-F for "PDO"), especially if you are running PHP 5.2.x (where PDO wasn't compiled in by default). Though if you are running PHP 5.2 (vs 5.3.8+) then you may want to just stick with ProcessWire 2.3.0 and upgrade your PHP version when possible. If you are using any modules that use the procedural version of mysqli functions (vs. the $this->db object oriented versions), or type-hint mysqli in methods, then those modules will no longer work. If you come across any modules that don't work with 2.3.1, please let me know here so that I can assist the author in updating them. Note that FormBuilder is one of the modules that does not work with 2.3.1, but I have posted an update in the FormBuilder board that corrects it–so be sure to download that version if you are tracking the dev branch of ProcessWire and using FormBuilder. What this new version adds: 1. New API variable $database that refers to the PDO database. The old $db API variable is still there and refers to mysqli for any modules that continue to use it. 2. New API variable $log that lets you easily log messages or errors to the system logs. Usage: $log->message("This saves this line to messages.txt"); $log->error("This saves this line to to errors.txt"); $log->save("my-log", "This saves this line to my-log.txt"); // Get an array of the last few entries saved to the messages log $entries = $log->get('messages'); // Get an array of the last 50 entries saved to my-log $entries = $log->get('my-log', 50); Note that as always, log files are located in /site/assets/logs/. 3. Conditional autoload modules. In PHP 5.3+, modules may now specify an anonymous function OR a selector string, rather than a boolean for the 'autoload' property returned by getModuleInfo(). PW runs the anonymous function after determining the current $page, so your module can make autoload decisions based on the $page (or any other factor you'd like), if desired. Lets say that we have a module that we only want to autoload when the template is 'admin': public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => function() { if(wire('page')->template == 'admin') return true; else return false; }); } And the same example but using a selector for autoload: public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => 'template=admin' ); } 4. Addition of $pages->add() method. Actually $pages->add($template, $parent, [string $name], [array $values]); This function adds a new page to the database and returns it. This is for syntax convenience, but using the old method is still perfectly fine too. Here's a few examples of usage: // add a new page using template basic-page under /about/ $newpage = $pages->add('basic-page', '/about/'); // same as above, but named 'contact' $newpage = $pages->add('basic-page', '/about/', 'contact'); // same, but populate the title field too $newpage = $pages->add('basic-page', '/about/', 'contact', array('title' => 'Contact Us')); // you can also do this, specifying the values array as 3rd argument: $newpage = $pages->add('basic-page', '/about/', array('title' => 'Contact Us')); $template and $parent are required, but may be objects, IDs, or string identifiers (like name for template, or path for page). When you add a new page and don't specify a 'name', then PW will make one up, guaranteed to be unique. 5. Module files that end in '.module.php' are now supported. So rather than ClassName.module, you may use ClassName.module.php if you prefer it. The purpose here is to support text editors that determine their syntax highlighting based on the file extension. More updates being made almost daily. Please report any issues you experience. Thanks, Ryan

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

Hey Peter - these are awesome! I posted a link to this thread on Github as a comment to an issue I brought up about this confusion I have seen: https://github.com/ryancramerdesign/ProcessWire/issues/968 I especially love the Choose and Upload tabs.

Read this https://processwire.com/api/multi-language-support/. If you did already, read again

Everything looks as it should be. After all you remove first image from $images.

I am working on this, but hadn't time to do. As a starting point this could help date_default_timezone_set('GMT'); $path = "/home/yoursite/backups"; // full server path to the directory where you want the backup files (no trailing slash) $hrs = 3600; $days = 24 * $hrs; $todaysdate = date('Ymd', time()); // Live Site Cutoff $livecutoff = date('Ymd', (time() - (7*$days))); $target = $path . "/site/" . $todaysdate . ".tar.gz"; $filelist = scandir($path . "/site"); foreach ($filelist as $backupfile) { if (stristr($backupfile, ".tar.gz")) { $filedate = explode('.tar.gz', $backupfile); if ($filedate[0] < $livecutoff) { unlink($path . "/site/" . $backupfile); } } } system("tar --create --preserve --gzip --file=".$target." ~/public_html ~/mail ~/ftpconf",$result); $size = filesize($target); switch ($size) { case ($size>=1048576): $size = round($size/1048576) . " MB"; break; case ($size>=1024); $size = round($size/1024) . " KB"; break; default: $size = $size . " bytes"; break; } This is just a snippet for a first approach, nothing to use as is.

It works like this: Add image to ckeditor (markup pasted in from plugin) Potential jQuery stuff happens on the ckeditor Markup is saved to database as it's in the editor Markup is loaded for frontend access from the database Potential textformatters are applied at runtime by php (cacheable by markupcache) Markup is send to the user Potential jQuery stuff happens (frontend) In 1, 2, 5 and 7 are the common places where you could bring in your custom logic. Which one you take depends on the use case.

Thank you so much! Managing those backups has been a little bit of a pain, now the pain is gone. Nice touch with the cleanup, 20 backups cleaned out . This module is indispensable now.

In your case I would probably create an english subsection on the tree. To give a simplistic example: home about events news contact english about contacts You can build a menu easily, being english one of the items. When you are in the "english part", your menu would be the children of english, plus the link to the default language. I'm assuming all the complex structure will for the default language, and that english will be pretty simple.

I forked this module to add an ignore list feature, see here: https://github.com/rolandtoth/ProcessWire-MarkupSitemapXML/blob/master/MarkupSitemapXML.module This adds a textarea where you can enter ProcessWire selectors. Matching pages will be excluded from the sitemap. For example: artist.date_birth!="" name=my-page parent.path=/my-page/ Screenshot: This is how the exlusion works, using $page->is(): public function processExcludeList($page) { // get module settings $configData = wire('modules')->getModuleConfigData($this); // process exclude list if ($configData['sitemap_exclude_list'] != '') { $excludeList = trim($configData['sitemap_exclude_list']); $excludeList = explode("\n", $excludeList); $excludeList = array_filter($excludeList, 'trim'); // remove any extra \r characters left behind // loop through lines and return false if current page matches foreach ($excludeList as $item) { if ($page->is($item)) { return false; } } } return true; } Submitting the module settings doesn't clear the cache - this has to be done manually (just like in the current 1.1.0 release). I made some attempts to fix this but no success. It would be nice if a ProcessWire expert could have a look on it as this is my first module contribution and I'm relatively new to PW.

Great to hear that and welcome to the forums.

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

If you have pages setup for the 1 step page creation and you have title set as format, at first it will make the name 'unpublished', 'unpublished-2' etc. It updates when you fill the title and save the page. The same route could be taken for other fields than title. I must admit that i don't use the format option a lot, i don't know about the general PW public.

Version update 1.1.0 Extended Module Setting Options Max number of backups Minimum 1, default and maximum 100 (defined in constant MAXFILES). Executed with each cron. Deadline Will remove backups older than selected time interval with each cron. Name format syntax # placeholder for db-name. Use surrounding % to escape date() format. Remove backups from module settings dialog Select how many backups you want to keep in storage. Klick *SAVE* to execute.

The answer here below: The menu-id can be found in the browser-url, e.g.: processwire/setup/menu-builder/edit/?id=1035 when you are editing your menu. To render the menu <?php //load the module $menu = $modules->get('MarkupMenuBuilder');//Load the module. $menu is an example //render by name, title or id echo $menu->render(1035,array('default_title' => 1)); //render by ID default title = 1 and you get ML-support ?> In de Readme you find echo $menu->render('1234');//render by ID but with brackets you get an error so, it should be echo $menu->render(1234);//render by ID

@MuchDev Thanks! Try it! Like it! Mark it as favorite in the modules directory! @ceberlin I put it on the todo list. @netcarver Good remarks I will add your code soon.

UPDATE: Fortunately, I have traced the problem. (I recalled having a similar problem on MODx a few years back) ALL of the pages which I created on local XAMPP install and migrated to the live site would throw a 403 Forbidden on save as well as pages which had content that matched the ModSecurity filters/ rules on the server. It does not like the brackets <> I guess. The pages I created on the live site had fields which were to have HTML code but were left empty, hence no error was thrown and the page was saved gracefully. Error log below: [sat Jan 17 13:13:33 2015] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 403 (phase 2). Pattern match "(< ?(?:script|about|applet|activex|chrome).*(?:script|about|applet|activex|chrome) ?>|> ?< ?(img ?src|a ?href) ?= ?(ht|f)tps?:/|" ?> ?<|" ?[a-z]+ ?<.*>|> ?"? ?(>|<)|< ?/?i?frame|\\%env)" ... [uri "/xxxx/page/edit/"] I have a few text fields which are supposed to accept HTML code and output it as is but my host does not like it being saved to the database un-escaped. This issue has been traced and is fixed for now by revisiting the template files PHP code and outputting the data some other way OR manually editing ALL offending entries in the database.....hmph BTW, my host uses HSPHERE/PARALLELS and hides its Apache version