Leaderboard

- Not sure where to post this- I just made a country list and i thought it might be useful to someone so i put it on github. You could use this for example with the importpagescsv module to easily create country pages for use in your site, forms etc. For now it's English only ( i could add other languages if someone needed it) README.md About This is a complete ISO 3166-1 encoding list. It is listed in alphabetical order by the English short country name used by the ISO 3166/MA. There are currently 249 ISO 3166-1 countries. England, Northern-Ireland, Scotland and Wales are added to that because they are used by FIFA. It also contains the corresponding IOC and FIFA three letter codes and the filenames of the country flag image(s). Total countries: 253 Fileformat: txt file separated bij tabs Data is taken from: http://en.wikipedia....wiki/ISO_3166-1 and http://en.wikipedia....6_country_codes Flag icons I included the flag icons from http://icondrawer.com/free.php See the link for details and terms of use. You can also get the flags in a wide range of sizes and flavors from this awesome project: https://github.com/koppi/iso-country-flags-svg-collection For the least amount of hassle: https://github.com/koppi/iso-country-flags-svg-collection#download-the-icon-sets

I would like to provide this for sure. But so far I haven't seen that there is any demand for it. I'm sure the time will come. Well if they didn't think it was somehow incomplete, there wouldn't be any real incentive to have a paid package? But I know what you are saying, and that's why I'm not interested in having anything but the pure open source and free ProcessWire. On the other hand, I do like the idea of support packages and commercial modules-- they are special add-ons (separate from the core software) for people that want them. I don't think that having paid support options devalues anything else. The way I see it, it just is a form of insurance… a form of insurance that doesn't exist at present. None of us are obligated to support anything. We do it because we like to. But that's not a good enough answer for a company that depends on their web site. They want to know that if something happens that they can't solve, there is somebody obligated to help them in a timely manner. You can find that here in the forum, but it's based purely on the goodwill of the people here. I think it works now because our community is a nice size where it's easy to keep up with everything. When and if we get to the point of having 10x as many daily posts as we get now, it won't technically be possible for any individual to keep up with them all, at least not nearly as quickly. At that point, I think having more support options becomes a benefit to the perception of the project and helps attract big scale users that might otherwise look elsewhere. So it doesn't hurt to explore how best to handle the growth, even if we don't necessarily need it now. Here are some examples of commercial support for other platforms: WordPress: http://vip.wordpress.com/our-services/ Drupal: http://www.acquia.com/acquia-network-subscriptions MODX: http://modx.com/complete-maintenance-and-support/ Symphony: http://getsymphony.com/get-support/

Ok I just pushed an update. You can now disable transitions. I will at some point hide the additional options in a hidden settings layer. I will still have to see what I'll do with additional stuff. I also see adding some that's left off in the same sheet and give them a color code like advanced. Adding additional sheet that can be switched would aslo be nice, but not as trivial as it seems.

What should be the general structure/format of an article? I have a nice collection of advices from you, guys, which I gathered on this forums. And I think at least some of them could be converted into small wiki articles. But I'm not sure whether it is a good thing to duplicate information from the forums anywhere else. Also not sure my language skills are bearable enough to contribute to wiki.

I just discovered the Template of selectable page(s) option in the Selectable Pages section, which allows me to use a different template for the categories within /work/. Brilliant!

Welcome to the forums Thomas. It's not possible to physically resize an image on another server, but you certainly can resize it with CSS or width and/or height attributes in the <img> tag. But if you want an image you can physically manipulate, then it has to be on a file system that ProcessWire can write to. You can tell ProcessWire to pull an image from another server like this: $page->video_image = 'http://domain.com/path/to/file.jpg'; $page->save(); Once you've got the image in there, you can resize it like in your example. I'm assuming from the non-plural name 'video_image' that you've defined the field to only hold 1 image rather than many. Though the snippet above should work either way. Note you may need to add a $page->of(false); before the code example above if you are executing it from a template file. ProcessWire delivers pages to templates in an output-ready state where entities are encoded and such (something you wouldn't want when saving a page). So you just have to disable output formatting to put the page in a state where it can be saved, otherwise ProcessWire will throw an error. This isn't usually necessary in other API contexts, outside of template files.

