ryan

To the outside world (those accessing your website) everything is a page, accessed by a URL. ProcessWire is just trying to maintain consistency between the outside and the inside. All pages have a consistent set of properties and methods, but a Page derives its actual "type" from its template. So a Wine, a Review and an Event are all different types, while still sharing the common heritage of being a Page. A Page is basically a URL addressable container for data that has a parent and optionally children. But beyond that, everything about the Page's type comes from the template. Pages in ProcessWire are very similar in concept to nodes in Drupal (from what I understand). But nodes in Drupal are abstracted away from URLs whereas pages in ProcessWire are always connected to a URL. Even if that URL is tied to something you never intend to use as a renderable page on your site (and might not even have a template file), the URL is still a consistent, known way for you to refer to a page from the API, or wherever. A Page's URL is always reflective of its parents, meaning you know where a page physically lives in the tree based on it's URL. ProcessWire embraces the addressing system of the web, both on the front-end and back-end.

I was missing a few of the reserved words in the field creation process, honeypot being one of them. But hopefully got them all covered now. If you use a reserved word, it'll still let you, but it'll just append an underscore to the end of it so that there's no confusion.

It's easy enough for me to search/replace, but I'm reluctant to remove it entirely (at least for awhile) as I don't like to risk breaking anyone else's code. But indicating that its deprecated is a good idea. Very nice, I like it. And actually think it is still useful even outside of an IDE. But I'm confused by the last line: "class Post extends Page" -- is this what you mean by fake-out the IDE, or does the Post class have a purpose beyond it?

Do you mean like put it in a /* comment */ or something?

