ryan

I haven't used the async attribute before. The info for it seems to suggest that it's only for "external" scripts, but doesn't clarify what they mean by "external." I would assume that to mean scripts that exist on another domain, but who knows, maybe they just mean scripts that aren't inline in the HTML? If it's not implying another domain, then it seems like an interesting possibility. Load order is pretty important for a lot of these scripts, so not sure we'd be a good case for it. Though there may be a few scripts we can do it with.

Awhile back, I made an Ajax API for querying pages in the admin via the ProcessPageSearch module. It is used by [for example] the PageAutocomplete Inputfield. I thought this capability would be useful on the front-end too, so this module brings it to the front-end as a page in your site that you can put wherever you want to. The way you use it is exactly the same as the one in ProcessPageSearch, but this one is a little more strict, given that it's publicly available on the front-end. By "more strict" I mean that you have to define what you want to allow in terms of input and output in the module's configuration. The web service takes it's query from GET variables in the URL and returns results in JSON format. It installs a page called /service-pages/ in your site, and you are welcome to move that page wherever you want. Here is the official page at modules.processwire.com: http://modules.processwire.com/modules/service-pages/ Once installed, you should view the /service-pages/ page that it installs because it outputs detailed instructions and examples on how to use it in your own projects. But here's a few excerpts from what you'll find on that instructions page: Input The /service-pages/ page can be queried with GET variables in the URL to return JSON-format results. The query string should follow a ProcessWire selector format ([field][operator][value]), but modified a bit for use in a URL query string. Here are a few format examples: Specify a single value: ?field=value Specify multiple fields and values to match: ?field1=value1&field2=value2&field3=value3 Specify multiple fields where at least one must match the value. Note use of "," rather than "|", something we had to settle for to make it work as a URL key: ?field1,field2,field3=value Specify one field with multiple possible values (it's fine to use "|" as a separator here): ?field=value1|value2|value3 Note that unlike regular ProcessWire selectors, multiple field=value sets are split with an ampersand "&" rather than a comma ",". Allowed Values The allowed values for field are set with the module configuration. You may also specify the following modifier keyword=value pairs: sort=[field] (Specify field name to sort results by) debug=1 (Enables debug mode producing human readable output) limit=[n] (Specify the max number of pages to return) start=[n] (Specify the result number to start with) include=hidden (Include pages that are 'hidden') Allowed operators The operator demonstrated by the "=" sign in the examples above may be replaced with any of the following operators in the query string: = Equal to != Not equal to < Less than > Greater than <= Less than or equal to >= Greater than or equal to *= Contains the exact word or phrase ~= Contains all the words %= Contains the exact word or phrase (using slower SQL LIKE) ^= Contains the exact word or phrase at the beginning of the field $= Contains the exact word or phrase at the end of the field As an example, this ProcessWire selector: template=property, body*=luxury, bedrooms>5, bathrooms<=3 ...would be specified as a query string to this web service like this: ?template=property&body*=luxury&bedrooms>5&bathrooms<=3 Allowed templates For security, the search will only be performed on pages using templates that are defined in the module's configuration. Output The returned value is a JSON format string in the following format (populated with example values): { selector: "title*=something, template=basic-page, limit=50", total: 2, limit: 50, start: 0, matches: [ { id: 1002, parent_id: 4525, template: "basic-page", path: "/test/hello/", name: "hello" }, { id: 1005, parent_id: 4525, template: "basic-page", path: "/test/contact/", name: "Contact Us" } ] } Each of the 'matches' values will also include all the fields you have specified to appear with the ServicePages module configuration. If an error in the query prevented it from being performed, a JSON string in this format will be returned: { errors: [ "Error message 1", "Error message 2 (if there was one)", "And so on..." ] } The web service honors user view permissions. As a result, if you are accessing this service from a superuser account, you are likely to get pages that others users may not see. Superusers get an "include=all" automatically, unless you override it with an "include=hidden". Returned field values The following field values will be returned for all matched pages: id (integer) parent_id (integer) template (string) path (string) name (string) Any other fields may be included from the module's configuration screen. Pagination To paginate, simplify add a "page[n]" url segment to the request URL, i.e. /service-pages/page2/?template=basic-page&sort=name