Thanks arjen. I prefer the rewrites directly on apache because it's faster / uses less resources. A new version from PW is not a problem for me, because i don't touch the original. While deploying to live server, a shell script automatically prepends my additions to it. -- OFF-TOPIC -- Maybe someone is interested, i'll explain it in detail: - I store my projects in private git repositories on bitbucket.org - I have environment variables on my local machine, so I can differentiate in config.php which config is needed on runtime (like database, debug mode...). That allows me to have one version of the project which auomatically runs on live and development server - when i want to do a live or preview update, i just start a shell script which: 1. creates a fresh clone of the repository in a subdirectory like "live-2012-06-28" 2. if needed, it sets chown and chmod for caching directories 3. it compresses my javascript and css files with yui-compressor (my environment switch will print out minified in live and normal scripts in development) 4. it checks for htaccess-extra files, which then get prepended or appended to the original .htaccess (like redirects, expires) 5. the docroot is not a folder, it's a symlink. final step is to set the symlink to the new updated folder And thats it. I can make changes in my code without touching the PW core, push everything to git, and run the update script to deploy everything. If something goes wrong, I only have to reset the symlink to the previous version folder. A second script does nearly the same, but instead deploying live it depoys to a preview subdomain. So i can check my changes on the live server environment first, before destroying the live

Paid corporate / enterprise service offered by core developer(s) isn't such a bad thing, really. IMHO it would actually add to the credibility of ProcessWire as a high-quality "enterprise level" CMF/CMS -- though I do agree that it requires some serious planning. Anyway, isn't that exactly what Acquia is doing with Drupal?

Think you make a mistake with the 1.1 update, it should be way higher Really enjoy the isotope transitions, think they are GPU processed to. To select the cols is a big plus. Think I gonna love the narrowness of one column select! Screen pixels are expensive Hope to start next week with the first project in PW.

Thanks Arjen! This is the sort of stuff that PW was designed for, and I think is also the most fun stuff to develop with it. There is almost always a way around any pitfalls. Please keep us up to date with how your projects go and with any questions you run into along the way.

Regarding workflow: the default profile is pretty much always my starting point. It's rare that I don't end up repurposing the fields and templates that are already there to start building things out. Likewise, I usually end up just renaming (as necessary) and repopulating the pages that are already in the default profile. Then I will start adding new fields, followed by templates, specific to the needs of the site. While I try to determine most of the templates/fields that I'll need ahead of time, I will continue adding fields and templates throughout the entire development process as necessary to make the site do what I want it to. Most larger PW sites are pretty relational and make good use of Page references. But this is also the part that I think is most important to outline when it comes to workflow. This part is quite a bit different from other systems, but has major advantages. I try to make my selectable Page references part of the site's structure, if at all possible. For example, on tripsite.com, every bike tour has a "country" page reference field, and those countries are useful in the site's overall structure (Netherlands in this case): http://www.tripsite.com/countries/netherlands/ In other cases, page references might not fit as part of the site's general structure, so I'll have a /tools/ section in the site where they live. Though it's easy enough to make them function as pages, so I figure why not. Here are a few examples (they are all using the same template): Multi-page reference field "months" (April in this case): http://www.tripsite.com/tools/months/april/ Multi-page reference field "tour_types" (Guided in this case): http://www.tripsite.com/tools/tour-types/guided/ Page reference field "difficulty" (Difficult in this case): http://www.tripsite.com/tools/difficulty/difficult/ The template used on those pages is not much more than this: $tours = $pages->find("template=tour, {$page->parent->name}=$page, limit=10"); foreach($tours as $tour) { // output the tour } Admittedly, most of my projects are rebuilding existing sites, so I usually have some (or a lot) of data to migrate to the new site. This becomes a major component of the development workflow, so I figured I should mention it here. After I've setup the necessary fields and templates (and usually before front-end development), I'll work on bringing in the new data. If it's a relatively simple conversion job, I might use the ImportPagesCSV module. But most jobs require some markup replacement, character set conversion or other things, so I'll build my own import script. This is where I like to bootstrap PW from a command line PHP script. Here's a simple example: /import-airports.php #!/usr/bin/php <?php require("./index.php"); // bootstrap PW $fp = fopen("./airports.csv", "r"); while(false !== ($data = fgetcsv($fp))) { $page = new Page(); $page->template = 'airport'; $page->parent = '/building-types/airports/'; $page->title = $data[0]; $page->location = $data[1]; $page->year = $data[2]; $architectName = wire('sanitizer')->pageName($data[3], true); $architect = wire('pages')->get("/architects/$architectName/"); if(!$architect->id) { $architect = new Page(); $architect->template = 'architect'; $architect->parent = '/architects/'; $architect->title = $data[3]; $architect->name = $architectName; $architect->save(); } $page->architect = $architect; $page->save(); echo "\nCreated page: {$page->url}"; } Once I've got a lot of data to work with in the system, I'll start doing front-end development: creating the template files, markup, css and anything else necessary to handle the output for the site. The files from the basic profile either get used as a starting point, or replaced completely at this point. These are my main workflow components I can think of, but let me know if there are any specific areas you'd like more detail on or can think of anything I've missed.