apeisa

Ryan, have you thought about having file field for attachments?

Nice looking site! And great to see more Finns, tervetuloa!

Very nice sites you have build Joshua!

Currently fieldtype creates a new file with suffix like filename_1, filename_2 when files with same filename is uploaded. Most of the time this is good, but sometime it would be good to allow overriding the file. Would it be difficult to check if similar file exists and offer a js confirm wheter to override or create a new file? This is of course for multifile fields, since single file fields override always (not sure if that is every time preferred without confirmation?). I will take a look at this myself at some point, but interested to hear what others think about this? Which would be best UI here?

Ryan wrote earlier:

Very nice work Adam and co! Only one thing to consider: while first looking this with my mobile (and 3G connection) the fast carousel was very confusing, since images loaded only after it have rolled few rounds.

Thomas, I'm little tired and not following your code pretty well.. but this is how I usually handle duplicates while importing pages: $p = $pages->get("name=$sanitizedPageName, parent=/where/these/go/"); if($p->id) { echo "We have this already, skip or update"; } else if (strlen($pageTitle) > 1) { $p = new Page; $p->template = "my-template"; $p->name = $sanitizedPageName; $p->title = $pageTitle; $p->save(); echo "Imported: $pageTItle <br>"; } It is important to set the name for the page, so it will be the same that you are comparing it against.

http://www.lowendtalk.com/discussion/4585/experience-with-processwire

Ryan, I figured out the above bug. It comes from AdminBar - I disable template changing there. I will edit it to remove that selection all together.

This works, thanks!

Am I repeating myself here? Thanks Ryan, noticed the new commit!

Thanks Ryan. I am also looking for a way to hide roles field under settings tab (those are irrelevant since they come from template access). Does it require another hook or is it possible somehow?

This is taking shape nicely - Ryan, do you mind adding buildFormRoles method hookable in ProcessPageEdit.module? I would like to hide it all together and use own implementation for same information.

Thanks Ryan. I am interested about other possible side-effects of going that route. Do you think it affects performance badly since we are looping all the pages in every request? I think that the inconsistency with limit is fine, couldn't think scenario where that would be required and ua limited. I am currently working on this.

There is no credit cards or paypal payment method yet. But each payment method is just an additional module, so it is pretty simple to implement. This file should help you to get started: https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentExample.module Let me know if you need any help.

Those should be automatic, like this $page->temp = "hello"; echo $page->temp;

Pete - I think we should have a POLL!

Ryan, started to implement this as a full module that switches template based permissions to page based. I have only made few modifications, but it already seems to be working rather nicely! What I couldn't figure out is how to make pageList view to disable pages that aren't viewable for current user? This is the code I have now: /** * Add the hook * */ public function init() { $this->addHookAfter("Page::viewable", $this, 'viewable'); $this->addHookAfter('Page::editable', $this, 'editable'); } /** * Hook called after Page::viewable is called * */ public function viewable(HookEvent $event) { // get the vars we need to check access $page = $event->object; $user = $this->user; // no need to check anything if it's the superuser if($user->isSuperuser()) return; // don't allow this access control on system templates if($page->template->flags & Template::flagSystem) return; // get the roles we'll be comparing $pageRoles = $page->view_roles; $userRoles = $this->user->roles; // if page has a 'view_roles' field, but none defined, then inherit 'viewable' state from parent if(!count($pageRoles)) { // determine access from page's parent, recursively $event->return = $page->parent->viewable(); return; } // we assume it's not viewable until we can prove otherwise $viewable = false; // loop through the pageRoles and try to match up to user // we don't need to check permissions in the role because // all roles are assumed to have page-view permission. foreach($pageRoles as $role) { if($role->name == 'guest' || $user->hasRole($role)) { // guest role was found or the user has the required role $viewable = true; break; } } $event->return = $viewable; } public function editable(HookEvent $event) { // get the vars we need to check access $page = $event->object; $user = $this->user; // no need to check anything if it's the superuser if($user->isSuperuser()) return; // don't allow this access control on system templates if($page->template->flags & Template::flagSystem) return; // get the roles we'll be comparing $pageRoles = $page->edit_roles; $userRoles = $this->user->roles; // if page has a 'edit_roles' field, but none defined, then inherit 'editable' state from template or parent if(!count($pageRoles)) { $event->return = $page->parent->editable(); return; } // we assume it's not viewable until we can prove otherwise $editable = false; // loop through the pageRoles and try to match up to user // we don't need to check permissions in the role because // all roles are assumed to have page-view / page-edit permission. => actually we should disallow selecting other than roles which have page-edit in first place foreach($pageRoles as $role) { if($role->name == 'guest' || $user->hasRole($role)) { // guest role was found or the user has the required role $editable = true; break; } } // master role for client (would be the only one to edit view_roles and edit_roles fields. if ($user->hasRole("master")) $editable = true; $event->return = $editable; } Above assumes that view_roles and edit_roles are global, so there should never be need to check access from templates. I need to add one more field for "add children" permission. Also a lot of tweaking and testing ahead, but so far it looks very good and doesn't feel "hacky" at all. Also I am thinking about building a process page which shows all the pages that have defined edit / view roles, so one would not need to browse all the page tree to find the locks...

Ryan, for some reason I have missed this before. I ended up solving my problem back then by doing 5 separate templates. But now I have similar situation, but this time with 15 sections - so I will definitely take your module as an starting point, thanks!

I vote for disabling the smileys also! I have had to disable them more than once because a) I like to use lists b) like these c) and evil smileys ruin them!

Gotta agree with Nico. That is pretty great looking portfolio!

Thomas, I just today implemented something similar and remembered the logic from your post. Simple and great solution. I made few modifications - most notably I save the related pages into page field also. I also run this code only once per page, since this is part of the import script. Here is how I modified your code: foreach($page->tags as $tag) { $related_pages = $pages->find("template=article, tags=$tag"); foreach($related_pages as $related) { if($related->id != $page->id) $related_id[$related->id]++; } } arsort($related_id); // We limit it to three related pages at max $related_id = array_slice($related_id, 0, 3, true); foreach($related_id as $key => $val){ $rp = $pages->get($key); $page->related_articles->add($rp); }

Pete: handy also if you are planning to throw lots of money to Google for paid visitors. You do want to get best possible conversion then.

I tried to replicate this myself today with same install and couldn't do it. I am pretty sure I wasn't dreaming when I got this, but it seems to been one time problem. I'll report if I find a way to replicate this.

Looking from my phone (HTC one X) and it looks great. Nice work at least for mobile surfers!