I guess I don't totally understand the issue here, as I've never had to wait for anything in real use. And I'm using a run-of-the-mill consumer grade internet connection. I recognize we've got a lot of small files to load (the modularity is intended), but I've never personally felt any load time drawbacks. And once loaded, of course they are then waiting in the cache, not needing to be loaded again. Perhaps it's more a matter of connection speed, but this is a web application not a front-end facing site where thousands of people might hit it at once. I'd consider it a best practice to minimize the quantity and size of loaded files on the front-end, but might consider it the opposite in an admin application like this, where modularity is far more important. If load time is an issue for anyone, I think we might do better to find ways to optimize the browser cache. For instance, can we send some cache control headers to reduce the 304 requests (or perhaps something like that). Though I'm also not against automated combining/minifying, if there are good opportunities to do it without side effects, and there is a tangible (not just tiny measurable) performance benefit to be found.

I almost always try to structure sites in a manner is consistent structurally and navigationally. I also think this is one thing that differentiates ProcessWire sites from some other CMSs (like Drupal), where the navigation structure is completely disconnected from the content organization -- it's maddening. So I think it's good to consider structure and navigation in the same process when possible. If you have a huge disconnect between the two, it's good to look at re-evaluating the structure. But I totally understand the need to have a custom menu in one place, or insert a page from a menu in another place, etc. Here's how I do it: When you need to have a navigation link in an existing structure, even though the page isn't in that structure, you can give it a placeholder. Create a field called "redirect_url" of type "URL". Create a template called "redirect" and add your "redirect_url" field to it. Then paste the following in your /site/templates/redirect.php file: <?php $session->redirect($page->redirect_url); Now whenever you need an extra navigation item somewhere in your structure, without the page actually being there, create a placeholder page using the "redirect" template. Put in the URL to the page you want it to go to. When the page is viewed, it'll end up where it's supposed to go. If you want to avoid the 301 redirect, you can also just update your navigation output code to give preference to a redirect_url field when it exists. And it'll use redirect_url when it's populated, and url when it's not: <a href="<?=$page->get('redirect_url|url')?>"><?=$page->title?></a> When you need to create a custom menu that has nothing to do with the site's structure, use a page reference field. For instance, lets say you wanted to create a "footer_links" navigation. You'd create a new multi-page reference field called "footer_links". Choose "Page List Select Multiple" as the Input field for it. Add this field to your homepage template. Edit your homepage and use that field to select the pages, anywhere in your site, that will be in the footer links navigation. Then output them like this: <ul id='footer_links'> <?php foreach($pages->get('/')->footer_links as $item): ?> <li><a href='<?=$item->url?>'><?=$item->title?></a></li> <?php endforeach; ?> </ul> Let me know if I've answered consistently with what you were looking for, or if you are trying to do something else?

ProcessWire's session handler is just sitting on top of PHP's, so you should be able to close it down using traditional PHP functions after bootstrapping ProcessWire. I'm thinking that if you can close it down before initializing the Silex one, that may work. If that doesn't do it, you could try to prevent PW from initializing a session by temporarily removing it's write access to /site/assets/sessions/ (before bootstrap), then enable write access again after bootstrap... a bit of a hack, but just trying to find something that might solve it. So long as debug mode isn't on, I don't think you'll see any errors. Btw, by "bootstrap" I just mean the include("/path/to/pw/index.php"). We're going to be supporting DB-based session storage very soon here (hopefully 2.3), and I'll look into providing the option of disabling PW's session handler entirely when adding that.

