Leaderboard

Is it possible you don't use a page field, but the custom select field like http://modules.processwire.com/modules/fieldtype-select/?

Just wanted to let you all know, I updated the module to 1.1.9 , with another new hook method to manipulate or add your very special case classes that will get added to list_tpl's "%s". To use this, here a little example to make it clearer. I want to add a class to my page with id 1001. Ok here we go. $nav = $modules->get("MarkupSimpleNavigation"); function hookGetListClass(HookEvent $event){ $child = $event->arguments('page'); // current rendered page item (in naviation) $class = $event->arguments('class'); // the class string, may be empty or filled if($child->id == 1001){ // add your checks, use API or whatever... daytime... $event->return .= " yourclass"; // add your class names } } $nav->addHookAfter('getListClass', null, 'hookGetListClass'); echo $nav->render(); Added this to readme

there are some more padding and margin in px. So I skipped this grid. Because of jackpot.css: the code of html5boilerplate and normalize is used by a lot of grids/frameworks. Also you can pick your needed extras from this resources to complete your own work. Best will be, if you try to build a site with gridiculo. Then you see, if it's ok for you. There are so many grids/frameworks to satisfy nearly everyones need. description of my experience (RWD beginner) in short words: looking for a simple grid (no Bootstrap, Foundation,etc!). Then study the code of some (no px, only em+%). I'm a little bit oldstyle and like to work from desktop to mobile instead of mobile-first. Descision to try Kube at first. Took a simple static ready-designed site (from my demos and test resources) to make it responsive. Work my way through the code. I'm surprised how easy and fast this was finished. I could keep my style and design and make it responsive anyway. Little bit customizing, had to build a responsive navigation. Also important: at the end I changed the px in media-queries to em (to get full text-zoom and site-zoom). @media only screen and (min-width: 480px) and (max-width: 767px) @media only screen and (min-width: 30em) and (max-width: 47.9375em) After that, I tried it with another site. Same experience. The sites are also running in IE8. Yesterday I used the respond.js (which mentioned some posts above) with the demo site. Now IE8 is also getting responsive. Nice to see. Maybe when have more time, I will try this new discovered PocketGrid This is very minimalistic, only 2 classes. But seems to be very flexible. We will see... yes!!

