ryan

Varvanin, I'm not sure I understand all points, but if you switch to the default admin theme do you experience the same issue? I'm just wondering if it's something we need to look at in the Futura Remixed admin theme or somewhere else.

If you've got URL segments turned on for the template used by page /cooking/29/ then all the URLs you mentioned should load the page /cooking/29/ and whether you choose to do something with the URL segment is up to you. In your case, I think that the viewable() check isn't working because you are checking $page->viewable(); rather than $redirect->viewable() ? Your $page->viewable(); call will never come into play because $page is the page you are currently on, and PW will never serve a request for a $page that isn't viewable. So I'm thinking you could fix it just by changing $page to $redirect? Here's another way to do it: if($page->id == 1232) { $id = (int) $input->urlSegment1; $redirect = $id ? $pages->find("id=$id")->first() : null; if($redirect) $session->redirect($redirect->url); } The viewable() check isn't necessary above since PW's find() function doesn't return pages the user can't view.

This has been my impression as well. That's my understanding as well. I think it's rare nowadays to actually store any CC info on a web server (I don't know of any merchant account that allows that). But usually interfacing with any merchant gateway requires your PHP code coming in contact with the CC info at some point. Like preparing it in an array that gets POSTed to the gateway. The data is in memory for the request (1/100 of a second), and never touches a disk or anything like that. And that's the only thing that happens. Yet, it means we are subject to the whole insanity of everything PCI. Such a simple thing, but it sounds like this solves the issue I mentioned above. Though I'm a little surprised, as it doesn't seem like the data would be much more secure. In either case, the biggest concern is a hacker silently logging the posted CC data before it gets sent to the gateway. It seems like that could still be achieved with the direct post, even with just a little JS. Given that, I would think the only way to truly clean yourself of responsibility for the CC data would be to let all financial transaction forms be delivered by and processed by the merchant/gateway.

Any idea what software looks interesting for this? I've also been meaning to check if there is any Wiki-type software that already integrates with IP.Board. I kind of doubt it, but just a 'nice to have'. What do you guys think about hostname? Here are a few ideas: processwire.org (already setup) processwire.net (already setup) manual.processwire.com man.processwire.com (unix style) readme.processwire.com rtfm.processwire.com wiki.processwire.com

What you are referring to sounds like a type of page reference, and I think you could use the Page reference fieldtype to achieve this pretty easily. Let me know if I can provide additional detail. But if you've got an instance where repeating the same image(s) is expected, then my preference is usually to code the template to pull them from a common page. For instance, in the default site profile, all the site's photos are on the homepage, and the rest of the site's pages pull them from there (at least for pages that don't already have photos uploaded to them). This is a technique I use on almost every site I build. Every page has an dedicated field for interface images. If no images are assigned to it, then it pulls from a common page, or the closest populated parent.

Readability also seems very lightweight, but I don't know anything about the company behind it. I usually have a preference for one-man operation software and bet I would like Instapaper. For now Readability is doing everything I need, and quite well, but I will definitely be keeping an eye on Instapaper.

What are your thoughts about PCI compliance and is that even an issue in this case? I'm just learning more about it here and have been wondering how that affects the gateway approach for something non-PayPal. I'm having to move away from self hosted Drupal UberCart because PCI compliance is a darn near impossible to achieve in a self-run/hosted environment as far as I can tell. PCI compliance is now a requirement (at least in the US). Those that don't meet it have to pay much higher fees, and pretty soon won't be allowed to perform transactions at all (I think we're in some kind of grace period now). The self questionnaire is thousands of unintelligible questions, even for someone that knows their way around web servers. Then they repeatedly slam your site TrustKeeper bots and always find thousands of things that don't really matter (like not running PHP 5.4, heh), but allow them to call you non-PCI compliant. So there is a real incentive to host online stores with a provider that handles the PCI compliance or at least has some deal going with the PCI inspector. I think it can also be accomplished by delegating all your customer forms and transactions to a merchant/gateway-hosted page, even if the actual cart is self hosted. But I don't know much about it yet, just learning and trying to move a client's store to a PCI compliant environment, and finding it kind of frustrating.

I'm not sure the software matters so much at this point, so long as it lets us get going quickly and covers the short-term collaborative needs. The focus in the beginning should be on the editors and their short term needs. Getting the content going is a lot harder than getting the software. Content is portable. Once the content is in a good place, then we're in a good spot to put it wherever it would best serve the users (while still keeping it collaborative). PW was not designed as a Wiki, so it'll take some work to make it behave like one. That means somebody coding it before we can populate any content. I think the content has to come before the software here. (Though if the editors actually prefer to use PW as-is rather than a real Wiki, then we'll do that). If it were just me, I would probably use PW since I don't know my way around Wikis. But PW is a multi-purpose tool, and a Wiki is a single-purpose tool that designed for the exact purpose we are looking for. Assuming a Wiki is a better environment for the editors, my opinion is that it's a good way to get things going short term. Moving it into a PW-powered Wiki longer term would be ideal. That way we could maximize the flexibility of the content… even providing JSON doc feeds to live PW installs like mentioned above. If we've accomplished what we want to with the content, then converting and delivering it with PW will be the easy and fun part.

