Leaderboard

You can also put this on your homepage template: <?php $page = $pages->get(123); // replace by the page you want to replace the homepage with include("./{$page->template}.php");

Happened to have a PW site open, so I did some grepping (is that a word? should be..) and seems to me that you're absolutely right. No short tags found from core files. @Natetronn, I'm trying to avoid getting all evangelical here, so I'm keeping this as short as possible: IMHO learning enough PHP to write templates effectively is much easier task than learning enough of most templating languages out there to do the same. PHP has very good documentation (php.net), wide user base (try googling pretty much any problem you're having and add "stackoverflow" to your query, it's rare to find a question someone hasn't already answered there) and there are many fantastic tutorials floating around. "It's easier than you think." That said, I don't have that much experience with templating languages -- mostly I've used Twig and several in-company solutions, so I'm not much of an expert on this subject. All I can say is that after years of learning, fighting and cursing various templating languages and their shortcomings, being able to write templates in pure PHP is a bliss for me

PageListImageLabel Marty requested and sponsored a new module little while ago. http://processwire.c...t-image-option/ I just wanted to create a separate release thread. Many thanks to Marty for sponsoring and making this possible. This just shows how great this community is. So here it is the Page List Image Label module. It enables you to add thumbnails of images from the pages in the admin page tree. Download: http://modules.processwire.com/modules/page-list-image-label/ Github: https://github.com/somatonic/PageListImageLabel A screenshot of it in production. (old version)

Ryan, this might be helpful topic: http://stackoverflow.com/questions/3221771/how-do-you-get-php-symlinks-and-file-to-work-together-nicely It would be great to run many modules as symlinks, makes maintaining so much easier.