Easily insert any complex HTML, Javascript or PHP output in your ProcessWire content by creating your own Hanna code tags. This module is based loosely on the WordPress Hana Code Insert plugin. A Hanna code tag looks like [[hello_world]]. A Hanna code tag with attributes looks like [[hello_world foo=bar" bar="foo]] using HTML style attributes or [[hello_world foo=bar, bar=foo]] using ProcessWire selector style attributes. After installing the module, you define your Hanna codes in Setup > Hanna Code. These Hanna codes that you define can then be entered within your body copy (or other text where you allow) and they will be replaced with the values defined or generated by your Hanna code. A common use case is to embed scripts or other bits of HTML or codes that would usually be stripped out by an editor like TinyMCE. However, Hanna codes can be more than just static snippets--they can be dynamic PHP or Javascript that outputs different things according to the request. PHP-based Hanna codes have access to the entire ProcessWire API. Hanna code accepts named attributes in the tag that can be passed as variables to PHP and Javascript Hanna codes. These attributes can be specified either in HTML attribute format or ProcessWire selector format. In either case, quotes should be used around the attribute value when the value contains whitespace or a comma. How to install Place the module files in /site/modules/TextformatterHannaCode/ In your admin, click Modules > Check for new modules Click install for TextformatterHannaCode Now to go Setup > Fields and locate the Textarea field(s) that you want to use Hanna codes with ("body" for instance). When editing the field, click the details tab, and select "Hanna Code" as the Textformatter. Save. Now go to Setup > Hanna Code and start defining your Hanna Codes! You may want to use one of the examples from this document to get started. Tag format Below is a Hanna code tag named hello_world with no attributes. If you pasted this into your body copy, you would get whatever the replacement value is that you defined. [[hello_world]] Below is a Hanna code tag named hello_world being passed attributes of foo, bar and foobar. If this were a PHP-based Hanna code, it would receive the variables $foo, $bar and $foobar: [[hello_world foo="bar" bar="foo" foobar="foo bar"]] Below is the same Hanna code tag as above, but with attributes more like ProcessWire selectors. You can use whatever format you prefer. Just note that unlike regular ProcessWire selectors, quotes (single or double) are required around any value that has whitespace. [[hello_world, foo=bar, bar=foo, foobar="foo bar"]] How to use Please make sure that you have completed the How to install section first. Then in your admin, go to Setup > Hanna Codes. Each Hanna code that you add has a type of either: Text/HTML, Javascript or PHP. The Text/HTML type is literally self explanatory in that your [[custom-tag]] is replaced with exactly the text you paste in. Anywhere that you type your [[custom-tag]] in your body copy will be replaced with exactly the static text you defined. More power opens up with the Javascript and/or PHP types of codes. These codes execute at runtime and thus can contain specific logic to produce different results. In fact, PHP Hanna codes have access to the entire ProcessWire API and are executed in the same manner as template files. Your PHP-based Hanna code should simply "echo" or "print" the replacement value. PHP example Create a new Hanna code with the name "children". Select "PHP" as the type. Paste in the following for the code: foreach($page->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; } Now go and edit a page that has children. In the body copy, enter [[children]] in the place where you want the output to appear. View the page, and you should see the rendered list of links to children. PHP example, part 2 Now lets take the above example further... Go back and edit your "children" Hanna code, as we are going to modify it to respond to a "parent" attribute. Change the code to this: if(isset($parent)) { // If $parent is an ID or path, lets convert it to a Page $parent = $pages->get($parent); } else { // otherwise lets assume the current page is the parent $parent = $page; } foreach($parent->children as $child) { echo "<p><a href='$child->url'>$child->title</a>"; } Go back and edit the page where you previously inserted the [[children]] tag, and change it to: [[children, parent=1]] (specifying the homepage) or [[children, parent=/path/to/some/parent/]] if you want to try something else. View the page and you should now see it showing the children of the homepage (or of another parent you specified). Please see the Javascript and PHP usage notes on the Hanna code entry screen. Security There are major security implications with a tool that will let you enter unfiltered text and code from your web browser. As a result, Hanna codes are meant for definition only by superusers and we recommend keeping it that way. Download Download the Hanna Code module from the ProcessWire modules page or from GitHub.

Since you guys asked for it, I'll take a stab at a case study on the development process. Most of the development was done in about a week and a half. I started with the basic profile, but it ended up being something somewhat similar to the Blog profile in terms of how it's structured. Below I'll cover some details on the biggest parts of the project, which included data conversion, the template structure, the front-end development and anything else I can think of. Data Conversion from WordPress to ProcessWire One of the larger parts of the project was converting all of the data over from WordPress to ProcessWire. I wrote a conversion script so that we could re-import as many times as needed since new stories get added to cmscritic.com almost daily. In order to get the data out of WordPress, I queried the WordPress database directly (my local copy of it anyway) to extract what we needed from the tables wp_posts for the blog posts and pages, and then wp_terms, wp_term_relationships, and wp_term_taxonomy for the topics and tags. WordPress stores its TinyMCE text in a state that is something in between text and HTML, with the most obvious thing being that there are no <p> tags present in the wp_posts database. Rather than trying to figure out the full methodology behind that, I just included WP's wp-formatting.php file and ran the wpautop() function on the body text before inserting into ProcessWire. I know a lot of people have bad things to say about WordPress's architecture, but I must admit that the fact that I can just include a single file from WordPress's core without worrying about any other dependencies was a nice situation, at least in this case. In order to keep track of the WordPress pages imported into ProcessWire through repeat imports, I kept a "wpid" field in ProcessWire. That just held the WordPress post ID from the wp_posts table. That way, when importing, I could very easily tell if we needed to create a new page or modify an existing one. Another factor that had to be considered during import was that the site used a lot of "Hana code", which looked like [hana-code-insert name="something" /]. I solved this by making our own version of the Hanna code module, which was posted earlier this week. Here's an abbreviated look at how to import posts from WordPress to ProcessWire: $wpdb = new PDO("mysql:dbname=wp_cmscritic;host=localhost", "root", "root", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $posts = wire('pages')->get('/posts/'); $sql = " SELECT * FROM wp_posts WHERE post_type='post' AND post_status='publish' ORDER BY post_date "; $query = $wpdb->prepare($sql); $query->execute(); while($row = $query->fetch(PDO::FETCH_ASSOC)) { $post = $posts->child("wpid=$row[ID]"); // do we already have this post? if(!$post->id) { // create a new post $post = new Page(); $post->template = 'post'; $post->parent = $posts; echo "Creating new post...\n"; } $post->of(false); $post->name = wire('sanitizer')->pageName($row['post_name']); $post->title = $row['post_title']; $post->date = $row['post_date']; $post->summary = $row['post_excerpt']; $post->wpid = $row['ID']; // assign the bodycopy after adding <p> tags // the wpautop() function is from WordPress /wp-includes/wp-formatting.php $post->body = wpautop($row['post_content']); $post->save(); echo "Saved post: $post->path\n"; } What I've left out here is the importing of images, topics, tags, and setting the correct authors for each post. If anyone is interested, I'll be happy to go more in depth on that, but didn't want to overwhelm this message with code. Template File Structure This site makes use of the $config->prependTemplateFile to automatically include the file _init.php before rendering a template file, and $config->appendTemplateFile to automatically include the file _main.php after. So the /site/config.php has this: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; You may recognize this as being the same setup from the Skyscrapers profile. The _init.php includes files containing functions we want to be available to all of our templates, and set default values for the regions we populate: /site/templates/_init.php /** * Include function and hook definition files * */ require_once("./includes/render.php"); require_once("./includes/hooks.php"); /** * Initialize variables populated by templates that get output in _main.php * */ $browserTitle = $page->get('browser_title|title'); $body = "<h1>" . $page->get('headline|title') . "</h1>" . $page->body; $side = ''; $renderMain = true; // whether to include the _main.php file The includes/render.php file that is included above includes several functions for generating markup of navigation and post summaries, or any other shared markup generation functions. Examples are renderPost(), renderNav(), renderTags(). This is similar to the blog.inc file from the Blog profile except that I'm letting these functions generate and return their own markup rather than splitting them into separate view files. I personally find this easier to maintain even if it's not as MVC. The includes/hooks.php sets up any hooks I want to be present for all of my templates. I could have also done this with an autoload module, but found this to just be a little simpler since my hooks were only needed on the front-end. The main hook of interest is one that makes all posts look like they live off the root "/" level rather than "/posts/" (where they actually live). This was in order to keep consistency with the URLs as they were in WordPress, so that the new site would have all the same URL as the old site, without the need for 301 redirects. /site/templates/includes/hooks.php /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } }); Our /site/templates/_main.php contains the entire markup for the overall template used site wide, from <html> to </html>. It outputs those variables we defined in _init.php in the right places. For example, $body gets output in the <div id='bodycopy'>, $side gets output in the right <aside>, and $browserTitle gets output in the <title> tag. /site/templates/_main.php <?php if($renderMain): ?> <html> <head> <title><?=$browserTitle?></title> </head> <body> <div id='masthead'> // ... </div> <div id='content'> <div id='bodycopy'><?=$body?></div> <aside id='sidebar'><?=$side?></aside> </div> <footer> // ... </footer> </body> </html> <?php endif; ?> We use the rest of the site's template files to simply populate those $body, $side and $browserTitle variables with the contents of the page. As an example, this is an abbreviated version of the /site/templates/post.php template: /site/templates/post.php // functions from /site/templates/includes/render.php $meta = renderMeta($page); $tags = renderTags($page); $authorBox = renderAuthor($page->createdUser); $comments = renderComments($page); $body = " <article class='post post-full'> <header> <h1>$page->title</h1> $meta </header> $page->body $tags $authorBox $comments </article> "; if(count($page->related)) { $side = "<h4>Related Stories</h4>" . renderNav($page->related); } What might also be of interest is the homepage template, as it handles the other part of routing of post URLs since they are living off the root rather than in /posts/. That means the homepage is what is triggering the render of each post: /site/templates/home.php if(strlen($input->urlSegment2)) { // we only accept 1 URL segment here, so 404 if there are any more throw new Wire404Exception(); } else if(strlen($input->urlSegment1)) { // render the blog post named in urlSegment1 $name = $sanitizer->pageName($input->urlSegment1); $post = $pages->get("/posts/")->child("name=$name"); if($post->id) echo $post->render(); else throw new Wire404Exception(); // tell _main.php not to include itself after this $renderMain = false; } else { // regular homepage output $limit = 7; // number of posts to render per page $posts = $pages->find("parent=/posts/, limit=$limit, sort=-date"); $body = renderPosts($posts); } The rest of the site's template files were handled in the same way. Though most were a little simpler than this. Several were simply blank, since the default values populated in _init.php were all that some needed. Front-end development using Foundation 4 The front-end was developed with the Foundation 4 CSS framework. I started with the Foundation blog template and then tweaked the markup and css till I had something that I thought was workable. Then Mike and I sent the _main.php template file back and forth a few times, tweaking and changing it further. There was no formal design process here. It was kind of a photoshop tennis (but in markup and CSS) where we collaborated on it equally, but all under Mike's direction. After a day or two of collaboration, I think we both felt like we had something that was very good for the reader, even if it didn't originate from a design in Photoshop or some other tool like that. I think it helps a lot that Foundation provides a great starting point and lends itself well to fine tuning it the way you want it. I also felt that the mobile-first methodology worked particularly well here. Comments System using Disqus We converted the comments system over to Disqus while the site was still running WordPress. This was done for a few reasons: Disqus comments provide one of the best experiences for the user, in my opinion. They also are platform agnostic, in that we could convert the whole site from WP to PW and not have to change a thing about the comments… no data conversion or importing necessary. Lastly, ProcessWire's built-in comments system is not quite as powerful as WordPress's yet, so I wanted cmscritic.com to get an upgrade in that area rather than anything else, and Disqus is definitely an upgrade from WP's comments. In order to ensure that Disqus could recognize the relations of comment threads to posts, we again made use of that $page->wpid variable that keeps the original WordPress ID, and also relates to the ID used by the Disqus comments. This is only for posts that originated in WordPress, as new posts use a ProcessWire-specific ID.

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.

I just pushed ProcessWire v2.3.1 to the dev branch. This is a fairly major change in that it switches the DB driver from mysqli to PDO. It meant changes to a large percentage of core files. ProcessWire still supports mysqli, but doesn't attempt to use it unless a module or a template asks for it via the $db API variable. The new API variable (for the PDO driver) is $database. More about PDO at php.net If you are using the dev branch, be careful and test thoroughly with this latest commit to it. Before upgrading, you may want to double check that your PHP supports PDO by looking at your phpinfo (CMD-F or CTRL-F for "PDO"), especially if you are running PHP 5.2.x (where PDO wasn't compiled in by default). Though if you are running PHP 5.2 (vs 5.3.8+) then you may want to just stick with ProcessWire 2.3.0 and upgrade your PHP version when possible. If you are using any modules that use the procedural version of mysqli functions (vs. the $this->db object oriented versions), or type-hint mysqli in methods, then those modules will no longer work. If you come across any modules that don't work with 2.3.1, please let me know here so that I can assist the author in updating them. Note that FormBuilder is one of the modules that does not work with 2.3.1, but I have posted an update in the FormBuilder board that corrects it–so be sure to download that version if you are tracking the dev branch of ProcessWire and using FormBuilder. What this new version adds: 1. New API variable $database that refers to the PDO database. The old $db API variable is still there and refers to mysqli for any modules that continue to use it. 2. New API variable $log that lets you easily log messages or errors to the system logs. Usage: $log->message("This saves this line to messages.txt"); $log->error("This saves this line to to errors.txt"); $log->save("my-log", "This saves this line to my-log.txt"); // Get an array of the last few entries saved to the messages log $entries = $log->get('messages'); // Get an array of the last 50 entries saved to my-log $entries = $log->get('my-log', 50); Note that as always, log files are located in /site/assets/logs/. 3. Conditional autoload modules. In PHP 5.3+, modules may now specify an anonymous function OR a selector string, rather than a boolean for the 'autoload' property returned by getModuleInfo(). PW runs the anonymous function after determining the current $page, so your module can make autoload decisions based on the $page (or any other factor you'd like), if desired. Lets say that we have a module that we only want to autoload when the template is 'admin': public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => function() { if(wire('page')->template == 'admin') return true; else return false; }); } And the same example but using a selector for autoload: public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => 'template=admin' ); } 4. Addition of $pages->add() method. Actually $pages->add($template, $parent, [string $name], [array $values]); This function adds a new page to the database and returns it. This is for syntax convenience, but using the old method is still perfectly fine too. Here's a few examples of usage: // add a new page using template basic-page under /about/ $newpage = $pages->add('basic-page', '/about/'); // same as above, but named 'contact' $newpage = $pages->add('basic-page', '/about/', 'contact'); // same, but populate the title field too $newpage = $pages->add('basic-page', '/about/', 'contact', array('title' => 'Contact Us')); // you can also do this, specifying the values array as 3rd argument: $newpage = $pages->add('basic-page', '/about/', array('title' => 'Contact Us')); $template and $parent are required, but may be objects, IDs, or string identifiers (like name for template, or path for page). When you add a new page and don't specify a 'name', then PW will make one up, guaranteed to be unique. 5. Module files that end in '.module.php' are now supported. So rather than ClassName.module, you may use ClassName.module.php if you prefer it. The purpose here is to support text editors that determine their syntax highlighting based on the file extension. More updates being made almost daily. Please report any issues you experience. Thanks, Ryan

