Search the Community

Would be nice to update the Fontawesome icons in PW core, so they can be used for labels in the backend. The current version 4 is quite old and has a very limit set of icons. Version 6 also has a free version with more icons. The implementation seems to be very similar, so it should be easy to implement. The icons can be downloaded here.

Hi all, I could have sworn I used to be able to use the site generic 'title' field as a sub field of a repeater field. However I've tried to do this on two 3.0.165 sites recently and, while it will add the title field in the repeater field setup, it wont save the repeater title sub field's content when the repeater is used in a page template and edited. It;'s not a big issue but I wondered if this was a known restriction?

Since I'm doing a lot of detailed logging in our internal PW-based systems, that has become a bit of a bottleneck under heavy load and I was missing a centralized view with the growing number of separate PW instances. So I dug into the core a bit, namely WireLog.php and FileLog.php as well as ProcessWire.php. I managed to whip up my own WireLogDatabase and DbLog classes mimicking the behaviour of the regular logging classes, but not without a little bit of tweaking to the ProcessWire class itself to replace the regular logger. Now I'm logging to a MySQL server instead of plain files and ProcessLogger works smoothly with it without tweaking. I thought it would be shame to keep this all to myself, but a release-worthy version would need or could benefit from: a bit of polishing in regards to error handling and proper treatment of conflicting concurrent operations without too much lock overhead (drop table vs. insert especially) more source code documentation a little more abstraction so all csv operations are deprecated in favor of database columns where avaible last but not least, an approved way to configure the substitute logger and load it early on, which means touching the core ProcessWire class Before I invest too much into that, I'd love to hear all thoughts on this, especially if you think such a module may fit your requirements, and I would be especially happy to hear from @ryan - could you see such a mechanism in the core?

I seem to be running into a repeated fatal error in a fresh PW install version 3.0.148. I can't quite put my finger on the pattern but it seems to be around deleting image fields or removing images from certain image fields. This is the trace from the log generated by trying to save a page and delete an image from an image field: Fatal Error: Uncaught Error: Cannot access protected property Pageimage::$original in /wire/core/PageimageVariations.php:256 Stack trace: 1. /wire/core/Pageimage.php(1327): PageimageVariations->getInfo() 2. /wire/core/Wire.php(386): Pageimage->___isVariation() 3. /wire/core/WireHooks.php(823): Wire->_callMethod() 4. /wire/core/Wire.php(450): WireHooks->runHooks() 5. /wire/core/Pageimage.php(1369): Wire->__call() 6. /wire/core/Pageimage.php(399): Pageimage->getOriginal() 7. /wire/core/WireData.php(333): Pageimage->get() 8. /wire/core/PageimageVariations.php(256): Pro Line 256 of /wire/core/PageimageVariations.php Earlier in the day I was experimenting with custom fields for images for the first time and kept running into this error, thinking it was me using this feature wrong and not having time to read up I deleted the custom image fields template and went about my business. So now I don't know if I triggered an issue or whether it was never related to the custom image fields in the first place? Any ideas?

Not sure if this is by design - or if I'm perhaps missing the obvious. I'm just getting my feet wet with pw (2.5.3) and have created a partial sitemap template (nothing fancy, just recursing through a partial tree). When I added a page field to my sitemap template, selected a page and tried to save, I got a memory limit exceeded error. The problem appeared only when the page picked in the page field was the same as the one being edited. public function resetTrackChanges($trackChanges = true) { parent::resetTrackChanges($trackChanges); foreach($this->data as $key => $value) { if(is_object($value) && $value instanceof Wire) $value->resetTrackChanges($trackChanges); } return $this; } Looking at this method, I guess it's easy to see that this will run in an endless loop if one of the properties of $page is once again $page. As a quick fix, this could be cured by comparing $this and $value in the conditional, but there'd still be a possibility of building circular patterns that have the same problem. Not sure how to go about that. Edit: Of course, InputfieldPage prevents me from even assigning the same page here at all (my fault). Still, the check in Inputfieldpage::isValidPage appears to happen too late.

Hello. I am starting to use ProcessWire. So, i need to extend the ProcessTemplate Module. I need to add a required field to the templates into the Advanced Tab (for personal purposes) I already added the field, but inside the core folder, but this is a very bad practice. The best would be add the modifications inside the site folder. How could i extend the core module ProcessTemplate in order to not affect the core, and the processwire read my extended modifications. Thank you very much everyone.

