ryan

Nice job Adrian! Please add to the modules directory too, when you are ready.

time() is not unique enough. By clicking the link fast, you are managing to get some pages with the same exact timestamped title. Since you are setting the 'name' to this as well, it's failing to create the page and resulting in the error you are getting. You can solve this by either using something more specific like microtime() or by just not setting the name and letting ProcessWire come up with it for you.

Rather than str_replace'ing in pipes, I'd suggest just using the "~=" operator to perform your search. That way it will track down your words without them having to be next to each other. It also requires that all the words are actually present, unlike "|" which is essentially saying "this OR that". I gather you probably want "this AND that", so ~= would fit the bill. If the keywords are page references, then you probably have to stop thinking of them as keywords and more as categories or tags, at least from the development side, and code it the same way. I'm assuming your keywords field is named "keywords" and that the words are stored in the "title" field. You could attempt to match the title of the keyword pages for all the words: "keywords.title~=guitar lessons". You could attempt to match the the title of the keyword pages for any of the words: "keywords.title*=guitar|lessons".

Great to have you back here Joss, and fantastic epic post!

Thanks for your work here. Maybe you want to add it to the modules directory under the "proof of concept" category? That way it's implied that it's not a plug-n-play type module, and that it may need further adaptation by the developer to use it.

You are absolutely right. Not sure how I managed to implement a header() call with two arguments like that, or how on earth it was working before, anywhere. But it should be the single argument version of the header() call. I've fixed it and pushed in the update. I'm also leaving out the charset=UTF-8 as I've read elsewhere that it's implied with a JSON header, so kind of redundant. Thanks for finding this.

If you don't want a user deleting pages, then it should be as simple as not giving them page-delete permission. If you want to change the behavior on a per-template basis, then come up with two roles... one that has delete permission and another that doesn't. Give the user both roles. On templates where you want them to be able to delete pages, assign both roles. On templates where you don't want them to be able to delete, then only assign edit permission to the role without page-delete permission.

Most likely your /posts/ page has hidden status. If you uncheck the hidden box on your /posts/ settings tab, it should show up in the sitemap.xml. An alternative would be to modify your sitemap code to allow for hidden pages by changing the $page->children call to $page->children("include=hidden").

Maybe you have badBIOS?

Tried out Fira, but it definitely screams Firefox. A nice font, but I can't look at it without thinking of the Mozilla lizard or whatever it is. A little hard on the eyes too, at least on my screen (I'm seeing lots of lizard tails). It seems like webfont technology on the PC side isn't quite there yet to the point where we should rely on it, though let me know if there's any other fonts you think we should try. Thanks Diogo! I will go ahead and add this.

Craig, thanks for your tests. Both of your screenshots looked pretty decent for Windows. So it sounds like the one on the right is Arial? Arimo looks pretty good on the left (at least compared to the earlier Windows screenshots), but relative to Arial, it looks a rather fuzzy. I would choose sharp and boring (Arial) in this case, as I think the usability of the type is much more important than the distinctiveness of it for this application. On the Mac, this really isn't an issue, as Arimo renders just as sharply as Arial. Do all web fonts render a little fuzzy on Windows? If so, then I think we have to just stick with Arial on Windows and limit our Arimo usage to Mac. Though if we can solve it by using a different face (Fira?) then I'm good with that too, so long as the face still portrays the same anonymity that Arial and Arimo do.

ProCache doesn't cache GET variables just because there would be an infinite number of possibilities to the point where it would fill up your hard drive with cache files. However, you can tell it what GET variables should bypass the cache. By default, any GET variable bypasses the cache. However, ProCache will cache URL segments, which can perform the same duty as GET variables. So in your case, if you enabled URL segments for your template, then you could cache both /path/to/page/ and path/to/page/TEMPLATE_NAME/. However, please be careful with any code that takes any kind of user input (especially GET variables, and URL segments to a lesser extent) and translates that to a file that gets included. This technique is full of security implications, so you've got to be especially careful. Also see the pinned page on using URL segments with ProCache in the ProCache board (which you should now have access to).

Thanks for testing it Manfred62. I'd say it still looks pretty bad (can't tell there's been any improvement at all). Is something just wrong with this font (Arimo) regardless of whether it's from Google Fonts or self hosted? The regular text looks mostly similar to how it does in OS X, but the bold looks like a different font entirely. This is what it looks like here (Chrome in OS X).

Good to see you here Joss!! If Teppo keeps this up, we'll just have to add a new docs tab on processwire.com that goes straight to his site.