Hi all, I've just pushed a new fully responsive site profile to Github: Unsemantic Site Profile for Processwire 2.3 After having tried seven zillion responsive grid systems, boilerplates, frameworks etc. I finally opted for Unsemantic Grid System. Mainly because it supports IE7, is lightweight and includes Compass/SASS. I've designed the profile as a starting point for development according to my needs. This includes almost no styling, an easy-to-use solution for placeholder images and three teaser boxes on the front page. In addition, I converted the .sass files that come with Unsemantic to .scss because I like the syntax better. Glad if you give it a try and find it an improvement for your workflow. You can see a preview here. Download from Github: https://github.com/christophlieck/UnsemanticSiteProfile

ProcessWire Online Installer Since there's now a shortcut to download latest stable PW http://grab.pw , I created a simple helper PHP script you can upload to your server to download and extract a new PW installation. Upload this php file to the server where you want to install latest ProcessWire Go to the browser and call this script. It will download and extract ProcessWire files. Once done successfully it will redirect to the installer. Downloaded zip the grabpw.php will be removed. If anything fails, make sure permission are correct on server and you remove files manually in case. I tested this on my local XAMPP (Mac) install and on some of my account on a ISP. Also I took some methods to download and extract files from my ModulesManager which seems to be "reliable" so far. Download The script can be found on github: https://github.com/somatonic/PWOnlineInstaller Why Just because it's cool. There's many ways to accomplish this task if you have ssh access for example using shell. Just wanted to have this alternative and maybe people find this useful too. @ryan. Do you think you could provide an latest dev shortcut url too?

