ryan

Looking good Adam! I replied in Diogo's thread something that may be more applicable here: That link mentions referencing other pages with a tag. So one way to make tags extendable is by tying them to a page and rendering the output of the page. I think there are cool possibilities there, but don't think it's enough... If we're going to have an extendable tags system, it probably needs to be a module that other modules can add hook functions to, and they become tags. It would utilize the existing hook system. That way another module could add a {subpages} tag by doing something like this: public function init() { $tagscript = wire('modules')->get('Tagscript'); $tagscript->addHook('tag_subpages', $this, 'subpages'); } public function subpages($event) { $page = $event->arguments[0]; $children = $page->children(); $out = "<ul class='subpages'>"; foreach($children as $child) $out .= "<li><a href='{$child->url}'>{$child->title}</a></li>"; $out .= "</ul>"; $event->return = $out; } As for format of tags, I think it may make sense to use the existing selector format already used elsewhere in PW. There is already a built-in parser for it, it would be consistent, and it could pass the params in the selector directly to the tag event in the $event->data array. So an example of a tag would be this: {subpages: limit=10, include=all} ...and the tag_subpages function would retrieve them like this: $limit = 0; if(isset($event->data['limit'])) $limit = (int) $event->data['limit']; Further along, we'd also want to be able to do this for markup independence: {subpages: limit=10, include=all} <li><a href='{url}'>{title}</a></li> {/subpages} I have a parser that does that that I was working on awhile ago. Might be time to resurface it.

Nice work Oliver! I like the approach you've taken with delegating to PW's image sizer with magic methods. PW's ImageSizer class actually isn't hookable, but I could certainly make it that way if you would prefer to add methods to PW's ImageSizer. However, I'm not sure that it matters, as the approach you have here is probably better. In your module settings, I would suggest setting both singular and autoload to false. The only other thing I can think of is that it would be nice to have constants or functions to relate to the available orientations. So someone could do this: $sizer->fixOrientation(ImageSizerExtended::flipHorizontal); Or better yet: $sizer->flipHorizontal();

Here's some PW (Dictator) tag stuff from the past. Stillmovingdesign mentioned CSS classes, so thought maybe some would be interesting. Dictator CMS (the one before PW) used tags like this for images, except that each image could be assigned a tag directly in the editor. Then you would type the tag (like "image" for example) in any text field like this: {image} If multiple images had the same tag, it would display all of them. Any image could have multiple tags too. If you wanted to assign a CSS, class, you'd do it like this: {image}.class So you could create a CSS class like "left" and "right", and display an image like this {image}.left If you wanted to grab an image from another page, you'd do this: {/some/other/page:image} You could actually do the above with any field. So if you wanted to display the 'body' field from some other page, you could use this tag: {/some/other/page:body} While I'm less keen on tags nowadays, I actually kind of miss enabling an editor to use tags like this in their text fields. So am glad to see Diogo's module as a step in that direction. If people like being able to do this, we could always bring back some of the older tag options like above.

MadeMyDay is on to some good ideas and things to think about for future upgrades in the images module. I think the primary benefit is in the shared image repository, as mentioned. This is something that my own sites rarely call for, but others have indicated interest in a common image repository. So this seems like a potentially nice approach to think about for the future.

I've got to put most of my time towards launch a site for the first half of this week, but will plan on getting the account setup in the second half of this week. I'll get it setup for Nico and anyone else that wants to help, just let me know.

Sorry Alan, I was incorrect about the automatic access checking in find(). I'll blame it on too many days (or drinks) at sea. Since an actual page ID was specified, there is no access checking because IDs are very specific. If you know so much about a page as to specify it's ID, then PW assumes you really must want it. So the find() would perform the same as get() in that case, which is what I forgot in my last code example. I think this may be more what you want: if($page->id == 1232 && $id = (int) $input->urlSegment1) { $redirect = $pages->get("id=$id"); if($redirect->id && $redirect->viewable()) { $session->redirect($redirect->url); } else { throw new Wire404Exception(); } }

Sounds like some good ideas for a module. While this isn't a need I come across in my own projects, it seems to line up somewhat with the needs others have mentioned to have a shared image repository, separate from one they'd create with a page. That's correct. The primary key for an image is its page ID + sort order (if multiple images in the field). Once loaded in memory, images are indexed by their filename. Another image fieldtype could certainly add an ID property to a table easily.

I think you are right that rtfm is the modx way. I don't really want to seem like we're trying to copy them on that. We probably need a term that doesn't necessarily label it as the comprehensive manual, because we have the main site docs. I kind of like the one sinnut mentioned "guide", since it doesn't infer itself to be an all-inclusive manual and it also seems more clearly distinguished from API, which is the named use by the docs on the main site. I also like "wiki", except that it says more about the software running it than it does about the content, and I'm not sure wiki means anything to the intended audience. @Pete are you okay with MediaWiki or can you think of something better? I know you mentioned some concerns about it as things get large. I have a feeling we won't be getting that large (at least not by Wikipedia standards). And having the IPB->MediaWiki integration with the thing Sinnut mentioned seems like it would solve the multiple account issue. Still, I have no experience with MediaWiki, and it sounds like you do, so don't want to jump into it if it's going to be a bear.

What version of PW are you running? It should just say "Add New" in the button. Though the button did used to say "Add New Page."

The only problem there is that PW's output is then getting routed through WordPress's language functions and gettext(). If it works, great, but definitely potential for unknowns and extra overhead. One alternate approach would be to avoid including PW from WordPress and instead have WordPress load PW's output from a web service. For instance, you could do this in your WordPress template file: echo file_get_contents("http://domain.com/path/to/page/"); If you need to pass any params to do, just use GET vars: echo file_get_contents("http://domain.com/path/to/page/?var1=abc&var2=123"); Your PW page template will render the content for inclusion in your WordPress page, meaning a block of HTML (partial) rather than a full HTML document.

I just tried to duplicate but couldn't get that behavior unless I left the role unpublished. An unpublished role isn't meant to show up as an option. When you created the 'media' role, did you click the publish button?

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.