Leaderboard

I've written a textformatter module for transforming SoundCloud URLs into SoundCloud widgets. It is customizable, so the user is able to select color, auto-play and comment visibility options. Being based on the YouTube/Vimeo textformatter by Ryan, it is working in the same way. I hope you like it. TextformatterSoundcloudEmbed.module

Two days ago, an idea about a new admin theme came to my mind. Some hours later, I've crafted a first concept in Adobe Fireworks.... The look and feel of the admin is important Two months ago, I've introduced some teachers into ProcessWire. They were none-technically people. At the end, they knew how to use the admin panel to create content or update a gallery on their new page. However at some points, they got confused with parts of the admin theme -beside the problems with our concept on how to use fields and templates for creating content. I think one factor why Wordpress became so large, was the great Adminpanel. It works well and easy (as long as you have a blog and not a twenty-plugins-for-text-pages-site). Editing content on a daily basis is the main task of my customer. I've to take this aspect serious. Problems I wanted to solve Have the page tree always visible. If I do not click the right link, it will be closed after I've finished editing my site More visuals like icons. Simplify some workflows. Creating 3 or 4 pages can result in multiple unnecessary clicks. More focus on important links like the tabs. Guide my customer through some action. Help them to repeat simple tasks. The concept First: Nothing is perfect and its not possible to find one single solution for everything. This was just done in a couple of hours and it's only the first iteration. Quick action button Next to the ProcessWire logo is the quick "Quick Actions" button. It should be possible, to configure it like: "Create a new Page with Template X with page Y as a parent". Use it for skyscrapers, news or galleries. (Yes i know, the arrow is pointing upwards. This is wrong) Two column layout The page tree is always visible (as long as we are in the pages view). It can be navigated as the normal page-tree. If you click "edit" it will become highlighted. Every action that would take you to a new page, would be displayed in the other half of the monitor. Speaking of a "half monitor" - I think that most people use a screen resolution of atleast 1300px. The sidebar should take up to 1/3 of this. On smaller screens, it will become hidden by default or we just simply step back to single pages for each view. If the content is to long, the sidebar becomes scrollable. Page tree I like the Template Decorator made by mindplay.dk. It fits the concept well with black outline icons for every type of template. The same icons could be used in the Quick action menu. I'm note sure what to do with the "move" action. To Do list Think more about the behavior of the elements. Design the modules view. Rework the search and the top menu. Options to "brand" the panel for agencies while keeping the ProcessWire logos. What happens if we are on mobile (small screen) devices? Listen to your feedback.

Ok I'm stupid, as I placed an exit in core to debug something... not my day I guess.

Looks like I broke the dev installer with yesterday's commit. Sorry about that. It was just an exception that needed to be caught–PDO throws an exception in a spot where mysqli doesn't, so didn't think to add one. And now realize I must have had PDO's exception mode turned off when I tested. This is now fixed.

No need for double redirects i think, just define it in your site/config.php: $config->http404PageID = 27; This line is from wire/config.php. Setting it in site/config.php should override. Just replace '27' with the id of any page you desire. Untested and maybe i'm overlooking an obvious drawback but this should work.

Hi everybody, Just wanted to share something that many of us already know of: while Page name settings restrict it to "Any combination of letters (a-z), numbers (0-9), dashes or underscores (no spaces)", you can use the dot in the name of your page. That's it

I have had to rewrite it because the alpha transparency wasn't supported at all. I just have pushed the version 0.0.8 to GitHub. There are some other fixes and changes with the version 0.0.8: added enhanced support for Thumbnails module, including permanent storage for CropRectangleCoords and params fixed / rewritten all bg-color stuff to support rgba alpha channel fixed a E-Notice with IPTC prepare changed the params of method resize, width, height to be the same like in new ImageSizer, ($sharpen can have value 'none') I will also update the first post of this thread.