ProcessWire2.+ Minify 1.0.3 This module helps you combine Javascript and CSS files into one, minified file to save on unnecessary HTTP requests and to compress files anywhere up to 80% (including already minified .js files). To use it, extract the attached zip file into your /site/modules/ directory and check for new modules in the ProcessWire Admin area, then install the module. Once installed, go to configure the module and, instead of this configuring anything for you, you can use the drop-down lists to build stylesheet and script code to place in your templates, grabbing a list of any stylesheets and scripts it finds in the /site/template/styles/ and /site/templates/scripts/ directories respectively. It's more of a helper than anything else, but it should take the guesswork out of configuring Minify for your site. Notes: This module contains a third-party library - Minify - which is subject to its own license (a copy is included in the attached zip file). I've left the module in-tact including its unit test files so there are more files than are necessary, but this will make it easier for me to upgrade the module if/when they release updates to that code. This module doesn't insert any code into your templates automatically - I think copying and pasting the code it currently outputs to the screen is more useful/configurable for more situations. It's worth using even if you only have one CSS or JS file as it will compress CSS files by about 80% and JS files by quite a lot too, plus since it handles caching on the server-side and does its own checks of the files it is serving (plus it's a dynamic URL), you can always be sure that it will serve the latest version of a CSS file (no more CTRL+F5 to show the new styles if your browser decides to cache it. You can change the /site/modules/Minify/min/config.php as you could if you were using Minify as a standalone script - tweak cache paths (default is your server's cache path) and other advanced settings here. Updates: v0.0.2 - now produces code that includes paths derived by ProcessWire at run-time so paths will be fine on localhost and live servers, removing potential issues when pushing a site live. v1.0.0 - bumped this up to a major version number since there appear to be no issues with the initial versions to speak of. Also implemented yellowled's input field suggestion (looks much better and easier to select for copy and paste purposes) and turned off autoload at ryan's suggestion. v1.0.1 - now recusrively searches for files inside subfolders under the scripts and styles directories using PHP 5's built-in iterator classes v1.0.2 - pull request from teppo - https://github.com/Notanotherdotcom/Minify/pull/1 v1.0.3 - updated Minify code to v2.1.7 which fixes a significant security flaw: https://groups.google.com/forum/#!msg/minify/cpN-ncKPFZE/kwYVpLMkfDwJ You can download the module here.