Glad that your friend was able to solve it with the hosting change. Just thinking about WP again, it would probably be very hard for them to take away the table prefixes now, since they've already been there for years. Sounds like a potential support nightmare. Still, I have to believe that if they were starting from scratch today, they might avoid them.

Almost anything involving output of markup is not an ideal candidate for a core module (/wire/modules/), but always a great candidate for add-on modules (/site/modules/). The intention is that the PW core stays as markup independent as possible.

Good call -- that makes sense to me. Fewer unintended side effects.

Here's another way you could do it, by using an SQL query. Also a good example of why I much prefer using PW selectors. Still, this should accomplish the desired result without any major caveats. $template_ids = str_replace('|', ',', $templates->find("name^=post_")); $parent = $pages->get("/beitraege/"); $sql = <<< _SQL SELECT pages.id FROM pages LEFT JOIN field_post_confirmed ON field_post_confirmed.data=1 AND field_post_confirmed.pages_id=pages.id LEFT JOIN field_user ON field_user.data=$user AND field_user.pages_id=pages.id WHERE pages.parent_id=$parent AND pages.templates_id IN($template_ids) AND (field_post_confirmed.data=1 OR field_user.data=$user) ORDER BY pages.created DESC _SQL; $result = $db->query($sql); $ids = array(); while(list($id) = $result->fetch_row()) $ids[] = $id; $items = $pages->find("id=" . implode('|', $ids) . ", sort=-created, limit=20");

What's the advantage of Instapaper over Readability? I'd heard good things about both, but one was free in the app store (Readability) and the other cost $5 (Instapaper) so I went with the free one. Still, I don't mind paying the $5 if there's a nice advantage to Instapaper.

I think there are multiple ways to examine this, but I've always used the LiveHttpHeaders add-on in Firefox. I think you can also do it with Firebug and Chrome's inspector. If you want to send me the URL here or by PM, I'll be glad to check it for you. By Google being shy, I mean that a portion of your search traffic may stop temporarily. Or it may not. If I've run a site for a year or two, the 301 redirects seem to work right away with no affect on traffic. But I've done them with a couple of sites running at the same URL for 6+ years, and have found the site disappear from the search results, temporarily. It makes me wonder if a change to something that's been one way for a long time sends it to some queue for somebody to look at manually to make sure there's no monkey business going on... who knows. All the 301 redirect scenarios I've been involved with have been at the same domain. Changing a page's path from an old URL to a new one. However, I've not completely changed domains like you are trying to do. There is value to a domain name from its age and combined quantity of incoming links. It's a lot easier to make a site perform on an old/existing domain than it is on a new domain. So I guess what I'm saying is that you should probably expect there to be some loss of search traffic as a result of completely changing the domain. But I can't say for sure as I've not had experience with this myself to witness the effects.