Most likely Apache is running as the same user for everybody on the server, probably with a name like "nobody". So it's not going to be able to write to a directory that is only writable to you (755)... it'll only be able to read from it. If the accounts a truly jailed from one another, and one account can't manipulate the files of another (by way of Apache) then 777 should be no problem. Likewise if it's a dedicated or VPS without untrusted accounts on it, then it should be fine. It sounds like that's the only way it'll run right now, so I would set it to that and then check with the web host what they recommend for Apache-writable directory permissions, and do what they suggest. You might also inquire if you can get an suPHP environment, where Apache/PHP would run as your account--in that case, you would only need rwx to yourself (700) or writable to you and rx to others (755).

The only reason why $this->pages->get(123); wouldn't work in a class that extends Wire or WireData (as yours does) is if you added your own implementation for a get() or __get() method. That's because something like $this->pages (or $this->any API var) gets routed through both get() and __get() in Wire/WireData. The nice thing about wire('pages') or wire('any API var') is that it works anywhere. Also wanted to mention that wire('pages'); is the new Wire::getFuel('pages'). They are both equivalent, but the getFuel() one just looks ugly. You'll see it used in some older modules and core code, but there's no reason to use it anymore. (though also no real reason to change it if you already are, as it's not going to be deprecated either).

An image field shouldn't perform any differently in a repeater. Or if it is, it's not supposed to. Can you go into more detail about the difference you noticed--you've got me wondering if there's a bug somewhere.

See the section on this page "Using the API to add or remove repeater items": http://processwire.com/api/fieldtypes/repeaters/ (though let me know if I've misunderstood the question) Already did awhile ago.

I don't think that you should need setTrackChanges. This is something that the core automatically turns on for every page it loads, so you don't need to do that unless you've got some other code elsewhere that did a setTrackChanges(false). There's also no reason to do $form->setTrackChanges(). So I'm thinking you should just remove any reference to a setTrackChanges function. Your form may be nested, in which case your code example is only going to handle the first level of fields. Try replacing your $form->children() with $form->getAll(), which should give you all the form fields flattened.

I used to care a lot about having nicely formatted HTML, primarily because it was much easier to debug. But now with inspector tools like those included with Chrome and Firefox, it's rare that I'm looking at the raw source anymore to debug things. The source formatting doesn't seem be to be worth the trouble given that the inspector tools are going to output it nicely formatted and structured regardless of where the linebreaks and tabs are in the HTML source. In fact, the extra "\t" and "\n" characters in the PHP generated markup often make the PHP side of it harder to read and maintain (you've probably seen me doing that too). So I guess I'm now of the opinion that this kind of formatting to the markup isn't nearly as useful as it used to be, and I'm trying to get away from doing it.

