ryan

I look forward to getting ProcessWire compatible with Composer. That's one of the things I'd wanted to do with 2.4 though other priorities for ProcessWire have gone ahead of it and likely won't be supporting it till after 2.4, but hopefully soon after. We may need to make changes to directory structure, but I'm averse to doing anything major there as I think we need to give priority to what's best for the web sites that ProcessWire powers over what's best for Composer. But we'll do what we have to do, just always in the context of our intended audience over Composer's (which have crossover, but are also different in many ways). Our audience veers much further towards web developers than dedicated PHP coders. Most of our audience is not integrating multiple PHP projects, but we do want to better support the few that are. 2.4 development is pretty much finished. Just trying to work out all the bugs before releasing it. Though I think it is already just as stable as 2.3 for the most part. I am also very interested in evaluating PSR-4 for ProcessWire. With regard to PSR-2, I'm less enthusiastic. Standards are great, and I support the PSR-2 standard for new projects looking to adopt a standard. But I think it's silly for projects that have already adopted a standard, as PSR-2 is a lot of compromise. ProcessWire's own code standard doesn't compromise so much, and in our context PSR-2 is a downgrade. However, I also see it as largely a non-issue. I don't care what standard people contribute code in, as IDEs make it largely irrelevant, at least for the way we merge code here. PhpStorm converts code to ProcessWire's standard automatically. I just encourage people to code in a standard that they find most readable and usable for them, so long as it's consistent.

Soma, I was able to duplicate the Repeater ready item issue and it should be fixed in the latest commit.

I have no idea where that's coming from. It's not something I'm seeing here. I've never named anything "Start", but that's kind of cute in a Windows-kind of way. It's not locked for me either (I can change it here). I'm not aware of any core changes that would have anything to do with this. That's odd. This is the line that's throwing that exception. Apparently a class_exists("PDO") is failing in your PHP install. Usually that would mean that PDO isn't installed. If you'd like, you can try commenting out that line to see if PHP is perhaps incorrect about the lack of PDO. But my guess would be that either PDO isn't really installed, or class_exists("PDO"); is not a reliable way to tell if the PDO class exists (?). I've never specifically added it to that part. I was kind of assuming fieldsets within repeaters were a bit unlikely. But clearly I'm wrong on that. Looks like the icons are the wrong color, for starters. Most likely there is a style being applied to the existing repeater items that isn't applied to new repeater items. That should be a simple fix, I'll work on tracking it down.

Check what createdUser is resolving to, and make sure it is what you expect. $createduser = wire("page")->createdUser; echo $createdUser->name; // is it showing the user you expect?

MarkupGoogleMap is going to attempt to fit to all the markers you add to it. So the zoom, lat, lng settings you send to it are only going to matter if you only send it 0 or 1 markers in $items. For instance, if you replace "$items" with "new PageArray()" then you should see your zoom, lat and lng options working.

First off, I really think that what you are looking for is just multiple branches in your site tree, one for each language. You don't really need any language support modules installed for this. This is a pretty good way to go when you have the needs you've indicated. When your navigation needs are going to be significantly different across languages, multiple trees is probably the best way to go. But if you want to stick with language support and multi-language fields, then it looks to me like the LanguageSupportPageNames module (included with core dev branch) already does what you are trying to do. My understanding was that the main issue you ran into is that you have instances where you don't want the default language to be active. A couple ways to accomplish this would be 1) just consider the default language to be not in use (don't link to the default language version of any pages, and don't let the user choose that language); or 2) add your own "disable default language" checkbox to every page template and check for it when outputting navigation, etc. Basically, I think there are a lot of very simple solutions if you use the tools that are already there.

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.