ryan

Here you go (I just added this page now): http://processwire.com/api/fieldtypes/images/

Another way to accomplish it is to have the template calling $page->render(); stuff the $originalPage into $page. In this case, /site/templates/main.inc: <div class='widgets'><?php // render widgets $widgets = $page->widgets; if(!$widgets || !count($widgets)) $widgets = $homepage->widgets; foreach($widgets as $widget) { $widget->originalPage = $page; // ADD THIS LINE echo "<div class='widget'>" . $widget->render() . "</div>"; } ?></div> Then in widget-recent-posts.php: $posts = $pages->find("template=post, id!=$page->originalPage, sort=-date, start=0, limit=$limit");

How do you duplicate that? I tried to duplicate but couldn't. Here's the test I ran in my /site/templates/home.php: <?php include("./test.inc"); Here is /site/templates/test.inc: <?php throw new Wire404Exception(); Result was the 404 page.

I think this makes sense. Only issue is the template needs to be aware of that context, rather than just having a $var present like others are. But I think it's probably the right balance.

I understand what you are saying. But the reasons are about consistency, readability, DRY and flexibility. For consistency, we want to have similar/identical hook naming conventions across Pages, Templates and Fields, and was just looking for the right opportunity. For readability, we want people to hook into things that that make sense purely by name. These hooks don't really cost us anything in terms of resources, but reduce potential ambiguity for the developer. I generally prefer more methods to more arguments, if that is an indicator. For DRY, I don't want everyone's save() hook to have to check return values or other things before deciding if it can proceed. I don't want people to have to devise ways of determine if a page was just added or already existed. Basically, I want to offer very convenient "sure things" in terms of hooks, where people don't have to think about internal conditions, and don't have to write code to accommodate them. Lastly, is flexibility for those of us that get deep in module development. I don't want 99% of people to have to think about internal conditions (per DRY above). But at the same time, I want to give the other 1% the flexibility to do so when their need calls for it. For instance a before(save) hook might be more appropriate than a saveReady() hook if I wanted to modify the conditions that will be present. Likewise, an after(save) hook might be more appropriate than a saved() hook if I wanted the ability to take action when something couldn't be saved.

Well I'm glad they do it. But it's not like we don't have a choice. We can put a robots.txt in place to opt-out when/if we want to. Someone searching for ProcessWire, getting something other than ProcessWire, would be considered a poor quality search result. The optimizations that Google makes are intended to increase the quality of search results, not reduce them. However, I recognize that temporary anomalies and unintended consequences can happen, and people occasionally get slapped down when they shouldn't. But that doesn't change the big picture. Google does what they do in order to increase the quality of their search results. If the quality goes down, the audience goes elsewhere, and they know that. Just because you or someone you know got slapped down when they shouldn't have doesn't change the big picture or long term. We should all be working towards increasing quality. Maybe what you are suggesting (changing the terms) does work to increase quality, but by our definition. Looking bigger picture, It does seem grey hat, and I'm guessing Google would frown upon it (though who knows, I could be wrong). But if we proceeded with that understanding, that we are doing this to work around Google's algorithm, then we'd be engaged in a risky behavior. If a future Google algorithm detects our strategy, the sites linking to us would themselves get legitimately slapped down for participating in the risky behavior. Another thing to consider is that your site can't be penalized for who links to you, or in what quantity. Only those linking to you, and the value of the links [to you] can be penalized. If a thousand sites out there have a link in the footer that says "Powered by ProcessWire open source CMS", does that mean that ProcessWire deserves a high placement for the term "open source CMS"? No. It seems reasonable to me that a large quantity of links like this (whether identical or randomized) should not carry the same value of more organically generated links. If I start randomizing the anchor text of those links, then I'm trying to make that link look like something it's not in order to boost the value of it. When we ask for attribution links, Google is not the audience. Google can do what they want. If they give us a boost, great. But we want attribution links so that people can show pride in what they run and share it with their audience. Old fashioned marketing. Regardless of whether Google considers the value of those links reduced, due to quantity and similarity, we benefit. There is no situation under which the presence of those links could hurt us more than if they weren't there in the first place. Maybe this is totally okay. But it seems like a grey area to me. If it has the blessing of someone like Matt Cutts, then I'd be supportive of it. Otherwise, I'd worry about involving users of the module in a potentially risky behavior. I may be able to write a module to outsmart Google in the short term, but not long term. While one may not equal the other, they also aren't isolated from each other. Yes. But note that there is no "bottom-line" (this is not a for-profit venture), and I do not see Google as our primary source of future growth. I see primarily word-of-mouth, but also the resulting links and social networks as being our source of growth. But even for my for-profit clients, I advise them to do the same and focus on the site and audience (and accessibility to them) rather than Google or some other search engine. Of course we care about Google, and pay attention to the webmaster guidelines, especially search accessibility and semantics. But I don't get involved in sites or business models that are built around living or dying based on organic search placement. That's a risky model regardless of what you do. Damage only relative to the potential value of those links if all links were equal. And I don't believe attribution links should carry the same value as organic links. Maybe they don't deserve more value than a rel="nofollow", I really don't know. Thanks. I also appreciate your interest in helping our search performance. I'm not trying to challenge anything you say, just enjoy participating in conversations about this stuff, and hope you do too. While I'm very grey area about what you are proposing (and I may be wrong), I do think we have plenty of room for improvement from the SEO side, and discussion like this is a great launching point.