Namespaces actually won't solve that particular issue unless someone opts to create their own namespace in their template file. That's something they could do now if they wanted to. So the switch to namespaces in PW's core won't change anything in this regard. If they want to overwrite a locally scoped API variable with their own, they will still be able to do it. I haven't updated the roadmap yet, but i'm slating namespaces for PW 3.0 rather than 2.4. Namespaces are going to require all modules to have "namespace ProcessWire" at the top. Either that, or use long/ugly syntax to access PW API calls. Likewise for template files (though I'm hoping to find a way to abstract that to compiled templates or something, so folks don't have to do this unless they want to). Once a module is updated for namespaces, it won't be compatible with previous versions of ProcessWire. Basically, it's all and a bigger and more annoying change (for most users) than I originally thought. But it's still a necessary one. Given the lack of compatibility for modules, I think it all needs to be tied to a larger version number like 3.0. Though if all goes well with the pre-compiled, auto-namespaced template file option I'm working on, then theoretically it could be applied to modules too. Such a solution would be applied to template files/modules that don't set their own namespace. That may enable us to add namespaces in the 2.x version tree, but I'm not confident enough that this solution will work in full just yet. I'm actually already working on 3.0 and have been for some time, so it'll probably be the next version of ProcessWire after 2.4 or 2.5, regardless of whether it ends up being 3.0 or 2.5, or 2.6.

something like this: $im = new ImageSizer($targetPath); $im->resize($targetWidth, $targetHeight); //or $im->width($targetWidth, $options); // $options are optional!

Phone Number Fieldtype A new fieldtype to enter phone numbers with 4 integer values for country, area code, number and extension and format the output based on predefined or custom options. StyledOutput The most common usage option will be: echo $page->fieldname //eg. +1 (123) 456-7890 x123 This provides a fully formatted phone number, based on the output format chosen from module's configuration page, or with the format override option (if enabled), when entering a phone number on a page. This is a shortcut that produces the same output as: echo $page->fieldname->formattedNumber //eg. +1 (123) 456-7890 x123 Alternate styled options are: echo $page->fieldname->formattedNumberNoExt: //eg. +1 (123) 456-7890 echo $page->fieldname->formattedNumberNoCtry: //eg. (123) 456-7890 x123 echo $page->fieldname->formattedNumberNoCtryNoExt: //eg. (123) 456-7890 echo $page->fieldname->unformattedNumber: //eg. 11234567890123 echo $page->fieldname->unformattedNumberNoExt: //eg. 11234567890 echo $page->fieldname->unformattedNumberNoCtry: //eg. 1234567890123 echo $page->fieldname->unformattedNumberNoCtryNoExt: //eg. 1234567890 Of course the actual output is determined by the selected format output Raw Output You can output the values for the component parts of the phone number like this: echo $page->fieldname->country; echo $page->fieldname->area_code; echo $page->fieldname->number; echo $page->fieldname->extension; Output for mobile compatibility To get iOS and other mobile platforms to recognize numbers and be able to automatically dial them, use something like this: echo '<a href="tel:+'.$page->fieldname->unformattedNumberNoExt.'">'.$page->fieldname->formattedNumber.'</a>'; Selectors for searching The component parts can be used in selectors like this: $pages->find("phone.area_code=123"); Field Settings There is a field settings for the width of the inputs in pixels. There is a field settings for the width of the inputs in pixels. You can also choose whether to display the country and extension fields for input. Off by default. There is an additional checkbox that determines whether there is an option to override the default format option on a per entry basis, which will be useful when styling phone numbers from different countries on the one website. Off by default. Custom formatting options On the module's configuration page you can choose from predefined formats, or create custom formats using syntax like this: {+[phoneCountry] }{([phoneAreaCode]) }{[phoneNumber,0,3]-}{[phoneNumber,3,4]}{ x[phoneExtension]} which generates: +1 (123) 456-7890 x123 Each component is surrounded by { } The names of the component parts are surrounded by [ ] Two comma separated numbers after the component name are used to get certain parts of the number using php's substr function, allowing for complete flexibility. Anything outside the [ ] is used directly: +,-,(,),x, spaces, etc - whatever every you want to use. There are lots of complicated rules around numbers changing when dialed from different locations. A simple example is for Australia. When dialing from within Australia, area codes start with a 0, but when dialing from another country, the 0 must be omitted. You can write a simple format to handle this. The following truncates the first number from an Australian two digit area code: {+[phoneCountry] }{([phoneAreaCode,1,1]) }{[phoneNumber,0,4] }{ [phoneNumber,4,4]}{ x[phoneExtension]} which generates: +1 (7) 1234 5678 x123 even though the full "07" is stored in the area code field. Where to get Available from github: https://github.com/adrianbj/FieldtypePhone And the modules directory: http://modules.processwire.com/modules/fieldtype-phone/ To Do Need to increase the number of pre-defined formats. There seem to be so many options and no real standards, so I thought rather than create a huge list of options that no-one will use, I thought I'd wait and get you guys to contribute them as you need them. Either post your formats here, or send me a PR on github and I'll add them. How to install Download and place the module folder named "FieldtypePhone" in: /site/modules/ In the admin control panel, go to Modules. At the bottom of the screen, click the "Check for New Modules" button. Now scroll to the FieldtypePhone module and click "Install". The required InputfieldPhone will get installed automatically. Create a new Field with the new "Phone" Fieldtype. Choose a Phone Output Format from the details tab. Acknowledgments This module uses code from Soma's DimensionFieldtype and the core FieldtypeDatetime module - thanks guys for making it so easy.