virgintribesa.com Created for Virgin South Africa Employee engagement - they're yet to have much content up there but the site is pretty much finished.

Today I just want to show a new page build with ProcessWire. It's nothing fancy but the client is more than happy. http://www.rv-heidenheim.de (german content) The local horse club had an old ugly Flashwebsite which we relaced with a fresh and modern PW site. The goal was to create an easy system to maintain content and to inform people about the club. Behind the scenes: Processwire with ProCache let the site run faster than any horse in the barn. Using the PageLink Field to create a menu structur. Skeletton 960px grid but right now we removed the mediaqueries. We will add the mobile view later. The weater widget uses this jQuery plugin. All widgets in the sidebar are pages and fully configurable by the backend user. A year ago, this was my first Processwire page. But it was never released and we made a complete new second version last month. First time I've used an icon font. Try fontello.com to build your own icon font. The site was designed on a friday evening and only 24 hours later the whole site was done. Using PW it's just a charm to build such small sites and let people insert their content.

Yes, you are correct, right now, I'm totally confused. I should first try to get clear picture myself of what I really want & how will it work. Thanks again

There are lot's of options for you, but I think all of them requires a custom coding (if you want to automate the process at all). It is pretty hard to help you at this point (no clear questions), but definitely when you have progressed a little you get lots of help from here. So I suggest as a first action try to draw more clear picture for us how you want the process to work.