What are your experiences with profile/color consistency when using Image Magick for resizing? I know @horst is probably the person with the most experience on this, (hope you can chime in here Horst) Problem: I noticed that In some cases Image Magic resized jpgs appear darker than the original, and after some digging it appears to involve various factors concering both the image preparation (Photoshop's save for web and even general profile handling before that) and the way the Image Magic resizing process is setup. - Images with an embedded (srgb) profile that were exported via Photoshop's "save for web" function with "convert to srgb" and "embed profile" ON, somehow result in muted colors and a darker image, (actually it looks very much like when you would assign an srgb profile to an image that was already converted to srgb before, not dramatic, but quite noticeable with e.g. reds and cyans.) - I tried multiple variations, with embedded and excluded srgb profile, "convert to srgb" on and off, but the result appears to be the same darker, muted image. Need to find time to do more structured testing though.. Possible causes: - The way the srgb profile is embedded in the jpg - The way the Imagick module detects/ignores profiles - Colorspace handling changes between imagick versions - One of the above plus these rather involved technical reccomendations (tldr: convert to linear RGB, resize, convert back) http://www.4p8.com/eric.brasseur/gamma.html#ImageMagick http://www.imagemagick.org/Usage/resize/#resize_colorspace Would be nice to get a discussion going here. I am out of my league with this, technical knowledge wise but I'll try to keep up Cheers guys, Phil

hey! i want to read a value from a $page which is a multilanguage-field. it is important for me that i get that field NOT language-filtered, so the whole JSON string '{"0":"abdc","1063":"rguer"}'.. is this somehow possible without switching the fileld to not-multilanguage? because i need the filtered output at other places... is there a possibility to read the RAW data? thanks!

I've updated my site's PW version from PW 2.6.x to the latest version. I've updated manually by copying the wire directory and overwriting index.php and .htaccess. When I try and load up the page I'm getting the following error. Error: Call to undefined function Site\wire() (line 5 of /Users/FrancisChung/Sites/Develop/site/templates/php/const/Const.php) My Const.php looks like : namespace Site; require_once(__DIR__."/../../../../index.php"); Define(SITE_DIR, wire(config)->paths->templates); Define(IMG_DIR , wire(config)->urls->templates."img/"); Define(IMG_SQDIR, wire(config)->urls->templates."img/square/"); Define(IMG_SDIR, wire(config)->urls->templates."img/small/"); Define(IMG_MDIR, wire(config)->urls->templates."img/medium/"); Define(IMG_LDIR, wire(config)->urls->templates."img/large/"); Define(IMG_PATH, SITE_DIR."img/"); Define(IMG_SQPATH, SITE_DIR."img/square/"); I'm guessing the wire(config) calls are failing because of the new Namespace implementation? Is there a way of fixing this without having to change every wire(config) or other wire(fnXXX) calls?

Hi guys, I would very much appreciate to get your feedback to the following idea: We've created a publishing system for our company that is based on ProcessWire. Currently we are only using it for one publishing page. But it could very well be possible that in the future we are in need of managing additional pages. I'm thinking of something like it is described in the article about Multiple-site support, but with something like a site-core that is included by any site instance. To keep server management simple all the instances could use the same database. Imagine the following folder structure: All the templates, modules and assets from the "site-core" folder are automatically loaded by each other "site-" instance. This would enable other instances to add their own templates but still let them use the "site-core" templates. Also the ProcessWire "wire" folder would remain untouched. Additionally it could be great to restrict module configuration access to only activate the "Site" tab on instances. And being able to create new instances from the "site-core" instance ;-) What do you think? Thanks for your feedback Nik

In his latest blog post, Ryan annouces his works on the ProDraft-module for handling publishing workflows. While this is really great news, there is, at least in my opinion, the drawback that this module is a Pro-module. I really appreciate the tons of work Ryan puts into PW and see the need for getting some money back not being able to do work for some clients. I also like the idea of the Pro-modules, where advanced functions not needed by anybody is sold at a moderate price, i myself have bought some Pro-modules already. But such fundamental functionality like draft-versioning or defining a workflow for publishing should be in the core and made open source. I would like to raise a discussion about this, how it could be solved or what other developers think. All other major open source CMS have versioning integrated, so this a field where pw lacks behind and the chance with making that in core would open more opportunities for attracting more people using PW. But then getting this functionality only by paying a decent amount could draw them immediately back without getting the beauty of PW: Some solutions to solve this that cross my mind: Sponsoring: Already Avoine has sponsored some other modules being developed by Ryan, so maybe they or other companies that need drafting could stepin. Crowd-Sponsoring: If there is not one company or individual taking over the sponsoring, why not community fund this like a kickstarter-project? I think, most of us could spent at least the amount the Pro-module would cost or even more to make it open for public. Making only support Pro: Now all the Pro-modules get higher priority support by Ryan. Not only being the only person doing this, but maybe the only individual capable of supporting all the modules at moment, this can become a bottleneck in the future. Being open source, others can work on adding functionality and bug tracking and Ryan could concentrate on supporting. Other CMS are already doing this more or less (i.e. Acquia for Drupal). What do you think, should fundamental functionalities stay available in core for all or only being available as Pro?

