Leaderboard

ProcessWire removes duplicates grouping results by page id thus giving only distinct pages as a result. So no need for a distinct there. That 3000 records shouldn't include any duplicates assuming it's a result from a single $pages->find() call. Solution would be to add more restricting selectors to the find itself. If that's not possible then pagination is the way to go. Add start and limit selectors to get records from 0-999 (start=0, limit=1000) and loop that increasing start by 1000 on every iteration until you've got less than 1000 result rows returned. This way you'll end up with less Page objects in memory at the same time. Something like 500-1000 rows at a time should be fine, but that depends on how heavy data you've got there. (Actually, only autojoin fields and the fields you're accessing do count here.) You may need to call $pages->uncacheAll() after every iteration to flush the previous iteration's Page objects from memory. No example at the moment, sorry, got to go for now.

Thanks to Ryan, I've managed to knock my next module into usable shape. The URL Shortener adds a link shortening feature to ProcessWire, so you can host your own short URL service from a PW site now. You can create as many bins for short links as you need & the module sets up an example bin when you install it. Each bin is a PW page that uses the LinkShortenerHome template. This template allows you to set the length of the shortened links that will reside in it. Shortened links are simply child pages that automatically use the LinkShortener template. As these links are normal PW pages you can manipulate them from the admin page tree just like any other page. Anytime you create a new short-link page in any of your bins, it will automatically be named with a random string that is not already in use in that bin. You get the chance to review this short string before adding the full URL and saving the page. Once the page is saved any visit to the short link's URL will be redirected to the full URL.

There are often situations when it would be valuable to login using client's credentials. It is slow to create new user with same roles and test that way. It would be great to have a module which allows to login using any username and without changing the password (of course security of that module needs to be top notch). Other use case is when adding additional login methods (like fb, google account, github... etc). If I have understood correctly, currently we always need to know (or change) the password to be able to login. So what I am looking for is something like: $session->forceLogin($username);

New site made with PW: http://yogacentergreenwich.com/ [edit - should have provided some details...] - formbuilder for contact form - image gallery pagination code from here - pw logo from here - ecwid for shopping cart - campaign monitor for the newsletter -marc

I think it has to do with the users page which has no outputformatting like regular pages. So even a single (max1) image field will be a wire array. Ryan correct me, but I think $user has outputformatting on and if you retrieve user through $users it is out. So to test you could add a date field and see what that outputs in both cases.

Ok, found some time today so I published a first version of a basic ecommerce template. The Shop Plugin is fully implemented. Every content is PW driven. You got the possibility to mark a product as featured or as topseller to let them shown at the homepage. Also you could mark a brand and a category as featured, so they will be outputted aside the slider. Slider content is generated from pages. My focus was to implement the most common options and to give the user a base template to work on. Built on top of the Twitter Bootstrap Framework. Still working on it http://process.besser-landen.de/ Plz dont laugh about the brands

I guess you can also use if($user->image!='') if you are any images in you image field you cannot check the url, happends to me also, I always check if the object image is not null or the count as you've done.

Hi folks. I've almost finished a site using this module, it works fantastic so far ;-) One thing I noticed AND solved (temporary): When enabling caching on templates, then the cache file gets generated only for the language of the first request. Switching between languages does not work anymore, always the same language is loaded. That make sense, because PW stores a cacheFile per ID. Solution: PageRender module in the method "getCacheFile", add after line 118: //Check the language if ($this->user->language->title != 'default') { $lang = $this->user->language->title; $lang = $this->sanitizer->pageName($lang); $secondaryID .= $lang; } This code adds a secondary Cache-ID per language resulting in a cache file per language. How to implement this correctly? I think the getCacheFile method should be hookable so this module can modify the returned CacheFile name.

You could use ID_name or name_ID.

Hi Luis, You could also set Status of a Page to hidden, then ProcessWire does not include the Page in searches and lists (Menu). This setting can be found under the "Settings" tab of the page -> Hidden: Excluded from lists and searches. If you want a hidden page to appear in a search, add "include=hidden" in the Selector, for example: $pages->find("template=basic-page, include=hidden"); //or $homepage->children("include=hidden");

Depends on the situation. I think for a status/time POV like Twitter or Facebook an infinate scroll is a very good solution, but one has to think very carefully how to implement this. I've seen this being used on newspages and mostly it's just a fancy solution for a problem that's doesn't exist.

Every other major player on the social web has moved to OAuth2 - I'm pretty confident that a major platform like Twitter will soon follow suit.

Ryan, is it ok if I use the P and the W from the official logo and adding a shopping cart for our little german shopping module?

This is exactly correct. Lets say you've got this page /user-profile/ in your site. You also have a template called user-profile, and it has URL segments enabled. In the code, all you need to authenticate is to compare $user->name to $input->urlSegment1. Meaning if user 'onjegolders' accessed the URL: /user-profile/onjegolders then you would allow them to make changes to their profile. if(!$user->isGuest() && $user->name === $input->urlSegment1) { // user is authenticated and may change their password if($input->post->submit_pass) { if($input->post->pass !== $input->post->pass_confirm) { echo "<h2>Passwords do not match!</h2>"; } else if(strlen($input->post->pass) < 6) { // if you want to enforce a minimum password length (recommended) echo "<h2>Your password is too short. Must be 6 characters or more.</h2>"; } else { $user->of(false); $user->pass = $input->post->pass; $user->save(); $user->of(true); echo "<h2>Your password has been changed</h2>"; } } echo "<form action='{$page->url}{$user->name}' method='post'>"; echo "<p><label for='pass'>Change your password</label>"; echo "<input type='password' name='pass' /> "; echo "Confirm: <input type='password' name='pass_confirm' /></p> "; echo "<input type='submit' name='submit_pass' />"; echo "</form>"; } The above was just written in the browser so may need tweaks.

Technically the pageName sanitizer isn't actually necessary here (as PW wouldn't even get the request if the pagename wasn't in the right format), but it is a best practice to sanitize anything you are planning on putting in a selector. So I would do it the same way as apeisa and sanitize with pageName, even if it's not technically required.

Once installed, you'll see a new "Short Links" page under your site root. This is a bin for storing shortlinks - which are simply child pages. If you edit the "Short Links" page you'll see various parameters that control the automatic generation of link names. You should be able to leave these as-is with no problems (unless you need more than 27,000,000,000+ links in your bin!) The parameters, if curious, are... You can add as many bins for shortlinks as you like to your site, just create a new page using the template "LinkShortenerHome" and give it a relatively short page name. Anyway, let's add a short link now. From the page tree just click new next to the "Short Links" page. This creates a new shortlink page (uses the "LinkShortener" template) and automatically creates an unused, random, page name using the parameters we just looked at from the parent bin. Something like this... If you are not happy with the spelling of the generated shortlink (if it happens to be offensive in your native language for example) then you can change it now and hit the save button which takes us to... ..where we just type/paste in the target for the redirect this shortlink will make and then hit the publish button... ... and we can see the short link and a "Go!" link for testing it. That's about all there is to it except to say that it will help out the ProcessRedirects module if it is installed and you have configured the URL Shortener to help generate names for it. HTH.

Pete, you're right in saying that download size won't make a big difference, but complicated codebase sure does. Of course good code should be modular and allow relatively minor additions (such as new auth methods in this case) without the need to alter "core module"..

Just as Soma mentioned, use the FieldSet field type to create your columns, and then set their width so they float next to each other. In my case I made 3 FieldSet columns. (column_1, column_2, column_3) — although I only used 2 columns in the screenshot above. I didn't want to change how the admin looked anywhere other than within these columns, so the only thing I changed about the default theme was a few lines of CSS that are specific to these columns. You can grab the CSS here

One thing to remember: there can be multiple pages with same names (but with different parent). But here is how you do it (this returns the first page it finds): $myPage = $input->urlSegment1; // Remember to sanitize! $myPage = $sanitizer->pageName($myPage); // $pages->get() returns single page while $pages->find() returns PageArray $p = $pages->get("name=$myPage"); // And finally, we want the url echo $p->url;

Thanks Ryan, I managed to sort this out by sticking with the repeater option, but instead of using a repeater as a singular method for date entry, I used it for "additional dates". That way, the majority of events are entered with a typical start/end date, but events with more complicated schedules can use the repeater. I set the ready fields to 2, that seems like a good place to start. I think this will be less confusing to the people entering events — at least I hope. See attached. (note: tweaked the admin via FieldSet to create 2 columns for calendar entry, I love how flexible PW is.)

I've used and still use MODx Evolution(v1) and Revolution(v2). I still run a production site on Evolution. This is nothing fancy and i've tried migrating it to MODx Revolution. This was a painful experience. I totally agree with yellowled, Revolution is powerful and feature-rich. It has some nice add-ons, an underlying framework and orm-like system, xPDO, for making your own modules. But imo things are very complicated and clunky. The back-end is pretty slow (heavy ext.js) and confusing. Clients don't tend to like it. Snippets, chunks, template variables. To understand user management, ACL's and stuff like resource groups you have to be a rocket scientist. I wouldn't waste time on MODx right now because they kind of acknowledge their mistakes with the announcement of MODx 3.0 for 2013.