ryan

There really isn't much point in a cropping=false value to this particular call, because that would force a stretched image... something that there is almost never a practical use for. You'd be better off just specifying only a width or height, to ensure you don't get a stretched image. But you are correct in that for the most part, ProcessWire only maintains one thumbnail per dimension. There is one exception: if you specify details about where it should crop, it should keep separate copies, i.e. $img1 = $image->size(200, 100, array("cropping" => "center")); $img2 = $image->size(200, 100, array("cropping" => "northwest"));

Xeto, welcome to the forums. You have a few options: 1. Leave the data in your tables and just query it from ProcessWire using $this->database (PDO) or $this->db (mysqli). 2. Export your tables to a spreadsheet (CSV) and import using the ImportPagesCSV module. 3. Query or export your data out of your existing tables and create new pages from the API. This is the route I usually take. See the cheatsheet. Also see the Data Conversion section (at the top) of the CMSCritic case study, which describes how to query data out of an existing table and create new pages from it.

This module does two things: 1. Gives you the ability to perform text matching on page paths/urls with selectors, i.e. $pages->find("path%=blahblahblah"); 2. Adds an index of page paths in a separate table, potentially making retrieval of a page by path faster. Meaning, it can increase the performance of $pages->get("/path/to/page/"); and similar types of retrievals. I honestly haven't used this module all that much. Its performance benefit is theoretical and I'm not sure it's actually measurable. As a result, I'm not sure I'd necessarily install it unless you want to perform text matching on page paths. This one will probably be removed from the core in PW 3.0 and kept as a 3rd party module.

Brent, if I understand correctly I think I agree there. Though if you are wanting to query the code like "35" then your selector probably needs to be something like "template=program, code.title^=35". This may be a dumb question, but if the content editors already know the geographical codes, why use page references? Could you just store the codes themselves? Assuming both the matching string "35" and the resulting page references need to be stored, then I'd probably approach it the way you are. If it was something I was releasing for others to use, I'd make a Fieldtype and an Inputfield. The Fieldtype would have the same schema as the current FieldtypePage schema, except that it would have an extra column for "code", to contain an integer that the user enters. I'd have the column indexed like the others, so that it could be queried from selectors. It would offer a shortcut for querying, potentially faster than querying the page titles of page references. One of the advantages of going the Fieldtype route is that ProcessWire will be managing things like deletions. If you delete a page, then it's going to delete the entries for that page in the DB. If you are managing your own via the Inputfield, that won't happen. This may or may not be an issue in your case. Just depends on how permanent the data is I guess. It could always be resolved fairly easily by adding a Pages::deleted hook. In your case, since the use is so specific I think just developing an inputfield, and storing those codes in your own table may offer a simpler solution. You'd just need to store the pages_id and code. Your render() method would do something like this: // get page being edited from ProcessPageEdit $page = $this->process->getPage(); $query = $this->database->prepare("SELECT code FROM your_table WHERE pages_id=:id"); $query->bindValue(":id", $page->id, PDO::PARAM_INT); $query->execute(); if($query->rowCount() > 0) { list($code) = $query->fetch(PDO::FETCH_NUM); $code = $this->sanitizer->entities($code); } else { $code = ''; } $out = ''; // here's where they enter the code, already populated with the existing value $out .= "<input type='text' name='{$this->name}_code' value='$code' />"; // then your page selection follows For your processInput method, you'd do the opposite... storing the code that was entered. $page = $this->process->getPage(); $code = $input[$this->name . "_code"]; // delete existing value if already present $query = $this->database->prepare("DELETE FROM your_table WHERE pages_id=:id"); $query->bindValue(":id", $page->id, PDO::PARAM_INT); $query->execute(); // insert the new value for code $query = $this->database->prepare("INSERT INTO your_table SET pages_id=:id, code=:code"); $query->bindValue(":id", $page->id, PDO::PARAM_INT); $query->bindValue(":code", $code, PDO::PARAM_INT); // or PARAM_STR if appropriate $query->execute(); Let me know if you want an example of how to do the Pages::deleted hook.

I don't care so much about whether my name is in the admin, but my understanding is that the company name has to be there, and I think it should. My full company name is Ryan Cramer Design, LLC. Very little of my business is design anymore (it's mostly development), so if the context is not one of design, I simply use the shorter version: just Ryan Cramer, or RCD. The plan is to change the company name to ProcessWire LLC, at which time I can change it to say "Copyright 2013 ProcessWire" like the other CMS projects do. The only reason I haven't done it yet is that it costs $ to do that, and I'm not running on a budget surplus at present. I honestly didn't think anyone cared what the copyright line said, so it's been hard to justify that change until I've got the extra cash to do it. Regarding use of a copyright line in the admin interface: the end users of the product (our clients) generally don't see or have any idea how to access the copyright statements in the server-side code/text files. So it should be visible to the actual end-users, with the admin tool they use being the most clear placement. Though I think the laws regarding this may vary from country to country, but I think it's better to just play it safe. Rest assured it will say Copyright ProcessWire at some point in the future.

Yes it sounds to me like there are class name collisions. That won't be an issue once both PW and Fuel are namespaced, but that also doesn't guarantee that the two will run alongside each other either. I do know of people that have used CI and ProcessWire alongside each other, and apparently that works pretty well. But I'm not aware of anyone running ProcessWire and another CMS running on the same request, including files from one another. Though I did once bootstrap Drupal from ProcessWire.

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).