Hi, I wish to have a core ImageManipulationClass like the ImageSizer but not only for resizing and cropping images. It should provide these easy to use functionality like with the ImageSizer and additionally a step to step image manipulation whereas the user / module author is not restricted anyhow. The basic image manipulation methods should be included, like: im_flip im_rotate im_crop im_crop_auto im_resize im_sharpen im_stepResize If someone want to do something more fancy or magic, he/she should not to have to reenvent the basics again. He/She just should start with the class by opening the imagefile and create a GD-object, use some basic methods, and at any point get the GD-IM-Reference out, do his fancy magic with it and put it back to the class to use its basics to finalise the file: im_get_im() im_set_im( &$im ) I have started to write something for this. I tried to be as close to the ImageSizer as possible, but some differences will be there. Before I've started with it I have done some tests with sharpening, rotating and others. First I've tried to create a module that hooks into ImageSizer, but have figured out that this wouldn't solve most things what I imagine one want to do with images. I have read the code of ImageSizer very carefully and there are allready very good inprovements in it from the community here. Ok, Ryan has written it and done the most work of all, so tribute to him , - adamkiss, interrobang, mrx, teppo, u-nikos have contributed the improvements to it: . I have looked into apeisas Thumbnail-Module and tried adding functionality for sharpening to it. It think he would have liked if there was a CoreImageManipulation class once when he has written the module. Also Soma actually work on a very cool Module where I really would like to see a link/button or some links/buttons for every image that just let you do some manipulations/corrections to them. <hint, hint ;-)> Any thoughts or Meinungen are welcome. --- EDIT: there is actually a modified ImageSizer class with autoRotation & sharpening available for testing: http://processwire.com/talk/topic/3278-core-imagemanipulation/#entry32284 --- Here are an overview of what allready is in, (I post only properties and method names, not the method bodies): class ImageManipulation extends Wire { // information of source imagefile /** * Filename ImageSourcefile */ protected $filename; /** * Extension ImageSourcefile */ protected $extension; /** * Type of image ( 1 = gif | 2 = jpg | 3 = png ) */ protected $imagetype; /** * Information about the image (width/height) and more */ protected $image = array(); /** * Was the given image modified? */ protected $modified = false; // default options for manipulations /** * Image quality setting, 1..100 */ protected $quality = 90; /** * Allow images to be upscaled / enlarged? */ protected $upscaling = true; /** * Allow images to be cropped to achieve necessary dimension? If so, what direction? * * Possible values: northwest, north, northeast, west, center, east, southwest, south, southeast * or TRUE to crop to center, or FALSE to disable cropping. * Default is: TRUE */ protected $cropping = true; /** * Should a optional Auto-Rotation be performed if EXIF-Orientation-Flag is available? */ protected $auto_orientation = true; /** * the default sharpening mode * * @var array with custom pattern or a string: 'soft' | 'medium' | 'strong' | 'multistep' */ protected $sharpening = 'medium'; /** * if extended imageinfo should be retrieved: number of Channels, Bits/per Channel, Colorspace */ protected $extended_imageinfo = false; /** * Extension / Format for resulting Imagefile (default is same as ImageSourcefile-Extension) */ protected $outputformat; /** * Filename ImageTargetfile if $outputformat is different than InputImage (default is same as ImageSourcefile) */ protected $targetfilename; // other properties /** * Directions that cropping may gravitate towards * * Beyond those included below, TRUE represents center and FALSE represents no cropping. */ static protected $croppingValues = array(); /** * Supported image types (@teppo) */ protected $supportedImageTypes = array(); protected $option_names = array(); private $property_names; // Methods to set and get Properties /** * Here you can specify multiple options as Array, whereas with the * single set* functions you can specify single options * * @param array $options May contain key-value pairs for any valid Options-Propertyname * @return this */ public function setOptions(array $options) public function setQuality($value) public function setUpscaling($value) public function setCropping($value) public function setAuto_orientation($value) public function setSharpening($value) public function setTargetFilename($value) public function setOutputformat($value) /** * Return an array of the current options */ public function getOptions() /** * makes protected and private class-properties accessible in ReadOnly mode * * example: $x = $class->propertyname; */ public function __get( $property_name ) // Construct & Destruct the ImageManipulator for a single image public function __construct( $filename, $options=array() ) public function __destruct() public function im_release() // read image informations, basic and extended protected function loadImageInfo() private function extendedInfo_gif(&$a) private function extendedInfo_jpg(&$a) private function extendedInfo_png(&$a) // helper functions /** * check file exists and read / write access * * @param string $filename * @param boolean $readonly * @return boolean */ private function check_diskfile( $filename, $readonly=false ) /** * helper, reads a 4-byte integer from file */ private function freadint(&$f) // the IM's (ImageManipulation Methods) private $im_dib_dst = null; // is the output for every intermediate im-method and optional a check-out for the im! private $im_dib_tmp = array(); // holds all intermediate im references private function get_next_im( $w=true, $h=null ) public static function is_resource_gd( &$var ) public function im_get_im() public function im_set_im( &$im ) public function im_flip( $vertical=false ) public function im_rotate( $degree, $background_color=0 ) public function im_crop( $pos_x, $pos_y, $width, $height ) public function im_crop_auto( $direction, $width, $height ) public function im_resize( $dst_width=0, $dst_height=0, $auto_sharpen=true, $sharpen_mode='medium' ) public function im_sharpen( $mode='medium' ) public function im_stepResize( $dst_width=0, $dst_height=0 ) // static oneLiner Methods that can be called only with a filename passed to them public static function file_get_exif_orientation( $filename, $return_correctionArray=false ) public static function file_jpeg_auto_rotation( $filename, $quality=95 ) }