I think that may be the problem here, as title is a required field. How do you have templates without a title? PW requires a title from all templates, except in specific cases. The ProcessPageAdd module assumes your template has a title field. When it finds there is none, that's where the exception is getting thrown (I think). I'm thinking you can fix this just by adding a title field to any of your templates that lack it, but still wondering how the templates were created without one. (Perhaps something about PW 2.0 that I don't remember).

I suggest not extending the User class, and instead plugin to it with a module class UserExtended extends WireData implements Module { public static function getModuleInfo() { /* return your array here */ } public function init() { $this->addHook('User::sendThankYou', $this, 'sendThankYou'); public function sendThankYou($event) { /* do something */ } } The above would add a sendThankYou method to all User instances. Your sendThankYou method can gain access to the $user the method was called on like this: $user = $event->object; Your sendThankYou method can also have one or more arguments if you want it to: $arg = $event->arguments[0]; If you want your sendThankYou method to return a value, do it like this: $event->return = 'value you want to return'; Looks like Antti beat me to it.

This is a fairly complex pagination scenario. I can see why you want to get it all in 1 find() operation here, and if the option I mentioned works, I would probably use it. But if not, you'll need to adjust your setup to perform pagination and sorting at the $pages->find() level, rather than after. Your $posts->find() is not setting pagination details to the PageArray it returns to you because all those pages are already in memory, and pagination is assumed to be for stuff that is not in memory. Writing in the browser here, but try changing your example to this: $template = $templates->find("name^=post_"); $parent = $pages->get("/beitraege/"); $posts = $parent->children("template=$template, post_confirmed=1, sort=-created, limit=10"); if(!$user->isGuest()) { $posts->import($parent->find("template=$template, user=$user, sort=-created, limit=10")); $posts->sort("-created"); // sorts with the previous results } A caveat is that the items-per-page is going to be somewhere between 10 and 20 rather than always 20, at least if the result set is not large. The other caveat is that it's not going to show more than 10 of the given type in each pagination. These may or may not be issues in your case, but just wanted to mention it. There are ways around it, but it'll take more code. Note the way I'm using the $template var requires the latest PW (or at least one from the last month). You no longer have to do something like implode('|, ...) in recent versions.

Kind of a hack, but give this one a try: $pages->find("offer_global|offer_from=1|22|33|44|55"); It should work with pagination. At least, I can see I've got code to account for pagination in PageArray::import(). However, I am not certain I've ever actually had to use it. Let me know what kind of result you are getting?

Nice job Diogo! I suggest adding this line to the top of your format() function, just so that it doesn't have to perform the preg_match (a heavy function) when it doesn't need to: // check if we even need to perform a preg_match and exit if not if(strpos($str, '{') === false) return; One idea for a future version is that if you just type the field name without the index, i.e. {images} it could output them all. Another idea is to add a class name to the <img> tag like "ImageTags" so that one could style them independently of other images.

When you try to add that new page, do you have the choice of selecting which template? If not, try adjusting your 'family' setting on the parent page's template and temporarily adjust it to not have a defined child template here. Just in case some data is amiss, also edit the template (Setup > Templates > your new page template) and save it. Do the same for the template used by the parent of the page you are trying to add. Lastly, do the same for the 'title' field (Setup > Fields > title). The purpose of this is to refresh the config data for the relevant templates/fields there, just in case there is some leftover PW 2.0 setting, re-saving those templates/fields should clear it out.

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.

A lot of shared hosts will have Apache/PHP running as you, which is good. When you installed ProcessWire on your server, if it never asked you to make any directories writable, then Apache/PHP is likely running as you. You can also tell by running a PHP script that just contains this: <?php echo exec('whoami'); If you run that script and it says the name of your account, then there's likely not any reason for anyone to have access to the site's files except you. This may or may not be necessary, depending on what jailing measures your shared host is already handling. But better to be safe than sorry. Don't do any of this if Apache/PHP is not running as you. To start, you can recursively remove write access to your /site/assets dir: chmod -R og-w site/assets Likewise, remove read access from your /site/config.php: chmod og-rw site/config.php You'll also want to tell PW what permissions to use when creating new files or directories. So edit your /site/config.php and locate the lines containing the chmodFile and chmodDir settings. Update them to this: // 0755 = owner r/w/x, group+other can r/x $config->chmodDir = "0755"; // 0644 = owner can r/w, group+other can only read $config->chmodFile = "0644";

Does anyone have experience setting up/running a wiki like this? Drop me a note. I can setup an account here to host it.

Uh oh, I'm using readability and was really enjoying it up until I read this. :- Okay I'm still enjoying it. But maybe I'll click 'read later' on readability's homepage or something, just in case.

There's a lot in PW (like the Template > Family tab) that is really useful when you get things going, but not really necessary when getting started. It's one of those things that you tend to find once the need comes up. I'd used ProcessWire for years without a lot of this stuff. So it's always a bit of a battle balancing simplicity vs. power. I think it will be good for these tutorials to outline what's essential [to get things started] and what's not. One of the problems I had with EE years ago is that I would get lost in it's endless configuration screens, and not really know what I needed and what I didn't. I'm writing this here so I won't forget when it comes time to expand upon the tutorials.