That fixed it - thanks for your help gentlemen!

Besides PW being an amazing cms there are some amazing contributing coders here as well. I am loosing track of all the modules, tips and tricks coming out lately. Wished I could spend more time on PW but damn my job doesn't allow me.

Thanks for the kind words ezeey! Nothing works with multisite I hope to find some time this weekend to take a look. If you can provide any more information it would definitely help (how to reproduce, test site I can login etc).

simple and nice. I like it. The yahoo weather bothers me a little bit... english condition text on a german site. Maybe this 2 links (in german) are helpful to translate the condition text? Don't know, how much work this is... link 1 (read in the comments) link 2

Hi kalmtl, welcome! 1) Pw can handle > 1000 pages (games) without problems. It scales very well! If you have files/images assigned to your pages, then each page gets a folder where the files are stored. As long as your filesystem / server can handle the files, you won't have any problems. That said, I currently have a project with > 100'000 pages and ~ 1900 Users and everything works fine 2) + 3) Nope. Give your 'game' template the field it needs. Then you can import your old data straightforward with the API. There is also a module by ryan, Import Pages from CSV that maybe useful. If you have relational data separated in different tables, then you could build a similair structure in Pw with Pages, Templates and Page-fields. For Example, store the genres as pages too and in your game-template, create a page field 'genre' that links to a genre-page. Some sample code how easy you can create a new page: $p = new Page(); $p->template = 'game'; $p->parent = $pages->get('games'); $p->title = 'Awesome flash game'; $p->publisher = $pages->get('template=publisher, id=4322'); $p->genre = $pages->get('template=genre, name=action'); $p->year = 2011; $p->save();