It sounds like there are various issues turning up as a result of this box sizing, though the only one that strikes me as a big concern is the image stretching Soma is seeing. What do you guys recommend as a fix for this? I originally added the box sizing per the recommendations here. Happy to change anything that needs changing, but not clear on what to change. Feasibly we could switch to a different icon set in the future, and the icon-iconname format strikes me as more portable? The fa-iconname format seems to be branded specific to Font Awesome. It looks like you've got a new /site/templates-admin/ without a corresponding new /wire/ directory. Click on the "download ZIP" button on this page. Take the /wire/ directory and replace with your existing /wire/ directory. Then take the /site-default/templates-admin/ directory and replace your /site/templates-admin/ directory with it. Can anyone with a PC and chrome confirm that the fonts are displaying correctly now that we've switched to self-hosted Arimo? It sounds like the easiest way to tell is whether the letter "e" looks like the screenshot in the post above this. Does anyone have any ideas on how to fix the submit buttons that aren't registering half the time?

Just committed, so it should be there now on dev. Modules > Core > Process > Image Select

Are you wanting to store just the selector (text) or both the selector (text) and the resulting page IDs? I'm thinking just the selector text, since the resulting pages may change ... that's what's kind of unique about storing the selector string, as the results of it really couldn't be known until runtime. If that's the case, then I don't think there would be any reason to extend FieldtypePage, as it is heavily geared towards storing IDs of page (references). Your own Fieldtype could store just the selector string, but expand that to a PageArray in the Fieldtype::formatValue function, as one possibility. The main disadvantage of storing just the selector is that you couldn't query the field from another selector to know what pages were stored in it... since the results are determined at runtime and not stored on disk. If you only need the selector string as a way to determine which pages are selectable (as opposed to which pages are selected), then this is pretty much in-line with what the PageAutocomplete inputfield does. Only it sounds like you need to define this selector on a per-page basis, rather than a per-field basis. Your Inputfield certainly could create its own DB table if you wanted it to. While it's true that dealing with the storage-side is exclusive to Fieldtypes, this one would be kind of a grey area. If it suits your needs and is ultimately simpler, don't be afraid to have your Inputfield create it's own DB table and store whatever it needs to. But keep in mind that by taking this route, it may prevent the Inputfield from having much value in other contexts like other Inputfield forms or FormBuilder (which may not matter) ... this is already the case with PageAutocomplete and PageListSelect Inputfields.

This is specific to the PW blog profile -- after adding the new template for the widget, you'd go to Pages > Tools > Widgets > new. Add a new page in there called Google Plus, using the new template you just added.

I can't duplicate that here. Are you sure you've got the latest version? Do you have the checkbox checked that is between address and latitude? Try hitting reload once or twice on the page as well, just in case something older is cached.

Adrian, sorry for some reason I got it stuck in my head that we were talking about API level adding of images rather than capturing those added from the admin. The install() method doesn't get called on images added from the admin because InputfieldFile puts them right in the target directory, if I recall correctly. So I think the hook that you would actually want would be one of these methods (both of which are already hookable): InputfieldFile::processInputAddFile($filename) This one adds the given $filename to the $pagefiles, perhaps you could rename $filename it on a before call and change the value of $arguments[0] to be your new filename? or... InputfieldFile::fileAdded(Pagefile $pagefile) This one is called after a new file is added, giving you the completed $pagefile

Which version of ProcessWire? It sounds like you are using multi-language support, in which case I'd strongly suggest using the dev branch (2.3.5).

Those are two different selectors. The first is looking for pages with the phrase "guitar lessons" in title or body. The second is looking for pages with the words "guitar" OR "body" in the title or body. If the first one is failing, then that would be because the phrase "guitar lessons" don't appear in the body of any pages exactly like that (though this is not case sensitive). This sort of thing can be affected by spacing too, so if you see "guitar lessons" on a page, view the source and see if there are actually two spaces between the words or perhaps a pesky or something. You might also want to consider if "title|body~=guitar lessons" might be better for your needs here. That would match pages having both of the words in either the title or body, but they wouldn't have to be phrased together.

Just added and will commit this weekend–thanks Soma.

It's using URL segments, where the number (id) is the URL segment. Here's the code from that template if it helps: <?php $id = (int) $input->urlSegment1; if($id < 1) throw new Wire404Exception(); $marker = $pages->get("template=map-item, id=$id"); if(!$marker->id) throw new Wire404Exception(); echo $marker->render(); That $marker Page is a page using template map-item. The map-item template contains the fields for each map marker item like location/coordinates, categories and notes. The implementation of the template file is just to output a <div> with that info in it, and that's what gets sent through that $marker->render() call above, which goes straight through ajax. It's not technically necessary to do it this way, but it does enable us to just pass through an ID on the front-end, since the full URLs take up more space without offering any real benefit in this case. So it's just more efficient to route through a known, consistent URL with an ID appended to it.

You can also just check the page type within the hook function. By simply issuing a 'return' if it doesn't match the template you want, that duplicates the behavior of accessing an unknown property (resulting in a null value being returned to the caller). wire()->addHookProperty('Page::hello', function($event)) { if($event->object->template != 'basic-page') return; $event->return = 'hi'; });