Leaderboard

ProcessWire ProFields is new product that will soon be available in the ProcessWire store. It consists of 4 really useful new modules: Textareas (Fieldtype + Inputfield) Multiplier (Fieldtype + Inputfield) Table (Fieldtype + Inputfield) AutoLinks (Textformatter) These modules are currently in beta testing, and I'll be posting screencasts to highlight some of the features of each over the next week or so. To start with, here is a screencast for Textareas: This video includes sound (narration) and I recommend viewing it at a larger size than above (preferably full screen), and bump it up to the 720p resolution so that you can see everything in better detail.

This looks great, Ryan. Processwire's modularity is, perhaps, its greatest asset. After working in Joomla and Wordpress for years, it's great to have a CMS that is dead-simple when you need it to be, but scales up easily for more complex sites. Keeping the core as clean as possible also makes it easy for people to get in the door, then add functionality as needed. I also find the current module licensing model to be an excellent compromise. Great work! Now, when can I give you my money?

See the FormBuilder or ProCache Dev version, as the plan is to license this in exactly the same way. Since this comes with multiple modules, I don't see a reason to have a single site license because you might like to use one module on one site and another on another site. So I'd rather just license this one as a buy-once use anywhere type thing. These modules won't be part of the core. They are a separate product from ProcessWire in the same way that FormBuilder and ProCache are. However there is one exception: FieldtypePageTable (not FieldtypeTable) is one of the ProFields and this one is being included in the core thanks to a sponsorship by Avoine. I'll be covering more about this Fieldtype soon, but it's already available in the dev branch and a great addition that I think many people will prefer to repeaters. The idea and concept for this field was designed by Apeisa and I think folks will love it. That's good to hear that you think so highly of these modules! But since nobody outside myself has developed a site with these modules, they definitely aren't essential to building a site with PW. Though they are certainly useful and big time savers! The tools essential to building great sites with PW will always be core. Like with FormBuilder and ProCache, the intention with premium modules is to provide time and/or resource saving tools for those that make a living from this and want additional tools to support their work. In addition, purchase of premium modules is a way to support the ProcessWire project as a whole (since we don't take donations). Where multi-language is needed, ProFields are intended to be used with ProcessWire's language alternate field support. Most ProFields involve lots of inputs and it's not practical to multiply those per language the way that FieldtypeTextLanguage does. Though they can work quite nicely in the language alternate context. Beyond language alternate support, Textareas can be used in a multi-language context, but since you define what each component is, you'd be responsible for defining separate components for each of your languages. Meaning, it's not specifically a multi-language field, but you can choose to use it in a manner that supports your multi-language needs. If we find that there are practical ways to expand upon any of the ProFields for further multi-language support, and there's sufficient demand for it, then we'll certain do what we can there too.

Hello fellow ProcessWire devs. I recently developed and launched the following site: http://whiteconst.com/ Specs: PW 2.4 Zurb Foundation 5 Full width layout + responsive design; font-scaling in certain situations Ajax page loading; window history pushstate CSS3 based loading animations (page to page, project modal) Heavily animated home page slideshow (built with sequencejs) Developed so that every page is properly indexed by search engines despite used of Ajax (each page has it's own unique URL; canonical meta tags also indicate to search engines what the official URL of a page is to prevent duplicate content cases) Form Builder module Hanna Code module XML Sitemap module Video Embed for YouTube/Vimeo module (don't know about this one? you should!) Custom module to that allows administrators to view all projects in the admin section using a table layout with more metadata screenshot: http://goo.gl/3HfJTW Custom modal to view projects Custom developed news blog (with categories, year archives, recent posts filters) Content is easily manageable by site admins All kinds of frontend coding to make the layouts look great, especially the project pages (image gallery, videos, etc.) This was a challenging project for several reasons. Several requirements and layouts were changed along the way. Also, whenever dealing with Ajax based page loading, that seems to complicate things by a factor of 3 (must take many other things into consideration for it to work properly and lots of edge cases). This was also the first PW site I did that needed a blog / news section. I didn't start with the Blog profile, but this was easy to roll. In fact, I like being able to build out the blog myself because of the greater control it provides. I wanted URLs to be formatted in a particular way. It needed to be Ajax based. I like naming things my own way (Blog or News? Post or Article?... WordPress's defaults are extremely confusing to the end user). At the end of the day, ProcessWire was a perfect fit for this project. - Jonathan

http://www.owengildersleeve.com/ - illustrator (built by CodeByBoy and edited by myself) http://ciaraphelan.com/ - illustrator (built by CodeByBoy and edited by myself) http://thehackneypeddler.co.uk/ - vintage bike shop (built myself)