The name/title screen is something that can't be skipped because a page can't exist without at least having a name. That screen is what creates and initializes the page as something that can be populated by your fields. One example would be a files or images field, which can't be populated until the page exists and has an ID. I'm not sure that I understand the full context of your need, so forgive my answer if it's not relevant… But if you really want to skip the PageAdd screen, you could create a bunch of ready-to-go but unpublished pages: for($n = 0; $n < 100; $n++) { $p = new Page(); $p->template = 'vehicle'; $p->parent = '/vehicles/'; $p->status = Page::statusUnpublished; $p->title = "Unused vehicle page $n"; $p->save(); } Regardless of whether you do something like the above… on another subject would be how your hook knows when to populate an automatically generated 'name' field to your page (If I understand correctly what you were trying to do). I'm thinking you could add a hidden integer or checkbox field to your page (one set to be 'hidden' from it's input tab). Then populate that field after you've set your automatically defined page name. That way your hook would know which pages to setup the name for and which pages to skip.

Looks great summer. Would you mind adding it to the ProcessWire modules directory too? http://modules.processwire.com/add/

That's a really good point. This would explain it all.

I think it might just be a matter of how it's described in the field setup. It originally started out as just a toggle: "single image" or "multiple images". But it was such a small stretch to make it also behave as a max files quantity, that it went there instead. And I think that may have been the mistake, because the max files quantity is serving two purposes rather than one. But the solution is pretty simple. It would be relatively easy for me to just add another Inputfield to the configuration that says: "Do you want this field to behave as a • single image or • multiple images?" And it would just be a symbolic front to the max-images setting, that hides the multi-purpose nature of it. While there might be some benefits to having it split out into two separate fieldtypes, there are also great benefits to having it as one. It always behaves as a multi-file field when output formatting is off, so any modules written for files/images automatically support both single and multi-file versions (with no effort). If these were split up as different fieldtypes, it would be more to maintain and people would have to potentially get a lot more code involved when writing anything to do with files/images.

I'm not sure initially. Do you see any javascript errors or anything like that in your browser developer console? Fieldtypes like the Repeater and Autocomplete weren't ever really intended to be used outside of ProcessPageEdit, so it's possible there's some dependency in there that I'm not thinking of. It seems like the most likely possibility is a missing JS file or something which may turn up in the JS console, but hard to tell for sure.

Not sure. I think it's either a children's game or has something to do with MS Office, or both.

Not really sure how to tell short of trying it myself, as I'm not aware of any issues with uploading, and I use a Mac all day long. It might be helpful to get a better look at those "out of memory" and "imagesizer" errors. Also, if you can take a closer look at the images and see what DPI and color space they are using? For instance, I've occasionally seen some strange things with PHP's GD functions when going into 300 dpi or CMYK images. If you want to send over the images and/or login info, I'll be happy to give it a go on my mac to see what happens.

Sounds good, I had planned on adding a quality setting with the $options array to the size() function like mentioned above. I'll push this forward in 2.3. Interrobang I think that looks like a good clean route too--decorating an image with an imagesizer. Though for doing the same thing, I think the $options array may be a little simpler both to implement and [subjectively] use. Plus we're using similar $options arrays elsewhere in ProcessWire, so it'll maintain consistency there.

Good find, I just deleted all the spam pages. But then got into the user accounts and discovered we've got nearly 500 spam accounts in there, all with spam profiles. I don't know how to clear that out short of going through them individually 1 by 1, and don't want to spend the rest of the day doing that. Seems like MediaWiki might just need a little too much babysitting with the spammers. Unless somebody here knows how to administer MediaWiki (?), maybe we should just move the content that's there into the main site. And if anybody wants to submit new documentation, I can set them up with a ProcessWire account instead. I think MediaWiki was a good test, but doesn't seem like we're really using it for it's strengths enough to warrant keeping it. Though if anyone thinks we should keep it (and maybe knows how to clear out these spam accounts) that's fine with me too.

I think that the push-to-top/push-to-bottom buttons that Soma mentioned are your best bet, as that makes a simple job of moving an image to the top of bottom. But you'll need to save the page with the image on it before you'll get that option. As another alternative, you might try just reversing the order that they are output on the front-end of your site: foreach($page->images->reverse() as $image) { echo "<img src='{$img->url}' />"; }

Awesome update, thanks Wanze!

How about Atlanta at Piedmont Park: ProcessWire BeerBQ 2012… 8) on second thought, I think I'm the only one in all of Georgia using ProcessWire. I need to change that, but something called "Word Press" (?) is the buzzword around here.

That particular fieldtype (autocomplete) probably can't work on the front-end because it depends on an Ajax service from ProcessPageSearch. It might be possible to get it working if you are actually logged into PW admin at the time, but not sure if this is useful if you are trying to make it front-end.

I'm a little confused about what you mean by the 20% quality setting and how this relates to retina displays? I would think a 20% quality setting would look horrible, but obviously it doesn't (as your examples show). So I'm just scratching my head, not sure exactly what this is. Looking on my desktop (30" dell screen) the first image looks potentially a little sharper, though close call. Looking on my iPad or iPhone (both retina) the second image is visibly sharper (especially on the first example). Quite interesting to see the difference, though not sure I'd notice if they weren't actually side-by-side. Still, can't quite believe those are 15/25 quality, so scratching my head.