I exported a CSV file from freebase.com that contained all the skyscraper fields I wanted to use. Then I created a simple shell script to import it from the CSV. Note that I only used a shell script for convenience, you could just as easily do this from a ProcessWire template file if you preferred it or needed to do this from Windows, etc. Below is a simplified example of how to do this. The example is fictional and doesn't line up with the actual structure of the skyscrapers site, nor does it attempt to create page relations or import images. If you are interested in how to do that, let me know and I'll keep expanding on the example in this thread. But I wanted to keep it fairly simple to start. First, here is the contents of a CSV file with each line having a skyscraper building name, city, and height. /skyscrapers/skyscrapers.csv (Building, City, Height): Sears Tower, Chicago, 1400 John Hancock Tower, Chicago, 1210 Empire State Building, New York City, 1100 IBM Building, Atlanta, 860 Westin Peachtree, Atlanta, 790 Next, create a new template in ProcessWire and call it "skyscraper". Create a text field for "city", and an integer field for "height" and add them to the skyscraper template. Create a page called "/skyscrapers/" in ProcessWire, that will serve as the parent page for the skyscrapers we'll be adding. Here is the command-line script to load the ProcessWire API, read the CSV data, and create the pages. As I mentioned above, this could just as easily be done from a template, where the only difference would be that you wouldn't need the shebang (#!/usr/local/bin/php -q) at the beginning, nor would you need to include ProcessWire's index.php file. /skyscrapers/import_skyscrapers.sh: #!/usr/local/bin/php -q <?php // include ProcessWire's index file for API access // (this isn't necessary if you are doing this from a template file) include("./index.php"); $fp = fopen("./skyscrapers.csv", "r"); $template = wire('templates')->get("skyscraper"); $parent = wire('pages')->get("/skyscrapers/"); while(($data = fgetcsv($fp)) !== FALSE) { // create the page and set template and parent $skyscraper = new Page(); $skyscraper->template = $template; $skyscraper->parent = $parent; // set the skyscraper fields from the CSV list($building, $city, $height) = $data; $skyscraper->title = $building; $skyscraper->city = $city; $skyscraper->height = $height; // set the URL name, i.e. Sears Tower becomes "sears-tower" automatically $skyscraper->name = $building; // save the skyscraper $skyscraper->save(); echo "Created skyscraper: {$skyscraper->url}\n"; } To do the import, make the script executable and then run it from the command line: chmod +x .import_skyscrapers.sh ./import_skyscrapers.sh OR, if you are doing this from a template file, then load the page (that is using this template) in your web browser, and that will execute it. The output should be: Created skyscraper: /skyscrapers/sears-tower/ Created skyscraper: /skyscrapers/john-hancock-tower/ Created skyscraper: /skyscrapers/empire-state-building/ Created skyscraper: /skyscrapers/ibm-building/ Created skyscraper: /skyscrapers/westin-peachtree/ If you go into the ProcessWire admin, you should see your skyscrapers. I used an example of CSV file for simplicity, but the same method applies regardless of where you are pulling the data from (web service feeds, etc). For the actual skyscrapers demo site, I used Freebase's web services feed to pull the data and images, etc.

Hi, I'm currently trying to setup a multi server setup here and I was wondering if anybody has any experience in saving the /site/assets/files to a different server, currently I have a front-end templates server, a backend mysql server and a fileserver setup, I'm trying to implement PW into this flow, anybody has done this before? Kind regards!

Just a quick note about output formatting. You always want it on before outputting anything. This ensures that when you output $page->title (for instance) that characters like '&' will get entity encoded to '&', and the like. Whereas, if you were setting values to the page, you'd want it to store '&' rather than '&'. So updating an earlier example, you'd want to do this: echo "<a href='{$p->url}'>{$p->title}</a> " ; // output formatting should be ON here since you are echoing output. // now you want output formatting OFF, since you are setting values and saving a page: $p->of(false); // same as setOutputFormatting(false), shorter syntax. $p->subway_station = $pages->get("/subway_station/sub_st_0111/"); $page->save();

I've always thought that the "template engines make it easy for non-programmers" was a myth, as it really just comes down to semantics and what characters you think are easier to type. But the reality is that template engines give you something like a jailed environment, and that increases the comfort level of some people. The prospect of limitation becomes an asset in that context. It means it's going to be harder to break things, and there is going to be a ceiling on what can be learned. I don't ever want to be in a "jailed" environment with a low ceiling, but also kind of understand the appeal to someone that may have never stepped beyond the likes of EE (which has come crossover with our audience). As we work to broaden the audience for ProcessWire, an alternate template engine for those that desire limitation here may help us to capture new audiences. There is also just the word "PHP", which scares off some, regardless of what is real or what we do. ProcessWire is always going to be an PHP API-driven environment at it's core, but I'm not opposed to adding on template engine(s) as an option for those that want them, in the future. It's something that's not at the top of the list on priorities, but it is something we'd like to eventually offer. They are a little more tricky to implement in PW vs. a system that is built purely for tags. The reason for this is that ProcessWire templates are executed directly by PHP rather than by ProcessWire itself. ProcessWire just hands off some API variables to the templates and lets PHP and the template execute natively. It's nice, fast and efficient. (Other systems like EE actually execute PHP code in templates using eval(); which is slow and inefficient… they hope you won't be using much PHP). The way we'd have to implement a template engine in ProcessWire, while still retaining the speed, is with compiled templates. The template using template-tags would have to be compiled to a native PHP template before it could be executed. Lots of these new template engines are designed to work that way anyway, so not a big deal, but just outlining how it would be done.

You could also do this in your homepage template: echo $pages->get('/path/to/page/')->render();

Try this one: $invoice = $this->modules->getModuleID('ProcessInvoice'); $invoicePage = $this->pages->get("template=admin, process=$invoice");

If the content you want to add consists of fields that would be applicable all users, then it's preferable to add them directly to the user template. But if it's content that is only going to be applicable to some users, then may be better to make them child pages.

To save a field you have to use either $page->set("field", $value) or $page->$field = $value. You should also make $page->setOutputFormatting(false) before making the changes to the page. I'm not completely sure that this is what you want, but for the interpretation that I make from your code and assuming that all those pages have a template that contains the "subway_station" field, you should be doing this: // this code will find all the UZAO pages that are descendent of /district/, and add the page "/subway_station/sub_st_0111/" to their "subway_station" field foreach($pages->get("/district/")->find("district_region=UZAO") as $p) { echo "<a href='{$p->url}'>{$p->title}</a> " ; $p->setOutputFormatting(false); // this should be after the echo $p->subway_station = $pages->get("/subway_station/sub_st_0111/"); $p->save(); } I didn't understand where «green» and «orange» were on your code, so interpreted only the code, and left this detail out. Edit: edited the code above by Ryan's suggestion