@darrenc There are a couple of approaches you could take to set this up. I'll describe one that uses a symlink. As you already know this will only be a change to the repeater module I'd be tempted to create a symlink from the wire/modules directory from #2 into #3 and make sure that I had #2 switched over to what folks call a 'feature' branch. This is a branch of the codebase that you dedicate to adding just one thing which, in this case, would be your changes (or just one change) to the core repeater module. Here it is set out in a little more detail. In the root of your local 'working directory' you'd do... 'git checkout dev' so you have the dev branch checked out 'git checkout -b super-repeaters' (substituting 'super-repeaters' with a better name for your feature) which creates and checks out a new feature branch called "super-repeaters". Make sure your local installation's wire/modules/fieldtype/FieldtypeRepeater/ (the whole dir) is a symlink to your #2's wire/modules/fieldtype/FieldtypeRepeater/ directory. Any changes you make to the repeaters in your installation you are then making to the corresponding files in your working directory. When you've tested your code and are happy with it you 'git add' and 'git commit' as required into your super-repeaters branch. You can then send changes to github with 'git push origin super-repeaters' (or whatever your branch is called) and use github to create a PR to Ryan. A couple of gotcha's to look out for... 1) Make sure your text editor is setup for utf-8 file encoding with no BOM marker. 2) Make sure you setup the editor to use linux style end-of-lines (\n not \r\n or \r.) Hope that helps. Just ask if you need anything else.

In fact I know ryan likes to retype pull requests himself so he has full understanding of the code changes and tweaks them as necessary. This is opposed to my occasional blind acceptance of pull requests on my own modules that is definitely not best practice!

@darrenc In addition to adrian's remarks above, I've found that Ryan is great at picking up a good idea from a pull request and making whatever adjustments he feels necessary to slip it into the codebase. Don't worry about dotting every 'i' and crossing every 't' at this point; just get used to git and github and then make sure that your proposed changes make sense and have a good rationale and you have a good chance of seeing the code get accepted even if it is modified along the way.

This module is improved and extended successor to Version Control For Text Fields. It handles everything it's predecessor did -- providing basic version control features for page content -- and quite a bit more. Download or clone from GitHub: https://github.com/teppokoivula/VersionControl. This module requires ProcessWire 2.4.1 or later, mostly because of the file features, which require certain Pagefile and Pageimage methods to be hookable. There's no sensible way around this limitation; for those stuck with < 2.4.1, Version Control For Text Fields will remain a viable option. What does it do? While 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. The module also adds a History tab to page edit. This tab opens a view to the history of current page in the form of "revisions" -- each of which is a group of changes to page fields processed during one page save (similar to revisions in various source control applications). There are three actions you can perform on these revisions: adding comments, live previewing what the page might've looked in that revision and restoring the page to specific revision. One specific feature that has been a big thing for me personally is support for file (and image) fields, as the original version control module felt rather incomplete without it. I'm hoping to take this a lot further performance, stability and feature wise, but as it stands right now, it's already included here and should be fully functional. Watch the video preview here I prepared a little screencast outlining most of this: http://youtu.be/AkEt3W7meic. Considering that it was my first screencast ever, I'd like to think that it wasn't that bad.. but I might give it another shot at some point, this time planning a bit before hitting "record" Upgrading from Version Control For Text Fields For those already using Version Control For Text Fields, I've added something extra. If you upgrade that module to it's latest version, you should see a new checkbox in it's settings screen saying "Don't drop tables during uninstall". If you check this, uninstall the module and then remove it's files (this is required in order to install Version Control), your old data should be automagically imported to Version Control. Import has only been tested with limited amounts of demo data. Proper tests are yet to come, so please be careful with this feature! Update, 21.6.2015: as of today, this module is no longer in beta. While all the regular warnings still apply (making changes, including installing any new modules, on a production site should always be considered risky) Version Control has gone through pretty extensive testing, and should be as stable as any other module out there.

I do believe a new standard for screencasts has just been set!

@darrenc The way you submit enhancements/fixes to a project on github is to first fork the project, then make the changes to your forked version, then submit a pull request to the original project. Ryan will receive notification of your PR and he can then review and accept the changes as is, or modify them as needed. Obviously it's hard to know whether your changes will be coded the way Ryan would prefer or not. Depending on the change it might be just as productive to simply submit an issue asking for the enhancement. You could look through some of the previous PR and issues and see if you think your enhancement suggestion and your coding quality would make it better suited to one approach or the other. Sorry, not a definitive answer, but hopefully helpful.