Template Cache and $page->render($options) If you ever use the $page->render() to render out partials (of another page using its template file) and use template cache for the pages you're going to render and the page where you render it, it will create a cachefile. So if you go to that previously rendered and cached page, it will render that partial. If the page is accessed before a cache is created, it will cache this one and render that in as the partial, so kinda turned around. Funny effect. And many mmms and oaaahhhs To get a better understanding what's happening read on. Simple example code from a list page to render partials of articles (likely) // from the list pages template $markup = ''; foreach($products as $key => $child) { $markup .= "<dl>"; $markup .= $child->render(array('isOverview' => true, 'class' => $class)); $markup .= "</dl>"; } echo $markup; And in the template of the article // in article template file if(isset($options['isOverview']) && $options['isOverview'] == true) { // render small partial $class = $options['class']; $markup = "<dd class='$class'> <h4>$page->title</h4> <p>$page->summary</p> <a href='$page->url'>details</a> </dd>"; } else { // render complete article $markup = "<div class='product-details'> <h1>$page->title</h1> $page->body </div>"; } // output echo $markup; So now the render call $markup .= $child->render( array('isOverview' => true, 'class' => $class) ); in the list template will cache the page it renders (the small view of it). Thus if you access the page directly it will serve the cached small view of it. Ups. Solutions This is without specifying a different template file in the first argument in the render(). The effect doesn't happen when you, let's say create a new template file (ie article-small.php) and use that to render the page. Since this new template file is not connected to the template in PW it also has no cache for that render. To show what I mean is the following with the first argument the file you want the view to render. $markup .= $child->render("product-small.php", array("isOverview" => true, "class" => $class)); Still following me? Ok there's also another method to not allow a cache file to be created. There's a default options set in the render() in PW. Bingo! allowCache is what we can also use. $markup .= $child->render("product-small.php", array( "allowCache" => false, "isOverview" => true, "class" => $class )); And everything's back to normal. Just wanted to write down a little thing, as I stumbled over this recently, to scatter some keywords about this here . I think this isn't really documented somewhere but I thought it was maybe mentioned by Ryan in a thread about when he added this feature: http://processwire.com/talk/topic/3145-multiple-views-for-templates/page-2?hl=%2Brender+%2Bcaller#entry32876. Edit: Zaaakkkk and it's in Google 9 minutes !

Hey, after some days of work I finished my new admin theme called "Dark Business". Just try it out: https://github.com/NicoKnoll/Dark-Business---Admin-Theme

I promised I would share my summer-project when I got a bit further along and now most of basic design is up on the test server (still just test content though, only some of it will be there in production). Two pages remain to be styled and some minor touch-ups are left for sure, but the gist of the simple design should be visible. Clean Scandinavian has been the motto. Will update to publishable version over the coming week/weeks. I will also clean up the code and do some validation fixing etc during that time. Any suggestions, pointers and tips from you pros would be much appreciated (tough love is the ticket). Keep in mind that I am not a pro and that apart from a sole static site I helped a buddy with 10 years ago, this is my first attempt at any of this (html, design, php, cms etc), so spare me the sharpest ax. A testament to the Processwire excellence - and to all of you helpful souls on this page - is that I have been able to get at least this far with no prior experience, so I would like to extend a heartfelt thanks to Ryan, Soma, Teppo and all the rest of you that have helped form this product in general, and taken the time to help me out on specific questions. You truly rock! re le vo DOT se/en