I really don't see that much difference between {% for item in navigation %} <li><a href="{{ item.url }}">{{ item.title }}</a></li> {% endfor %} and <?php foreach($navigation as $item): ?> <li><a href="<?= $item->url ?>"><?= $item->title ?></a></li> <?php endforeach; ?> If you write it like this, you can forget the }} as much as the ?> Of course the Twig code looks a little more friendly at the first sight, but the advantages of getting used to writting PHP are worth it.

Hi all! I'm currently switching two projects from modx to Processwire - I have to say, Processwire is really awesome!! My sites are both multilang, so I decided to test and maybe use this module. Everything's working fine so far, just noticed two things: 1) I had a Page with the title "persönlich". Processwire generated a name "persoenlich" for this page, before installing this module. The module now generates the name "personlich" (notice the missing e when replaced the Umlaut). Looking into the "toSlug" method, I saw it uses the Santinizer::pageName method to generate the name. This method is using a replacement array from the "inputfieldPageName" module. In the settings of this module, I was able to change "ö=o" to "ö=oe", now i'ts perfect ;-) I was wondering why Processwire itself was not using the replacement array? 2) Caching does not work. There are no Page cache files generated or loaded when the module is installed. I'm still exploring the architecture of Processwire and don't know exactly how the caching is handled. Can anyone tell me if this is possible? Maybe something like this (pseudo code), after finding the page to load: $page = $modules->get('LanguageLocalizedURL')->parseUrl(); if($pages->getCache($page->id)){ //return the output of the cached file }else{ //Check first if caching is enabled in template... $pages->cache($page); include("./{$page->template}.php"); }

Nate, welcome to the forums and thanks for the suggestion. It is something that pops up every now and then and certainly something to think about. I think only thing that makes template languages more newbie friendly is that those fail silently. Forgot ending ?> from <?php and whole site won't load. This single thing might be big obstacle for someone who is just starting. What comes to echoing variables and making simple if statements or foreach loops - I don't think that any template language is much easier than PHP. I have only used EE tags, Smarty and tried Laravel's Blade, so I don't know too much of those.

I second that. Since I'm involved in another open source project which actually uses Smarty, I have been working with Smarty for some years now. I still like it because it saves me from having to do "actual" coding – Process Wire's API does just the same, but offers more flexibility and possibilities.

Not evangelical at all, as I'm not even an experienced programmer. I only learned PHP in the past few months, and I can say it was mostly because of the way PW is thought out. As a Designer I never thought I would be writing some rather advanced PHP so soon, but because PW uses PHP instead of a templating engine, and because it's designed to make it so easy for anyone to achieve basic tasks, you just feel encouraged to go further and further without any constraints. Really, just start building a website with PW without thinking of external tools, you don't even need to install any of the excellent custom modules that are already available, and you will see how easy it is and how powerful it can get