I finally figured this one out. I had just about given up, when I thought to look in config.php, and lo and behold, there at the bottom was $config->httpHosts, which only contained the domains that were working. I added the other domains, and now the multisite module is working excellently.

I like the licence model where once I have purchased I may use on any site. Each model has it's benefits. For me the ease of managing a simple model where if I have bought it I can use it is a big one. Another thing I like is that if I have bought a module and learnt how to use it then there is nothing reducing my enthusiasm to use it on the next site I work on. I recognize that there is no 'one size fits all' and that therefore any solution has to be a compromise to some extent with some of the audience, all I can say personally is that the model used feels best to me.

Since users are pages with a certain template, you can access them after going to /setup/template/, choose Filters and set "Show System templates" to yes. From that point on you can add fields to users like on any other template.

yes i like wp for.install exploit script , irc bots , pharmz , game servers etc without wp i wolud have.to get my own hosting

MarkupCache is a simple module that enables you to cache any individual parts in a template. I'm working on a site now that has 500+ cities in a select pulldown generated from ProcessWire pages. Loading 500+ pages and creating the select options on every pageview isn't terribly efficient, but I didn't want to cache the whole template because it needed to support dynamic parameters in the URL. The solution was to cache just the code that generated the select options. Here's an example: $cache = $modules->get("MarkupCache"); if(!$data = $cache->get("something")) { // ... generate your markup in $data ... $cache->save($data); } echo $data; I left the markup generation code (the part that gets cached) out of the example above to keep it simple. Below is the same example as above, but filled out with code that finds the pages and generates the markup (the part that gets cached): $cache = $modules->get("MarkupCache"); if(!$data = $cache->get("city_options")) { foreach($pages->find("template=city, sort=name") as $city) { $data .= "<option value='{$city->id}'>{$city->title}</option>"; } $cache->save($data); } echo $data; That was an example of a place where this module might be useful, but of course this module can used to cache any snippets of code. By default, it caches the markup for an hour. If you wanted to cache it for a longer or shorter amount of time, you would just specify the number of seconds as a second parameter in the get() call. For example, this would keep a 60-second cache of the data: $cache->get("city_options", 60) I hope to have it posted to GitHub soon and it will be included in the ProcessWire distribution. If anyone wants it now, just let me know and I'll post it here or email it to you.

Don't forget to set setlocale(LC_ALL, 'de_DE'); when using strftime() Is that de_DE correct for German?

Ahhhhhh! Very clever/simple/elegant. You just gave me thousands of ideas for implementing sym/hard links. Thanks again, netcarver.

I am here with another issue noticed when running seige to benchmark stuffs. There is a bottle neck for SQL_CALC_FOUND_ROWS . I was going through this blog post http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/ and some of my own tests. I am running and testing on ~ 606267 pages. SELECT SQL_CALC_FOUND_ROWS * FROM `pages` LIMIT 5 you will get the result in between ~ 0.42 s to ~ 0.572 s When you are running it in two queries, say SELECT * FROM `pages` LIMIT 5 and SELECT COUNT(*) FROM `pages` you will get the result in ~ 0.014 s and 0.189 s respectively. So a total of ~ 0.203 s. So I feel it will be nice not to have the SQL_CALC_FOUND_ROWS always been used when running any queries. Some of the additional problems to be taken are the queries will be using joins and those will take more seconds. In my case it has been taking ~22 seconds and more when running. Thank you.

Yes. The whole home page slideshow uses that library. It's nice to work with once you get the hang of it.

All the WP sites I did in the past (way too many of them, now I switched entirely to PW, I even redid whole clients simple "brochure" websites pro-bono to save me the hassle) have been ok, but there's always something with the API that doesn't work quite right (future dates in queries, good luck!), maintenance issues, compatibility issues (loading 10 versions of jquery and the like). Some things might work right when developping, but often I need to change the plugins code to improve them, which is a problem. Then when new versions of everything comes out, it's a mess. WP sites don't seem to grow very well either, so as complexity increases, it all falls apart. Speed issues are also a big thing and really hard to optimize to get good load times. All that time waiting for the admin to do stuff is wasted time in billable hours (I charge a minimum of 30 mins for maintenance, most things take less than 15 mins to do, the process is usually much faster in PW I've found so far). Also take into account that when you do full-custom work like I do (I'm a designer AND a programmer), WP always comes with either too many or not enough features. That's time I need to just do configuration to get rid of the unneeded parts, which sometimes isn't really straightforward. I also do a lot of multilingual things, WP can do it with plugins, but the workflow is kinda weird and involves a lot of support calls from clients. Some of the features don't work so well either. So far what I've launched with PW is trouble free. It does everything much better and faster. I can say with big relief that WP's custom post types are a thing of the past. I was able to implement different relatively "complex" things (well, would be in WP) like 100% custom event systems, payment/donation systems, etc (hopefully will be able to package some of them nicely to reuse later and share in modules) in next to no time. Now I'm happier, clients are happier, work is faster, everybody wins.

Building sites for other people (clients) using Wordpress can be a time saver. But why usually happens with clients is that they will invariably ask "say, can we change this or add that to the design?" This is where I find Wordpress gets tricky to work with. You have to pull back all the onion layers from the theme. There is a lot of prefabricated structure with a themed WP install. Customizing a site can lead to more work and frustration than building a site from scratch. I found MODx much better to work with because you had a blank canvas to work with initially. Much more designer friendly in the long run. ProcessWire offers similar advantages. One thing that site owners have to deal with is the backend admin system. Some CMS platforms offer a million control settings and panels that seem overwhelming. This is where PW shines. I think it offers site owners a nice, fast, clean system...

@Soma, I just setup the whole thing, see: https://github.com/owzim/PWCaptainHookCLI Now the output of the array only has to be integrated into your html.

I love how this Module is clearly excellent for larger sites, useful for any site but not essential to building brilliant PW sites. Building an income stream for PW is a healthy thing to do and like the rest of PW it's clearly being done with care; thanks for this and the upcoming great new tools Ryan And nice to hear, from the vocal commentary, that not just the Admin i/f has a theme

I have also created a helper some time ago specific for InputfieldTinyMCE to strip non breaking spaces in text on saving. https://gist.github.com/somatonic/10330802

This is awesome Teppo! Of course near the end it looks like many versions are created as adding images saves the page behind the scenes via Ajax so that's one way you'll end up with a lot of revisions (did I remember that correctly or make it up?). I'm wondering if it's worth making it so it only stores revisions when updating image and file fields AFTER the Save button is pressed? Or did you already take that into account? Loving this module and it will be fascinating to see how you handled the image and file fields when I dig into the code

Huge release! Congratulations Teppo! I love the preview UI, very neat.

I'll keep it short: no. The longer version is that every time I've dealt with Wordpress it was to upgrade it due to security issues and every time I did that it broke a plugins and updatingthe plugins broke some template or other. Now I don't accept work with Wordpress unless it's to move a site away from Wordpress. The problem is that so many people out who use it are oblivious to the security issues that keep cropping up in their software but if you look at the update history every 2-3 updates fixes some XSS or other big security flaw. I actually used a hint from a website that allows you to check the version of any Wordpress website to highlight the issue to a customer whose WP was about 5 versions behind so you can - if you had the time - let folks know just how out of date and unsecure their sites are. This is almost certainly how hackers target sites too. You can do the same for Joomla easily too (same customer had a Joomla site on the early 1.x branch - some 15 versions behind the latest in the 1.x series and well behind the 3.X branch of course!).

adrian, extremely helpful and that completely makes sense. I'll brush up a bit more on git and then go from there. Thank you for following up.

In case anyone is wanting to access the item link or summary, you just need to add these to the makeCalendarItem function. $a->link = $this->cleanText($item->link['href']); $a->summary = $this->cleanText($item->summary); and edit the __construct function appropriately.

@xeo, what you want to do is not the intention of the module. In PW the urls follow the structure of the tree, if you would shorten your urls like you are saying, there would be problems with pages overriding other with the same name. Imagine that you have a page called "About" in the root of the website (mydomain.com/about), and you would write an article with the title "About". You would have a problem because they would share the same url. If you want to have short urls for your articles, you can put them under a parent that is on the root, and has a short name (not short title) -home --about --contacts --articles (name: a) ---article1 ---article2 This way, your article1 url would be mydomain/a/article1 If you want to have an even shorter url for the articles (avoiding urls like: mydomain/a/my-new-article-with-a-very-very-veeeeeeeeery-long-title), you can create a system that accepts their IDs on the URL (mydomain/a/123): <?php // on top of the template file of the "articles" page ("/a/") // url segments have to be activated on this template if ($input->urlSegments) { // if there are segments in the URL $id = (int)$input->urlSegment1; // get the first segment ant turn it into an integer $myURL = $pages->get("/a/")->find("id={$id}")->first()->url; // get the url of the page with the id in the segment if ($myURL && !$input->urlSegment2) { // if page exists and there's not a second segment $session->redirect($myURL); // redirect to the correct page } else { throw new PageNotFoundException(); // if not, throw a 404 } }