I don't think the delay would be coming from ProcessWire. Most likely client side, styles or javascript. Try removing these and working forwards from there till isolating what it is. Sometimes browsers get in an odd state too, so the first thing to try might just be quitting and reopening your browser. But if that's not it, definitely remove CSS and JS from the equation, and then start adding them back till you isolate it.

You can make any page a settings page. Some of us use the homepage for convenience (since it is the root owner of the pages below it). But you could make your own custom 'settings' template and contain them all there instead if you preferred. I'd also suggest deciding which settings need to be dynamic and which don't. Something like 'site title' may not need to be dynamic. I prefer to store this stuff in $config or with PHP define('key', 'value') calls, either of which you could put in /site/config.php.

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.

Thanks Maniqui, this is great info! You are officially our Git advisor, should you choose to accept the job. Actually those 3 lines aren't supposed to be in dev OR master. It appears to be just a duplicate if() statement to the one right below it. It doesn't appear to be a problem, but of course it's unnecessary redundant code. So I will have to remove this from master. I actually have no idea why or how there are duplicate lines there. But thank you for finding it. Great links too, bookmarked and look forward to reading.

Very nice! But it took a long time to load here. Not sure if that's because of the connection that IP is going through, or if it's the result of loading and rendering data for 533 pages (?) in one request. But if you are loading that many pages in one request, it's good to keep in mind that you can only scale so far using that method. Eventually, you'll fill up memory if that table keeps growing. If it's not going to keep growing, then you may want to at least cache it with MarkupCache. Usually if I'm rendering something that's reusable and has 50+ pages loading as a result, I use MarkupCache to cache the output.

Double check that you don't need a more specific URL for this. I'm guessing you might need it to be "/sendEmail.php" instead? I would guess those values have to be escaped if you bundle them in a string like that. To make it simpler, I would suggest changing this to: data: { name: name, email: email, subject: subject, comments: comments }

For front-end use, I would just follow any instructions that come with CKEditor itself. ProcessWire really tries to give you an environment on the front-end where you can implement anything without having to worry about the system itself. The only reason I would use InputfieldCKEditor on the front-end is if you are already using other Inputfields and including their scripts, css, etc. Otherwise, better to just use CKEditor and implement the same way they do on their website.

