Leaderboard

I'm pretty close to having native core support for multi-language page names. It's something I wanted to add originally in 2.1, but just didn't know exactly how without adding lots of overhead. After marinating on it for a long time, an easy way to accomplish it finally became apparent. A nice thing about it is that it does it with near zero overhead. It won't be as fancy as the LanguageLocalizedURL module, but it should be good for people that have relatively simple needs. It's the one feature that we were missing that would really let the multi-language fields sing, and it should lead the way for making more fieldtypes multi-language capable. It works by enabling you to specify an alternate name for each page, for each language. When a page is accessed at its alternate URL, then the language is automatically detected and set for the request. Combined with multi-language fields or multi-language alternate fields, it provides a full multi-language solution without need for multiple trees or having to use any code to set the language. It's not the right solution for all situations, but for some situations, it'll be quite nice. Lets say you've got the page /about-us/contact/. For the "about-us" page you've set the Spanish language name to be "quienes-somos", and for the "contact" page you've set the Spanish language name to be "contacto". When the URL /quienes-somos/contacto/ is accessed, it's technically referring to the same page as /about-us/contact/, except that the user's language is automatically set to Spanish, and thus any multi-language fields output in Spanish. Calls to $page->url on any other pages also output the Spanish URLs. You don't have to define alternate labels for all pages if you don't want to. So long as there is just one of them in the URL (like in the rootParent, for example) then it'll be able to detect the language automatically. In order to avoid problems with having multiple URLs displaying the same content, it doesn't let you access the page with a URL like /about-us/contacto/ (English and Spanish mashup), because both of those pages have their names translated. So if you accessed such a URL, it would 301 redirect to the Spanish version. Here's a screenshot that might help to explain how these things are defined. This will be committed to the core within the next few days, as part of the LanguageSupport group of modules, but I'm going to leave it as an uninstalled alpha then beta module, until ProcessWire 2.4.

Hey, if anyone should think about writning a on-page editing module this might be helpful: http://vitalets.github.com/x-editable/demo.html Greets, Nico

Not sure if this has already been suggested, but for the less php literate among us it would be great to have some sort of repository of php scripts on the PW website for formatting template data, i.e. the php snippets for outputting different kinds of menus, breadcrumbs, bloglists, etc. Similar to a database or list of modules, but specifically for the templating side of things, where you don't require a full-on module. Right now you have to scour the forums (or write your own code) if you're looking to do something beyond the basics that are included in the default templates.