This method is different from what we normally use for select options. As you can guess from the responses, we use page fields to build selects and the options are actual pages. http://processwire.com/videos/page-fieldtype/ This allows for much more flexible and dynamic building as the options are coming from pages. The select field you're using is completely different as you have options hardcoded into the field, you could just hardcode the labels in your template too. You know which key has which value. Or to make things simpler you could use the inputfield interface of the select field to get the options.. $options = $fields->selectfieldname->getInputfield($page)->getOptions(); echo $options[$page->selectfieldname];

The trick is to build up a string variable eg. $selector, based on the options chosen by the user and using that variable as part of something like: $images = $page->children($selector); This assumes of course that all your images are child pages of the main gallery page. You'll probably want $selector to end up being something like: sort=-camera_model, sort=resolution, sort=-size The way to build $selector can be seen in the Skyscraper's search.php file. For example, this section: if($input->get->keywords) { $value = $sanitizer->selectorValue($input->get->keywords); $selector .= "title|body%=$value, "; $summary["keywords"] = $sanitizer->entities($value); $input->whitelist('keywords', $value); } Each section like this appends more component parts to the $selector string using the '.=' notation. The $input->get->keywords refers to a variable passed from your form using the GET method. You could of course also use POST. GET will put the variables in the URL like ?keywords=word& etc. This is useful for allowing a user to bookmark or share a query link. I am not exactly sure your plans for the resolution and size selects - sounds like you want to offer sorting highest to lowest and lowest to highest? If so, you can build your selector using sort options. Take a look at the sort options on this page: http://processwire.com/api/selectors/ Once you have defined your $selector and searched and sorted the children with it, you can simply foreach through the images: foreach($images as $image){ echo $image->url ...... //etc } Hope that helps.

Greetings, I understand! And I am eager to put it out there. But I also want to make sure the first rendition is strong so it can be a good start, since I expect to keep improving it beyond the initial release. I promise to post here when I make progress. Thanks, Matthew

I'm not following. Do you want to search for a field name or search the contents of a field of the current page? $page->nameOfYourField Gets you the current page's field with that name. E.g. $page->title give's your the current page's title field (assuming it has a field with the name "title" ). So you can do echo $page->title; On the other hand $page->fields gives you an array of the fields attached to the current page (via its template). This is if you want the names of those fields. With arrays, you do a foreach if you want to echo them out, for instance. Edit: Also useful if you can state what you want to accomplish. In many cases, there are easier ways of going about tasks in PW...

Hi all, I've just released the site profile i mentioned first some days ago here. More info in this thread: http://processwire.com/talk/topic/3832-release-unsemantic-site-profile/ I completely agree. My approach is to use just a simple grid system (in the moment Unsemantic) and no pre-defined element styling whatsoever. If I need let's say styling for a form i pick it from elsewhere (for example Kube or Skeleton) and incorporate it into my css. Thus, I'm having control about nearly everything and just need to familiarize myself with the anatomy of the grid.

Little detail. Instead of $p->setOutputFormatting(false); you can also use $p->of(false);

Thanks Knoll Theres an issue with the width of the breadcrumb extending beyond the main div. Ill try and solve it later.

Updated URL from ProcessWire module directory: https://modules.processwire.com/modules/vi-translation-pack/

Hi Ovi, when looking at your code and your statement of what you can do in PHP, I think you just should start here. And yes, you also should use the "Hello World Module" as a skeleton too. For example, if you want to do something that isn't implemented in PW core, you can [write | implement] your somehow into templates, or you can create a module. As it should not be a big problem for you to write your working code, you may find it not an easy task to get the right Hook. (for me it is exactly that)And at the beginning you can do it like we all do (we, who are not belong to the pro's, - we, who are not be able to cite the core code when waken up in middle of the night, - we, who we need to learn and have fun with it): we drop a post here and describe what we want to do and then get perfect answers on what Hook would be best to use for it! --- Basically a module hooks into PW somewhere and somehow. You just need to kow where to hook in and when, (before or after). And you need to know how to access objects & values and how to return your result. That's all covered in the new great API-Documentation of Hooks! Read it and just go on