WillyC's example just modifies the output of the $page->path() function (which is also used by $page->url). His intention there is to change what URL gets sent out when you call $page->url. It's really no different than making your own function and using it instead, except by using a hook like this, you can continue to use ProcessWire's API and get the result out of it that you want. Ultimately it's just a syntax convenience. While his hook example handles the URLs that get output in your markup, you still have to have something to look for and capture those URLs. Perhaps you could use mod rewrite, but typically you would use the "URL segments" feature that you see on the "URLs" tab when editing any template in PW admin. Lets use a simple example of your homepage template (home) with filename home.php. And lets say you want to make it so that when someone access domain.com/contact/ (a URL that doesn't currently exist) you want it to display the page that lives at domain.com/about/contact/. So you are setting up your site to respond to the shorter URL of /contact/ (rather than /about/contact/, where the page actually lives). Go to Setup > Templates > home > URLs. Click the checkbox to "allow URL segments", and save. Now edit your /site/templates/home.php file, and do something like this at the top: if($input->urlSegment1 == 'contact') { // render the /about/contact/ page echo $pages->get('/about/contact/')->render(); return; } else if($input->urlSegment1) { // throw a 404 throw new Wire404Exception(); } // otherwise continue normally and display your homepage.

Very cool Pete (and Netcarver)! Thanks for posting this.

If the page name were different, it would technically be a different page. We will find a way to do some kind of aliasing down the road, but it would involve some changes to the way that ProcessWire addresses and differentiates between pages. But it's doable. I'm just waiting for the simple solution to pop into my head and it hasn't yet.

Andrew, I'll be glad to answer any questions you have. I see you already posted some in another thread, so will respond later tonight or tomorrow AM.

Of course! I'm always glad anytime to get updates like this. In this case, I wonder if it really should get down to the database level. For instance, supporting the option of a 'unique' index down to the table schema in text fields, which could then be inherited by the email field. For something beyond an individual site, uniqueness probably needs to be enforced down to the database level for any field used as a login identity. That's one reason why 'name' is good for this, because that uniqueness is already enforced. But the same could be done with email. I'm going to look at what changes might be needed at the lower level of text fieldtypes.

Alan that's good to hear you've had a good experience with MT. My only experience with them is from the (gs) plan, via multiple clients, and it's been the most problematic hosting situation I've dealt with, though it's not all bad all the time. But it's good to hear their plans above that are in a different class. I'm good with this too. Though also think that there isn't anything specific about ProcessWire that makes it require hosting any different from say WordPress, Modx or Drupal. So ultimately it would just be a list of services that members here have had a good experience with. Longer term I think we should have a listing of this sort, but shorter term we'll probably want to keep it to the forum until some other projects are out of the way.

It's meant to be paginated within date ranges using the dateFrom() and dateTo() methods that you can call. Here's an example that uses the Google Calendar Loader and paginates by month/year: http://washingtonwaldorf.org/calendar/ $month = $input->get->month ? (int) $input->get->month : date('n'); $year = $input->get->year ? (int) $input->get->year : date('Y'); $dateFrom = strtotime("$year-$month-01 00:00"); $dateTo = strtotime("+1 month", $dateFrom)-1; $cal = $modules->get('MarkupLoadGCal'); $cal->dateFrom($dateFrom)->dateTo($dateTo); $cal->load('your-gcal-email@domain.com'); echo "<h1>" . date('F Y', $dateFrom) . "</h1>"; // i.e. September 2012 foreach($cal as $item) { // output your items }

WillyC's example above would be the way to do it. The core is specifically built to support that hook exactly the way that he used it, so this is not a hack, this is part of the API (combined with using urlSegments). But maybe somebody will come up with a module that enables it to be automated from the admin at some point. I'm of the opinion that you will see the greatest benefits by using a structure that is consistent with the navigation. So if one is having to redefine URLs outside of the structure, that's a good reason to reconsider whether the chosen structure is ideal. You've got an infinitely nest-able tree (in a manner of speaking). Every branch is its own tree if you want it to be. It's just a question of how you perceive and use it. Regarding labels, take a look at mindplay.dk's Template Badges module, which might have some of what you are talking about.

Sorry guys looks like I neglected to update the tag. So it was 2.2.7, even though the filename didn't indicate it. However, I updated the tag today so it should now say 2.2.8.

Thanks for the pull request John. I will bring this in soon.

Here's one way that you could do that from your module's getModuleConfigInputfields function: public static function getModuleConfigInputfields(array $data) { $inputfields = new InputfieldWrapper(); $name = 'my_page_select'; if(!isset($data[$name])) $data[$name] = 0; $f = wire('modules')->get('InputfieldPageListSelect'); $f->attr('name', $name); $f->attr('value', $data[$name]); $inputfields->add($f); return $inputfields; }

This looks like it should work to me. Just make sure you are executing all of this before you are starting output. If you find it's still not working, examine what values are getting thrown around in there. For instance, if($session->language) { echo "<p>Language is: $session->language</p>"; } Likewise, make sure that the names like 'it' are consistent with the actual page name of the language.

When you use multi-language fields, they all live at the same URL and it's up to the $user->language setting to determine what language gets shown at that URL. Visit this page for more info about the benefits and drawbacks as well as different strategies that you can take: http://processwire.com/api/multi-language-support/multi-language-fields/ I also recommend checking out McMorry & Soma's Language Localized URL module as another possible solution.

I think that your code looks fine, but I'm not sure that I understand the question?

Thanks for this info. It's hard to tell, still not sure where it was picking up the reference to the template from. Please let me know if you ever see it again.

Great suggestions, thank you for this. You are right, those hidden/invisible properties are not well covered at present. Largely because this was one aspect of phpdoc I wasn't aware of until recently. @Interrobang actually added the appropriate property/method tags in /wire/core/Page.php a couple months ago, and I expanded upon them. Do you think this is a good model to carry through in other core files? This is a good point as well. I want to mention though that "fuel" is more of a old and now redundant thing (for backwards compatibility with the original PW 2.0). It's now preferable to use the wire('...') function to access API variables (rather than $this->fuel()). Technically they achieve the exact same thing. But I like wire() because it works anywhere (template files, bootstrapped shell scripts, modules, core) ... code examples are portable no matter where they come from or are going. Whereas $this->fuel only translates to within 'Wire' derived classes. But I'm not planning on deprecating $this->fuel() either. I'm just avoiding it in my own code and examples (only new stuff) so as not to confuse people studying code. But perhaps there is some way I can signal that $this->fuel() is an alias of wire() with phpdoc, to better clarify it for people in an IDE. I think PSR-0 will take care of this one and I'm anxious to move forward with that but need to resolve some questions about how it will affect language translation.

Thanks Martijn, found it -- I'm adding both you and Raymond to it.

Raymond, I have posted an update that fixes this issue in the Form Builder Support forum. I'm not sure if you have access to that board because I don't see your name in the list. Was your order placed under a different name? Let me know and I can update or add to it in the fulfillment system which should correct your access, but just need to know which order to edit.

Thanks Raymond, I was able to reproduce that and am working on a fix now. Should have it within the hour.

I'm not really a fan of robots.txt for keeping bots out of URLs I'd like to keep confidential. Why? Because if someone wants to know where they can find the "interesting" URLs, they just have to take a look at your robots.txt. The meta noindex,nofollow at least doesn't broadcast the location of the page. So far my experience is that search engines that honor robots.txt also honor the noindex,nofollow meta tag.

Glad you got it solved. But I'm confused, how is a Page field linking to a template?