Page References Tab This little module adds a new tab, References, to the page editor. There it lists pages referencing the page that is being edited (title, path, field). There are also links to view or edit the listed pages (if they're viewable/editable). Only fields of type FieldtypePage are considered to be references and system fields are not listed at all (roles, permissions). It's nothing much, but as the subject has turned up a couple of times in the forums, I decided to give it a try. So watch out what you're asking! Screenshot Links Modules directory: http://modules.processwire.com/modules/page-references-tab/ GitHub: https://github.com/niklaka/PageReferencesTab

Here's my first processwire site: www.a-cat.nl ported from modx, the design was already ported from wordpress to modx. HTML Kickstart is used for the basic structure. I had someone do the porting from modx. There are still a number of layout issues with it, having to do with html kickstart margins mainly, but all in all this site is pretty much as I like it. The amazing and awesome apeisa thumbnails module is used to make all the images that are used all over the place in this site, that really makes a difference in speeding up writing new articles, I used to crop the images offline, but now it is a snap. The site also uses the ProCache module, so tell me how fast it feels. Any suggestions welcome! I am sooo happy I found processwire, I come from modx evolution which was/is absolutely great. Processwire is what I hoped modx would grow into. If you want to know why I now went for processwire read the former leading german modx guy who really nailed it for me in this page where he explains why he left modx and went for processwire. With processwire I might have to learn a bit more about php, but from what I see so far processwire really delivers on speed, flexibility and simplicity..

Wow this is awesome news ryan! I will help to test for sure! First answers from 3 swiss guys - no surprise because we have 4 languages in Switzerland and therefore lots of websites need to be multilingual

I honestly don't understand the confusion with pages. When everything are pages, that's really all you have to know. Couldn't be any simpler...

Good interview Ryan. Confident in your product, I like that. And so you should be

So, addHook automagically add the method to the pageImage object. I thought hooks where a defined set (like render, save and so on...). I was blown away by the power of PW as CMF, but i'm on the way to get blown away by the power of module development! I considered client side generation of the image, with css or a js/canvas solution, but integrating the functionality in PW just has that The Right Way™ feeling. Also, i need to show 70+ images per page and this could be too much for the client side. Thank you so much, this is often regarded as a vibrant and helping community, now i can confirm that!

I'm interrupting my vegetative state on the forum to say that I went for Linode after my last message ("I'm not a forum kind of person" ) and I'm very happy with it. I still have the 19.95$/month where I keep three production websites and all my experiments and developing stuff. Never had a single problem and learned a lot in the way.

Wanze why, you're already here This is correct. Just the hook function would be like this. public function greyscale(HookEvent $event){ $img = $event->object; $arg1 = $event->arguments[0]; // do things with image // return image object for chaining $event->return = $event->object; } Which would allow you to do things like: echo $im->size(10,0)->greyscale('arg1','arg2')->url;

I thought it was Mambo, phpNuke and News Publisher

I think it would be great and make sense to have repositories of scripts and modules that are approved by the PW members to ensure they're quality modules. With launching the new PW website we're working on it will come.

Hi everyone! With Batcher you can batch-edit and create Pages in the Pw Admin. If you install this module, you get a new Page "Batcher" under Setup. Modules page: http://modules.processwire.com/modules/process-batcher/ Github: https://github.com/wanze/ProcessBatcher Editing How does it work? Search your pages with a selector. You can check if you want to include also hidden/unpublished pages with the filters. Select the pages you want to execute an action (the action only gets executed on "checked" pages). Select the action and if necessary, additional data like the new parent or the new template. Execute. Supported actions: Publish/Unpublish Pages Hide/Unhide Pages Lock/Unlock Pages Trash Pages Delete Pages Change Parent Change Template Batcher does the following permission checkings for the current user: Don't display pages that are not editable Remove Actions if the user doesn't have the permissions (page-delete, page-move, page-template, page-lock) Important notes: When changing a template, data in fields of the old template which are not assigned to the new template gets deleted. When changing the parent, the template of the new parent must accept the pages template as children. This is a setting in the template under "family". Creating How does it work? Select a parent where your new pages will be added as children Add as many pages as you want by clicking "add Page" Click "Create Pages" You must enter a title and choose a template. The name is optional: If left empty, Pw will generate this for you. Includes permission checking and Family template restrictions. This means in detail: The selected parent must accept children and their template The pages template must accept the parents template User needs the permission to add children to the selected parents template User needs the permission to create Pages for the chosen Template Batch-creating tips The chosen template and the statuses are always cloned from the last row. So if you need to add 30 pages with the same template, define it first and the click "add Page" - it'll make your life easier ;-) You can drag & drop the table rows should you want to change the order. The dragging looks ugly but it works. For the lazy dogs and keybord hackers among us, you can add a new row by pressing "ctrl+n". This works (at least in firefox) only if no input has focus. After adding a new row, the title input gets the focus. By pressing 3 times tab you arrive at the published-checkbox, here the short-cut works. Restrict Batcher for a user to only allow editing or creating Create permissions "batcher-edit" and/or "batcher-add". As soon those exists, the module checks if the current user has the permissions. If you only need batch creating, check out the following module by Soma: http://processwire.com/talk/topic/2138-process-tools-create-pages-wip/ Cheers

This module provides simplified (no fancy diff etc. features available, at least yet) version control for text type fields. Originally introduced in another post as a proof of concept, I'm now considering it stable enough to deserve a thread of it's own here. Just so that you know: I've tested this module in multiple ProcessWire installations, three or four different versions in total running on two different platforms, but it still hasn't seen too much real world use. Any information you folks can provide me about how well (or badly) it worked (or didn't work) for you would be considered extremely helpful! So, what does it do? When editing pages, fields with old revisions available show up with a new icon in their header bars. By hovering that icon you get a list of available revisions and by clicking any one of those the value of that particular field is reverted to that revision. No changes are made to page until you choose a revision and save the page, which means that you can keep switching between revisions to get an idea what's really changed without inadvertently causing any content to change. How does it work? Behind the scenes hooks provided by ProcessWire are utilized to catch page edits. If text fields (such as FieldtypeText, FieldtypeTextarea etc.) selected at module configuration to be tracked were changed, their values (along with some metadata) are saved to two custom database tables. See attached screenshots for better idea about how this thing works. Please note that before you've selected at least one template + field combination to be tracked via module settings nothing will be saved to database! Getting started Module is available at GitHub: https://github.com/teppokoivula/VersionControlForTextFields. Here's a direct download link if that's what you prefer. Installation instructions etc. are available at README.md. If you've got any questions, feel free to post them here or PM me!

I have an integer field and wanted to take advantage of the HTML5 'number' input type, but the type refuses to save in the backend. (On version 2.2.9 and have tried a couple of admin themes including default.)

I think that technically multi-trees still provides for the most flexibility and will still be the right solution for many. There is kind of an assumption with multi-language page names that every page in the structure is applicable regardless of language. Also, I'm guessing that the LanguageLocalizedURL module will still be a good solution for many as well. But the truth is, I don't build a lot of multi-language sites, so I don't know all the scenarios as well as you guys. But I am building a multi-language site right now (that needs to support 6+ languages initially, with 17k+ pages), and the existing multi-language options weren't working quite right for this project, so decided to pursue this instead. You can use either. How you handle the URL segments outside of a page's actual path is up to you. As a matter of keeping it simple, I would probably stick to more abstract URL segments that aren't language specific. But your "page-name-en" and "page-name-de" as page names will set the language. I'll rely on you guys to tell me what I'm missing. I'll try to get this committed to the core later this week for anyone that wants to play with it. But I would hold off using it on production sites until we're further along with it. When the module is installed, every page in your site gets inputs for each language for the page "name" field (like in the screenshot). In order for the page to automatically switch languages based on URL, then the page itself OR one of it's parents must have the name defined in the target language. The URL is what ultimately triggers what language gets set to the user, and thus what language gets displayed in multi-language fields, static translations, etc. The behavior of it is basically identical to the existing $page->name field. In fact, it keeps the other language page names right alongside the 'name' field in the existing pages table. In this way, the data is searchable, selectable and loads with pages, without extra overhead.

Can anyone like a post of mine? 666 is evil edit: thanks Wanze

Yes it isn't saved when selected HTML5 and save...

Well I think most people think page == what you see instead of page == container

Ryan, I think Dave is having problems when trying to save field settings as a number field. Not in position to test if I can reproduce it (I'm on sleep already).

I think that traditional version control with Git or the equivalent is great for template files, front-end development files and your own custom modules. When it comes to defining the templates and fields on the admin side, it's better to do this from the admin rather than migrating SQL queries or the like. So someone in your team should be the gatekeeper for these administration resources.

Thanks Ryan, this is a huge feature. Being able to do full multilingual sites, without the need for multiple trees and all from the core installation - this makes what was already a great multilingual solution, almost perfect. Looking forward to testing! Could you elaborate on the situations where you think it would not be appropriate to use this new feature? I can't think of any. How will this work with selectors? Can you use either language urls to get the same page? or will there be one definite url that you have to use in a selector? I am also wondering how would this work with categories - if for example I am using a Page field for categories, and do the category filtering via the url segment, could I do for example page-name-en/category-AA-en and then page-name-de/category-AA-de to get the same result?

I think it is a good alternative to the client who only has a budget for a desktop site, but wants to later add a mobile site. Instead of redeveloping the desktop site using responsive web design (one of my personal nightmares), it would be much easier to just develop a mobile responsive site at a different domain.

When I'm installing to a new server where I'm not totally sure about the capabilities of it, I install a fresh/new copy of PW just to test and see if the installer complains about anything. That doesn't mean you have to use that fresh copy for the actual site, but it does give you a picture of potential issues that might need to be addressed on the server side. Based on the error message you got (a missing image) I would guess that not all the files made it over in the transfer, and it might be as simple as just attempting to transfer them again. However, the error you got was a Warning rather than a fatal error, so it shouldn't prevent the site from running. There's always a chance you were getting the same warning on your dev server, but didn't see it because debug mode was off.

Did I already say I love you?!

How much time per day do you spend looking at the light of the screen? I would guess too much... I prefer to stay away from it as much as I can, and reading on paper is great for this. Plus, you can do it on a coffee table outside or on a bench by the river Now I bought a kobo e-reader. With the e-ink technology It really feels like paper and I recommend it to everyone.

http://www.tyssendesign.com.au/articles/cms/cms-review-processwire/

Using published option is actually worst and most unelegant. You then can't use published anymore... Option 2 is the simplest and most elegant way to go. If you have no template file you can't view them directly. It's there for this reason.

In fact, the functionality for this is simple - allow users to post links to each gist they want to list here, on submit split the gust ID off the end of the URL, check it's accessible (not private) and the sky's the limit Obviously some thought needs to go into categorisation and other relevant fields, but aside from that it's relatively straightforward.

Yes addHook is to add a new method to whatever you like. addHookProperty is to add a property to the object. addHookAfter/Before is hooking into events like save etc. You could also go with something like $page->image->greyscale(100,100)->url; and just leave out the size() and do it in greyscale. Endless possibilities.

Hi arjen, You must give your editor role this permission : "Administer users (role must also have template edit access)". + the Editor needs edit permission on your User template. Can the editor see the users now if you move the Page outside of "admin"?

Pete: I think this is something much simpler. Something along these lines: modules directory = github snippets directory = gist

Glad you got it sorted out. Good luck with the rest of your project.

Hi everyone, Event Mentor is now running on ProcessWire and ProCache (it previously on Hero Framework). It's also linked up with DigitalDeliveryApp to handle payments and digital downloads. Site design by monodesign. Cheers Marty

Pete, just a heads-up that I sent you a pull request regarding Multisite support and a pile of other changes I thought were necessary/useful.. Edit: as an afterthought, should probably have sent those as separate pull requests. Not familiar enough with GitHub yet. I hope there's some way to choose which commits you're willing to merge (if any.) Also: didn't read this thread properly before making changes, so I've managed to miss all this 404-related stuff. One of those commits would change hook from Page::render to ProcessPageView::pageNotFound, which shouldn't break anything (except that it changes slightly those cases where sitemap gets rendered, which was exactly my intention) but that might be slightly dangerous still. Works OK on those platforms where I've had the chance to test it, but that may not be good enough yet.

Ryan, You are right of course Funny, when i wrote the js code I knew something is missing but I couldn't figure it out then. Corrected my post.

Hi Giovanni and welcome! This is a very interesting first question You can write an autoload module which adds the greyscale method with a Hook to the PageImage class. Check out the /site/modules/Helloworld.module for examples. I have never used these hooks which extend a class with methods, but it would be something like this: Edit: I don't know if you can access variables from the Pageimage class inside the makeGreyscale method. So sample code below could be completely wrong. Ryan, Soma, Apeisa, Nik, Teppo etc. where are you? //In your module... public function init() { $this->addHook('Pageimage::greyscale', $this, 'makeGreyscale'); } //This is only sample code... public function makeGreyscale(HookEvent $event) { $img = $event->object; //Make a new image file that is greyscale. Otherwise you could apply your image filter directly to $img $basename = basename($img->basename(), '.' . $img->ext()); $basename .= '-greyscale.' . $img->ext(); $filename = $img->pagefiles->path() . $basename; $greyscale = clone $img; $greyscale->setFilename($filename); //Make it greyscale //... $event->return = $greyscale; }

Hey, UD-Media is a german hoster. And they offer a feature-request system. So some weeks ago I posted there if they could add PW to the "1-Click-Install" stuff and today I got a mail that it will be available with the next software update they are doing. Much love to them: Go and register yourself there: udmedia.de (and support me by clicking this link before this ) They are really great and a lot cheaper then my old hoster I left two years ago. Greets, Nico

@antknight: they don't matter - in this case. You should take a look at this post by nik where he explains pretty comprehensively how this stuff works

$news = $page->rootParent->find("template=news-item, limit=5, sort=-date"); echo "<ul>"; foreach ($news as $newsitem) { echo "<li><a href='{$newsitem->url}'>{$newsitem->rootParent->title} - {$newsitem->title}</a></li>"; echo "<span>{$newsitem->date}</span>"; } echo "</ul>"; That should be enough. There's no need for "if($page->path === '/')" either, since $page->rootParent always points to parent page closest to root except while viewing root page itself (in which case it points to current page.) Exactly what you need for a task like this

Just let me know when I can refresh Captain Hook.

This should be working now on the latest dev. Ryan commited a fix already .

Version 0.9.2 of this module (just pushed to GitHub) introduces support for multi-language fields. See commit details for more info. I've also brought in some minor fixes etc. during this weekend, so if you've installed this module you should consider updating.

I know the problem you described. Normally, I just fixed the paths by hand in the editor - possible if you only have around 10 images used. My current workflow is to develope a site under a subdomain, for example dev.example.com and later make it example.com . So I'm just avoiding sub-directories. Maybe it would be possible to replace all <img src".."> directly with some SQL Queries and a little bit of Regex magic.

This is nice if your client is using the side and you're not longer developing the site. Then it's a little bit of a security measure not do easily delete pages, users and stuff. In Development on the other hand, it's really sometimes a little bit frustrating. I'm always using the "Page-Delete" and the "Page Copy" Modules just to be faster. Maybe a solution would be a switch - if debug or development modus is active, you get those easy delete links and batch operations. If not, everything will require some more steps for security.

I was thinking it would be good if it was something people could contribute to fairly easily. I'm sure that a lot of ProcessWire users here have accomplished a lot of really cool things inside of their templates using the API, and if there were a central place that they could then submit those for the benefit of others, that would save people having to re-invent the wheel or ask on the forums. Which leaves more time for Ryan and others to work on the core and various modules Some kind of basic gatekeeping/moderation would probably be necessary to ensure a minimum quality standard for the scripts.

I think something like what you've linked to there diogo may already be on the cards for the future. I do really like how they've laid that out over at Symphony so maybe something similar to that would be good - I do like the way I looked at the page and thought "yep, that would be pretty easy to do in PW" and already had myself thinking about the code behind it. Definitely makes a change from other systems I've used where it would be more a case of "I wonder if this is possible?"

I like how they implemented this on symphony (ya again, i know). On the downloads section of the site they have extensions and utilities. Utilities would be more or less this kind of snippets. http://symphony-cms.com/download/xslt-utilities/

For US hosting I can't recommend Liquidweb highly enough. For cloud hosting, which suits me better on one of my higher traffic websites, I use their other company Storm on Demand. I use them because I've never had any real problems in the past several years with them, and it's managed VPS so I don't have to spend time installing modules or upgrading things. They're always happy to install modules for you on your VPS and do pretty much whatever you ask them to do. The bit that I really like though is that they proactively monitor their servers. Once when there was actually a problem and the server hit a fatal issue in the middle of the night, their monitoring software sent me an email saying there was an issue, had automatically rebooted the VPS less than a minute later and I was emailed once again once it was back up. Then a technician sent an email a little while later saying it was a hardware fault (this is on Liquidweb, so not the cloud hosting) and the faulty hardware was replaced very quickly. All the tech support emails to me occurred overnight and my site was down for no more than a few minutes at most - on other hosts I've experienced hours of downtime and it's often only when you get a client calling you that you even realise there was a problem to start with - that obviously doesn't look professional! They have their own datacentres too, with a new one finished recently and are showing no signs of slowing down, so I'm not worried they're going to disappear off the face of the planet one day either. For hosting my UK sites I use EUKHost. My experience with them is mixed on the support-front (seems to depend who you speak to at this company which I've experienced many other places too), but generally positive on their VPS offerings and the prices are very hard to beat. Their VPS packages are also managed and their staff are also happy to install anything you need - I even have several caching modules and FFMPEG on one VPS, the latter being something that not a lot of hosts will install as it can eat up quite a lot of system resources, but from what I can tell EUKHost don't oversell so it's not a problem. Another great company I've used before in the US is Site5. They're still going strong and the only reason I moved away from them and ended up at Liquidweb is because I needed a VPS at that stage and they didn't offer them at the time.