But what would you have left to do then? Oh yeah, more modules. Good point

One of the many things I love about PW is that whenever new features are added they always make sense. Not just Ryan's excellent descriptions, but the additions themselves. In this case I especially like the $pages->add method.

But now cheatsheet is a PW site and Ryan can edit it easily himself.

where to start? from out of my head: http://processwire.com/talk/topic/3265-fredi-friendly-frontend-editing/ http://processwire.com/talk/topic/3602-pw-online-installer-download-of-latest-pw-install-to-server/ http://processwire.com/talk/topic/3691-tutorial-a-quick-guide-to-processwire-for-those-transitioning-from-modx/ http://processwire.com/talk/topic/3745-hanna-code/ http://processwire.com/talk/topic/3474-admin-custom-pages-module/ and most importantly: http://processwire.com/talk/topic/3498-karena-savannah-cramer/

So, I guess the modules manager is the must module that should be installed

Unless you prefer separate trees for each language, you might want to consider the new LanguageSupportPageNames module (included with the core), which will let you accomplish that URL structure pretty easily. If you try it out, use the one from the dev branch, which is a little more up-to-date, as this module is in development. To accomplish the structure, you would do this: In Language support, assume that "nl" is your "default" language. So edit the "default" language and change the title to Nederlands or whatever the right spelling is. Add another language and name it "en", with title: "English". Install both the LanguageSupportFields and LanguageSupportPageNames modules (in that order), as they are not automatically installed with LanguageSupport. Though they are included with the core, so all you have to do is click "install". Change title field to be of type "TitleLanguage" and all relevant text fields to use TextareaLanguage or TextLanguage. Edit your homepage and click to "settings" tab. Make the "name" field be blank for Nederlands, and make it "en" for English. Check the box to make English active, if necessary. Save. Edit your About Us page, and again click to the "settings" tab. Make the default page name "over-ons" and the English page name "about-us". Do the same with any other pages. Keep in mind that the "name" field is optional for all pages. When left blank, it will just use the default (nl) name instead. But it should still be able to determine the proper language based on the URL, so long as you've configured the language names at the homepage.

You can only pass static strings to the __() function. At least, the translation parser will only be able to find static strings. The only reason you'd put a variable in a call to the __() function, is if you knew the text was already available translated, and wanted to retrieve the translated version. But that text would have had to appear statically, somewhere else in the file. To make a multi-langage image field, you can use a Repeater. Your repeater would contain two fields: 'image' and 'summary'. Make the 'image' field of type Image, and set to to contain max 1 image. Make the 'summary' field of type TextLanguage (or TextareaLanguage). The Image field is the next one on the list to make multi-language capable, so should be within the next major version of ProcessWire.

Did I already say I love you?!

Welcome to the forum ohthanks! I recommend using pages instead. Maybe something like this: product-page - table-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - table-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - table-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) fields in the template: - data1 - data2 - data3 - data4 In the table-page (parent) it is used for the headers. The row-page (child) it is used for data. The template doesn't need a file, only used for storing data. Only populated fields in the table-page (parent), filled with header names are used for the table headers Now you know wich fields to use from the child pages. Each child page is a row in your html table. --- For large amount of data, you can use the import CSV to pages module. ---- I like to use the MarkupAdminDataTable. look in: /wire/modules/Markup/MarkupAdminDataTable/MarkupAdminDataTable.module it's straight forward & not that difficult to understand. here some sort of example: $table = $this->modules->get("MarkupAdminDataTable"); $table->setEncodeEntities(false); $table->setSortable(true); $table->headerRow(array('name', 'of', 'header', 'items')); foreach($table as $row) { $table->row(array($row->data1, $row->data2, $row->data3, $row->data4)); } echo $table->render();