Hi diogo, Thanks for the welcoming! I forgot this topic could possibly lead to a "evangelical" debate :/ With that said, I'm glad PW has taken a stance on this one way or another. I haven't taken the time to dive into the PW templates yet so, yes, Ryan's points may very well be sound and your comment about " it easy for anyone with no PHP skills to learn and use" might also be as well. I will say that Ryan's article touches on Smarty and to be fair that's a template engine of yesterday as far as I'm concerned unless something has changed in Smarty 3 (also debatable I'm sure.)

Hi. and welcome to the forum! There's not really a point on implement something like this in Processwire. PW use of PHP is very well thought to make it easy to anyone with no PHP skills to learn and use. Have a look at this page where Ryan explains this design decision http://processwire.com/api/why-php-syntax/. The context of this quote is a blog ready-to-use PW install. Ryan meant that this profile should be as easy for non-programmers to start using immediately.

Here's something I never finished but what's kind of something similar: AutoUpgrade This module checks if a new version of processwire is available and if it should be it'll show a message with a link. After clicking the link it'll automatically download the new version dezip it and replace the old files. But it's still alpha so you always backup your system before running an upgrade. AutoUpgrade.zip

The page fieldtype refers to the page object itself, and not the id. So this should work: $news = $pages->find("template=news-post, news_section=$page, limit=5");

You guys got me thinking about this form builder and now I can't get my mind off it. I've taken a look at Netcarver's and Zend's form classes, and both look awesome. I'm particularly impressed by Netcarver's system and hope to be putting it to use sometime soon. Focusing on this a lot the last few days also made me realize that a PW formbuilder and the existing Inputfields have a lot of common ground. Enough so that it probably doesn't make sense for a PW formbuilder to venture outside of that. But it does make sense to upgrade PW's Inputfield system to make it more flexible consistent with the needs of a formbuilder. It's easier to maintain and support if there is one system rather than two. It wouldn't replace a system like Netcarver's or Zend's, but would provide a good middle ground for the less complex form needs. As a first step, I figured I'd see how well Inputfields would adapt for the sort of portability a formbuilder would need. The goal was to be able to take an array or JSON string, and have it render as a form using PW Inputfields, as they are now. This is something I'd not tried before, but the first step we'd need in order to easily store a form schema for a form builder. A small 20-line recursive function takes that array and dynamically creates a form composed entirely of PW Inputfields. All that's left to do is call $form->render(); I built a small test form and had success with it. Yesterday a friend needed help on a larger form, so decided to put the strategy to work there too. Here is the result. Not a pretty form by any stretch, but I was happy with how easily it all went together, and now getting me enthusiastic about going further with full blown form builder. As an example, here's the PHP array schema for my test form: $formArray = array( 'personal_info' => array( 'type' => 'Fieldset', 'label' => 'Personal Information', 'children' => array( 'first_name' => array( 'type' => 'Text', 'label' => "First Name", 'columnWidth' => 50, 'required' => true, ), 'last_name' => array( 'type' => 'Text', 'label' => "Last Name", 'columnWidth' => 50, 'required' => true ), 'email' => array( 'type' => 'Email', 'label' => "Your Email", 'columnWidth' => 50, 'required' => true ), 'phone' => array( 'type' => 'Text', 'label' => "Your Phone", 'columnWidth' => 50, 'required' => true ) ) ), 'customer_feedback' => array( 'type' => 'Fieldset', 'label' => 'Share Your Feedback', 'children' => array( 'store_location' => array( 'type' => 'Select', 'label' => 'What store location did you visit?', 'options' => array( 'ATL' => 'Atlanta, GA', 'CHI' => 'Chicago, IL', 'NYC' => 'New York, NY', 'SFO' => 'San Francisco, CA' ) ), 'would_visit_again' => array( 'type' => 'Radios', 'label' => 'Would you visit that location again?', 'options' => array( 'Y' => 'Yes I would', 'N' => 'No I would not' ) ), 'comments' => array( 'type' => 'Textarea', 'label' => 'Comments or Questions?', 'description' => "We'll respond right away!", 'rows' => 5 ) ) ), 'submit' => array( 'type' => 'Submit', 'value' => 'Submit Your Feedback!' ) ); That schema can be converted to/from JSON just by calling json_encode/json_decode on it, and gives us exactly the portability I'd want out of it. Given that this can be translated to a full form of Inputfields with a tiny function (arrayToForm), I figured that's a great first step towards an interactive formbuilder. Here's what the template code looks like: $form = arrayToForm($formArray); if($form->isSubmitted()) { $body = "<html><body>" . $form->renderValues() . "</body></html>"; $headers = "Content-type: text/html; charset=utf-8\nFrom: " . $form->get('email')->value; mail('me@domain.com', 'Form Submission', $body, $headers); echo "<h2>Thanks, your form was submitted!</h2>"; } else if(count($form->getErrors()) { echo "<h2>Fix the fields in red and try again.</h2>"; echo $form->render(); } else { echo $form->render(); } That's how I'm doing it now, but stuff like the above would obviously be integrated into a FormProcessor class so that you only need to call 1 function to display/process a form, and you could store and browse the results in a DB rather than just emailing it. Inputfields need to be upgraded so that all the structural markup is customizable. I'd probably want the default render output to be structured around fieldsets rather than lists, and be something that one wouldn't necessarily need any prerequisite CSS/JS except for progressive enhancement. Other upgrades would be more validation options for the basic Inputfields. The nice thing is that any upgrades would benefit all of PW, not just the formbuilder. The next test/proof-of-concept will be to make the creation of that $formArray interactive from the admin (with a Process module).