InputfieldEmail does this validation for you. PHP's built-in mail() function makes this pretty simple: $body = "This is the message body"; $subject = "Web Contact"; $emailFrom = $form->get('email')->value; $emailTo = 'you@domain.com'; mail($emailTo, $subject, $body, "From: $emailFrom");

Thanks Radek, will do! This is on my to-do list.

Matthew is already working on a site directory for us, so he may have some thoughts too (?). I think if someone wants to put time towards making ProcessWire look good, that's always a good thing. One thing is for sure, we definitely need more showcasing of sites built with ProcessWire. If there is more than one showcase, I don't see that as a problem at all. Just more opportunity to reach a broader audience.

I would think that whatever you pass in would overwrite any defaults already present? That way, if you want to override something, you can. If you don't want to, then you leave it out. I guess the question is whether there is any value to overwriting the variables that are already populated in the template. The only one that seems like it could have value would be $page. Until I think about it a little more and… what would be the point of calling $page->render(...) if you were going to overwrite the $page in it. It would be more logical to just find the $page you want and call its render() method instead. Maybe throwing an Exception does make sense. Though need to think about it a little more.

I'm not clear about the question. What is the source of the URL segments you'd want to use?

This makes the events consistent with how they are in the Pages class, which I think is a good thing. They are more reliable to standardize upon because, for example, saved() is called only after an item has been saved without error, and saveReady() is called only after its been confirmed the item will definitely be saved (no conditions to prevent). Without these, your hooked functions have to consider these things themselves (at least, if you want them to be thorough). Granted, there are more potential conditions within Pages than here, but these are hooks that probably belong here either way. I was just looking for a good reason to add them. While I think you may be able to do what you need without them, feel free to use them if helpful, because they belong here.

This sounds awesome mindplay.dk! That's a valid concern, since modules or other API usages that are adding/manipulating templates/fields would not be triggered from the Process ones. Though if you only wanted to capture changes made interactively, that would be the place to do it. Attached are replacements for /wire/core/SaveableItems.php and /wire/core/Fields.php. They contain additional hooks, which I think may be more what you are looking for. Let me know if these work out, and I'll commit them to the core. I'm a little short on time this afternoon, so haven't had a chance to try them myself, though the additions are very minor and simple so can't think of any reason why they wouldn't work. mindplay.zip I added a few hooks to SaveableItems.php which is used by both Fields and Templates. You can hook these either by wire('fields')->addHook('methodToHook', $this, 'yourMethod') or $this->addHook('Fields::methodToHook', $this, 'yourMethod'). To operate on templates, you would replace 'fields' with 'templates'. Here are the hooks, and they work exactly like their Pages class counterparts: public function ___saveReady(Saveable $item); public function ___deleteReady(Saveable $item); public function ___saved(Saveable $item); public function ___added(Saveable $item); public function ___deleted(Saveable $item); These two were also added to the Fields class (in the attached zip): public function ___changedType(Saveable $item, Fieldtype $fromType, Fieldtype $toType); public function ___changeTypeReady(Saveable $item, Fieldtype $fromType, Fieldtype $toType); For all of those above, it doesn't matter if you hook before or after. For the existing hooks that were already there, it does matter whether you hook before or after. Though not sure if you necessarily need any of these: protected function ___changeFieldtype(Field $field); // Fields class only public function ___saveFieldgroupContext(Field $field, Fieldgroup $fieldgroup); // Fields class only public function ___clone(Saveable $item); public function ___delete(Saveable $item); public function ___save(Saveable $item); protected function ___load(WireArray $items, $selectors = null); Let me know if there is anything else I can add/adjust to facilitiate what you are working on.

I agree with Soma, it sounds very doable to me. Let us know if you run into any specific problems as you go.

It's in kind of small text on the MySQL config screen:

I'm not clear about what the pages are. Can you post a screenshot from your admin so we can see?

It's in the dev branch now

Thanks Soma, that one is fixed now.