Hi, trying to implemement a set of blog pages and started using the Pagination module to find I couldnt list the page=2 etc results. This is what I started with: This is on a blog template, of which the post template children have page number enabled. $results = $page->children()->find("limit=2, sort=-date"); $pagination = $results->renderPager(); echo $results->render(); This didnt produce different results when clicking 'next'. so I tried: $limit = 2; if($_GET["page"]==0){ $startNum = 1; }else{ $startNum = $_GET["page"]; } $start = ($startNum-1) * $limit; echo $start; $results = $page->children()->find("start=$start,limit=$limit, sort=-date"); $pagination = $results->renderPager(); echo $results->render(); And it works up to a point but then starts doing some crazy stuff! (like adding a new number for another list page which doesnt exist, e.g. page=4 when the limit only allows for 3 pages of list). any help would be amazing. b

...and ideally fastest way. Where "equal" means that both arrays have the same set of elements, while order may be different. Straightforward way is to use double foreach, but I'm wondering if there is more elegant way with selectors and PW API.

I think there is a bug in ProcessPageAdd Module. PW 2.4.0 If I try to add an Page by selecting a template with the big button on the right side in Admin 'Add New' and no parent site is given as GET Parameter like: http://example.org/admin/page/add/?template_id=37 the form will appear not complete and without submit button. EDIT: 10 min later .... Ah, its not the module its the Javascript ProcessPageAdd.js. If there is only one page in the list to select, the selection cannot be changed, and the submit button doesn't appear.

**** UPDATE *** nevermind. seems to be an issue with my server/php. by testing it on another server, everything runs as expected. thanks! ******************** Hey ryan! i ran in a very special problem today: i moved a page to another server. (Im using V2.3) everything is good, except: i cant login as admin - because there is a problem rendering the submitbutton... in ProcessLogin.module i get a strange error: "Fatal error: Call to a member function attr() on a non-object in /Applications/MAMP/htdocs/[...]/wire/modules/Process/ProcessLogin/ProcessLogin.module on line 123" this is caused by trying to add the submitbutton rendered by InputfieldSubmit.module.... BUT: if i uncomment 123: $this->submitField->attr('name', 'login_submit'); 124: $this->submitField->attr('value', $this->_('Login')); // Login form: submit login button and 134: $this->form->add($this->submitField); everything of the loginscreen gets sucessful rendered (but without a login button, which is... well.. unusable the module itself (version 100) is fine, and taken fresh from git.. (i'm running in the same problem using the password-forget module)