Soma, you no more should use exit for that sort of "rapid debugging"! Maybe you should use the "advanced rapid debug" method like: die("<p style='margin:10px;padding:20px;background-color:sienna;color:white;'>RIP :: now I'm dead, because Soma has shot me here: <br />" . __FILE__ . ' : ' . __LINE__ . '</p>');

@horst, I really like this way of thinkin' !

Ok, I think I might know what is going on. You say "If my image is called image1-cover". Is "image1-cover" the filename of the image, eg image1-cover.jpg or is it the name of the image field in PW? You need to reference the image by its field name. On a page you can do: echo $page->image1_cover->first()->filename; This line references the current page, then the image field name (the first image if the field is a multiple image field), then the filename of that image. You can also reference fields from other pages, but I'll leave it simple for now. Does that help?

In the above code I have forgotten the channels, so the correct code could be: function getMaxMem() { // read PHP maxMemory from php.ini $sMem = trim(ini_get('memory_limit')); preg_match('/^[0-9].*([k|K|m|M|g|G])$/', $sMem, $match); $char = isset($match[1]) ? $match[1] : ''; switch(strtoupper($char)) { case 'G': $maxMem = intval(str_replace(array('G','g'),'',$sMem)) * 1073741824; break; case 'M': $maxMem = intval(str_replace(array('M','m'),'',$sMem)) * 1048576; break; case 'K': $maxMem = intval(str_replace(array('K','k'),'',$sMem)) * 1024; break; default: $maxMem = intval($sMem); } return $maxMem; } function checkMemoryForImage($imageFilename, $maxMem) { // images pixel $size = getimagesize($imageFilename); $channels = isset($size['channels']) && $size['channels']>0 && $size['channels']<=4 ? $size['channels'] : 3; $imgMem = $size[0] * $size[1] * $channels; // read current allocated memory $curMem = memory_get_usage(true); // memory_get_usage() is always available with PHP since 5.2.1 // check if we have enough RAM to resize the image return ($maxMem - $curMem > 2.5 * $imgMem) ? true : false; } $maxMem = getMaxMem(); foreach($imageFiles as $imageFile) { if(!checkMemoryForImage($imageFile, $maxMem)) { throw new WireException("Cannot load the imagefile {$imageFile->name} into Memory! Imagedimensions are to large."); // or e.g. with modules use $this->error("Cannot load the imagefile {$imageFile->name} into Memory! Imagedimensions are to large.") continue; } // do the resize ... }

Currently you can't pass multiline arguments to Hanna code. But I'm not sure how user friendly that looks even if you could. What I would probably suggest is to populate your content in a dedicated field on the page and have your Hanna code automatically look in that field. For example, your [col2] Hanna code might look like this: <?php if(!empty($attr['content'])) $content = $attr['content']; // use content attribute if supplied else $content = $page->col2; // otherwise pull from "col2" field on page // ...now $content is ready for you to use

You might try adding this to the end of your /site/config.php: $config->sessionName = "sevarf2"; session_name($config->sessionName); session_set_cookie_params(0, '/', '.mydomain.com');

Thinking about that you seem to have your app mainly working under "/members/". Why not just add that? $pages->get("/members/")->get("id=1733"); $members = $pages->get("/members/"); $members->get("id=1322"); And you don't have to care about trash.

Yes it does work, as the I use the input names and in dimensions inputfield I set them to "fieldname_width, fieldname_height", so this seems to work fine.

Bill, Just to clarify what Adrian is saying...If you have a multiple image field (i.e. set to a number <1>), that image field will return an array (0 = unlimited, btw). Hence, you would need to loop through the array using a foreach if you want the multiple images, or can select a particular image in the array, using either "first", which grabs the first image, or eq($n) which is retrieval using an index...where $n is the index

@Ipa For linux servers "http://www.test.com/Kapitalize/WORDS/" is different then "http://www.test.com/kapitalize/words/". So two different locations. On a windows environment, their's no difference. It's the same url. So you have 1 location. I think for consistency, always use lowercase then there's no issue. I would recommend using lowercase in all situations even if you do not use ProcessWire.

Hi Bill, You can simply add the .xml part in the name of the page. PW will accept it gladly. What I still don't understand is why you use $page->path instead of $page->url. javascript can't access your computer folders, it only works with urls... or am I missing something?

I haven't updated the code in the modules directory yet, but take a look at the attached screenshot. I have set up custom formatting options, similar to the way the DateTime output formatting options work. The user can choose from some pre-defined options, or edit an existing format to output as they want. So now you can choose an output format and then output the formatted phone number on the front-end with: $page->fieldname->formattedNumber or you can manually format by using the component parts as described in the initial post above. The formatted version is generated on the fly and not stored in the database. Now I am wondering how many predefined formats I should set up. There are quite a lot of different formats, but not sure that there are any official standards: http://en.wikipedia.org/wiki/National_conventions_for_writing_telephone_numbers Anyone out there an expert on phone number formats, or have any strong thoughts/ideas on this? Also, does anyone have any comments on the format code syntax I set up, which you can see in the screenshot. Does this seem intuitive? Any other ideas? I might attach the revised code here soon and ask for some feedback before updating it on github/module directory. One more thought - wonder if it might be useful to have a format over-ride option - an extra subfield that allows page specific formatting of a phone number - might be useful for example for an international business with office around the world to be able to apply different formats on different pages. Thanks

Bill, Are you aware of the difference between single and multiple image fields? Check the "Maximum files allowed" field on the details tab of your image field. If it is set to anything but "1" then you will need to do something like: <?php echo $image1_cover->first()->url; ?> If it is "1", then you must omit the "first()" I have used "url" as I would imagine that you don't really want "filename" as it would look something like: /var/www/root_folder/site/assets/files/xxxx/filename.jpg Does that help?

Same here, Sinnut & Mats. Install looks like to quit while creating database tables. Tried to import the SQL manually also didn't work. Quits after creating field_summary. The weird thing is it looks like the (install) SQL isn't changed. @Mats: //side note for no errors: on line 293 on the installer "error_reporting(0);" ps, Manually install ./wire/core/install.sql, and the installer will continue.

Peter, There's certainly nothing wrong with it but why do you use this form for internet forum postings? Seems a bit redundant and overly polite to be honest.

I was about to ask if its possible to add more info to the fields. Great addition thx !

In case you want it a little more simpler $pages->setOutputFormatting(false); $pag = $pages->find("template=basic-page"); foreach($pag as $p) { foreach($languages as $lang) { if($lang->isDefault()) continue; $p->set("status$lang", 1); $p->save(); } }

A customer wanted to disable save ( $config->demo ) for users with a specific role. I created a module for that. If you need it, it's over here. To select the role(s), go to the modules config settings. download at github

There is no different method. The same field can't be repeated on the same page because of how the database is built. The fieldset doesn't take any part on structuring the fields on the database, so you should consider it merely like a cosmetic thing for the admin. Right now, the only way to group fields as you want is the repeater, but I think that in your case the best would be to have independent fields like "group1_title", "group2_title" and edit their labels to read only "title". On the admin side it will be no different from your first idea.

Ryan, wouldn't it be better to check if the current available memory is enough for a image resize? If we restrict it in the config.php for 32M, all above that (64M, 128M, 256M, ...) have to change the setting. And if they don't know it, they first run into the limitation. I think if we try to find a point for the maximum we have to guess how much RAM PW has allocated before the call to image resize. I don't know how much memory PW allocated for a 'normal' ? request, but lets say it would be something like 14M for example, we have 18M for the image resize. We need memory for the source image and for the target image plus memory for the image operation(s). - lets use a factor 2.5 18 / factor 2.5 = 7.200.000 / 3 (channels RGB) = 2.400.000 (this would be the setting for the config.php)! This could be a image of 1250 x 1920 px. But it will crash if PW has allocated 15M and not 14M. That said, one possible way (without a setting in config.php) could be to check the available memory: function checkMemoryForImage($imageFilename) { // images pixel $size = getimagesize($imageFilename); $imgPix = $size[0] * $size[1]; // read PHP maxMemory from php.ini $sMem = trim(ini_get('memory_limit')); preg_match('/^[0-9].*([k|K|m|M|g|G])$/', $sMem, $match); $char = isset($match[1]) ? $match[1] : ''; switch(strtoupper($char)) { case 'G': $maxMem = intval(str_replace(array('G','g'),'',$sMem)) * 1073741824; break; case 'M': $maxMem = intval(str_replace(array('M','m'),'',$sMem)) * 1048576; break; case 'K': $maxMem = intval(str_replace(array('K','k'),'',$sMem)) * 1024; break; default: $maxMem = intval($sMem); } // read current allocated memory $curMem = memory_get_usage(true); // memory_get_usage() always is available with PHP since 5.2.1 // check if we have enough RAM to resize the image if($maxMem - $curMem > 2.5 * $imgPix) { return true; } return false; } The code is meant as example. There should be only one call per Request (or per Session?) to the php.ini to get the maxMem, and not one call per image resize, etc.

Or even better. By making it configurable, you can perfectly have a much lower default.

Sorry I got the answer.......... the query should................ $page->get('/item/')->children('title^='.$input->get->q);

What you'll probably want to do is: 1. Find all pages whose date_field is not empty but whose date_field is past $today. $what_you_dont_want = $this->pages->find("date_field>0, date_field<$today"); 2. now select what you want $what_you_want = $this->pages->find("template=template_with_date_field, id!=$what_you_dont_want, limit=$limit"); The general idea is: 1. Find all pages that you want to exclude. 2. Find ALL the pages but filter out the pages found in #1. Thoughts: You can use filter() method for this by finding all the pages you need first then filtering out what you don't want but this somehow messes up pagination by default as what I mentioned in the original post. BUT, ryan did say you can use setTotal() and setLimit() methods on the PageArray but I haven't tried it since I'd already found a solution but then was too lazy to rewrite

Built this Dutch site for friends of mine ( www.talk-about.nl ). It's a lightweight, straightforward website but sufficient for their needs and they are very happy with it. When it comes to computers they are a bit heavy-handed so I ended up doing the content editing myself. That experience made me change TinyMCE for CKEditor which in my opinion feels better. Installed Pro Cache and that makes the site lighting fast. First only could get it to work locally and not on the live server. Appears that Pro Cache is not working when PHP is in safe-mode. Used this as a study project and it made me very exited about ProcessWire.

Hi and welcome to PW. Simply set up a new permission called: page-publish and make sure that is checked for the admin user's role and unchecked for the others.

I understand and know this, but why do you need to get the translation when it is just already there. It will output in the language the user views the page ($user->language) This works just fine in the language the user view the page. echo $fields->get("body")->label; Edit: ah, hm it does not? Ok it doesn't get translated as with page fields. Since it's meant to be used for backend context there's no language value for fields settings. So you either use a $lang variable like this: $lang = $user->language->isDefault() ? "" : $user->language->id; // Default needs no id echo $fields->get("body")->get("label$lang"); Or a little hook to add method to the $fields template API var. // from template or a autoload module $fields->addHook("getLabel", null, "getLabelLang"); function getLabelLang($event){ $field = $event->arguments(0); $lang = wire("user")->language->isDefault() ? "" : wire("user")->language->id; $event->return = wire("fields")->get($field)->get("label$lang"); } // now we use it and it will recognize user lang echo $fields->getLabel("body");

small update to the german laguage pack. In the zip are following new files: wire--core--pages-php.json wire--core--wirehttp-php.json wire--core--wireupload-php.json wire--modules--fieldtype--fieldtypecomments--commentfilterakismet-module.json wire--modules--fieldtype--fieldtypecomments--fieldtypecomments-module.json wire--modules--fieldtype--fieldtypecomments--inputfieldcommentsadmin-module.json wire--modules--languagesupport--languagesupportfields-module.json wire--modules--languagesupport--languagesupportpagenames-module.json I took them from Radek's cz files and translated them. Maybe someone (yellowled?) can check/correct them before loading up to GitHub? Some phrases are ... difficult to translate. de-DE.zip