Hani

Ah ha! Thanks guys! This is fantastic and really helps me to make better modules with better integration. Thanks, again.

I'd like to add some functions to $user. For example I'd like to be able to do the following: $user->sendThankYou(); I tried creating the following module: class UserExtended extends User implements Module{ public static function getModuleInfo() { return array( 'title' => 'Extended User Module', 'version' => 100, 'summary' => 'Extends Processwire\'s Core User Module', 'singular' => true, 'autoload' => true ); } public function sendThankYou() { // Do something } } But I get the following error: Class UserExtended contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Module::init) (line 18 of /home/hani/public_html/site/modules/UserExtended.module) At that point, I thought, "Of course. "User" isn't a really a module. It's not in the Modules list. It extends Page." I'd really appreciate any direction on how to do this.

Yup - $featuredTag returned just fine. It was a mistake in my code in a loop below it. Silly me.

D'oh! Totally my mistake. Had something else wrong with my code. Ryan - can we delete this topic?

What selector string should I use to return pages that have a specific page selected in a Page Fieldtype input? I searched around and tried multiple things, but couldn't find the answer. I really figured this should be easy, so I may totally be overlooking something. I have pages that can have any number of tags selected (through a Page Fieldtype input). I would like to return a PageArray of pages that have the "Featured" tag selected. (It doesn't have to be the ONLY tag selected.) I attempt to do that with the following code, but it is returning all the pages. $featuredTag = $pages->get('template=tag, title=Featured'); $featuredPages = $page->children("tags=$featuredTag"); Any idea what I'm doing wrong? Am I totally missing something? (A little more info, I am using checkboxes to select the tags in the Page Fieldtype input.)

Great idea, Ryan! Even better than my static fix! Thanks!

Okay - cool. Thanks, Ryan!

Ok, duh. I just have to use $sanitizer->pageName() instead. But the $sanitizer->username() function should behave just like $sanitizer->pageName(), no?

Thanks for this module, Ryan! For anyone using this module and has recurring events on their calendars, you're going to want to add one line of code to the makeCalendar() function if it isn't behaving as you expect. (Recurring events' behavior is wonky in the sorted order. I didn't look too hard to find a pattern.) Anyway, right before the following line: $url = rtrim($url, '?&'); Add the following: $url .= 'singleevents=true&'; This will render recurring events as single events in the XML feed. Come to think of it, It may be good to make this change in the module anyway since it doesn't have any negative effects on single events.

Using the $sanitizer->username() function on an email address returns the email address as is. This behavior is expected and correct according to the function's definition (in the cheat sheet), which is: However, when adding a user manually in PW, the name field shows a different formatting requirement: So inputting email@domain.com into that field automatically changes it to email-domain.com. (The "." does in fact stay in there although its not part of the defined character requirement. No biggie.) Shouldn't those two formats match? Background info: The reason this came up is because I'm allowing folks to signup for my parish's website to access parishioner-only content on the site. However, instead of usernames, I'm relying on email addresses for registering and logging in (at least from their point of view). Since each user in PW requires a username, I'm making their username a sanitized version of their email address and was going to use the $sanitizer->username() function to automatically create their username based on their email address. But given the current sanitizing convention of $sanitizer->username(), I'll have to create a new sanitation function to accommodate. Is there a reason for the discrepancy that I may have overlooked?

Marty - do you happen to have the HelperFieldLinks module installed? If so, the problem might be something with this part of the module's css. .ui-widget-content{ overflow:hidden; /*clear floats*/ } If you do have it installed, you can comment that out. I don't think there's a significant problem doing that. From what I saw, the helper link to the field/template that appears below the field simply doesn't have the proper spacing below it.

Ooooooh! Got it! I feel like that's a great way to go since it simply builds off of ProcessWire's current functionality (of ignoring folders starting with a ".").

Just wanted to talk about this a little more to see if I understand it correctly. Since PW blocks access to any files/dirs that start with a period, it would have to change so that it blocks access to those files/dirs EXCEPT those located in the files dir. Instead, for those folders, it would to reference a pass through similarly to how I've done it. Is that what you're thinking?

You rock, Pete! Thanks for the fix and for adding functionality to allow for crops for specific templates. Totally handy!

Thanks for the feedback, guys! Really helpful. Not entirely sure what you mean, Ryan. The htaccess file that I manually placed was not in the root files folder, but rather the specific page's file folder. If I am correct (which I may not be) and it acts the way I intended it to, only files being accessed in that folder will be running through the pass through. So for instance, if my page (id #1900, for example) is only viewable by a certain role, then only those logged in with that role can access files found in /site/assets/files/1900. So with my solution, an htaccess file is required for each protected page and located under that page's file folder. So I guess that means, if I were to have 30 protected pages, I'd have 30 copies of the same htaccess file located across 30 different file folders. While its functional and "invisible", I can definitely agree that it's "messy". Cool, thanks! Love that! I think that's a great idea. I guess that's a great solution if the htaccess file is located under /site/assets/files. It seems less messy than having an htaccess file in multiple folders.

Also - like I said, I'm no htaccess guru. Does the htaccess file settings also block any indexing of the files by search engines?

The following solution seems to work for me. I'm not sure what downfalls there may be to my approach, if any; I'm not an htaccess or regex expert. My solution is a mix of htaccess (a solution raydale touched upon) and one of Ryan's suggested options (downloading through a passthrough PHP script/PW template). Firstly, the htaccess file that I manually placed into the protected page's file directory. (Example: placed into mydomain/site/assets/files/1072) IndexIgnore * Options +FollowSymlinks RewriteEngine On RewriteCond %{REQUEST_URI} ^/site/assets/files/(.*)/(.*)$ RewriteRule (.*) http://www.mydomain.com/file-download/?page=%1&file=%2 [L] Any requests for any file in that directory get redirected to my passthrough page. (A hidden PW page using the following template.) <?php // Get page that owns the file if(!$input->get->page) throw new Wire404Exception(); $page = $pages->get((int) $input->get->page); if(!$page->id) throw new Wire404Exception(); if ($page->viewable()) { // Visitor has access to the page // Build file's URL $filePath = $config->paths->files.$page.'/'.$_GET['file']; // Force download of the file header("Content-type: application/force-download"); header("Content-Transfer-Encoding: Binary"); header("Content-disposition: attachment; filename=\"".$_GET['file']."\""); readfile($filePath); } else { // Visitor does not have access to the page $redirectURL = $pages->get("/login/")->httpUrl; /** * Or alternatively, redirect to Processwire's login page if you don't have a custom login page * $redirectURL = substr($pages->get('/')->httpUrl, 0, -1).$config->urls->admin; */ $session->redirect($redirectURL, false); } ?> The template checks to see if the page is viewable to the site visitor. If so, it forces the download of the file. If the user does not have page view access, it forwards them to a login page. It seems to work really well for me. Thoughts? Does anyone see any downfalls? At some point, the creation of the htaccess file can be automated based on the template's access settings. (One standing, though non-critical, question I have is, why does $config->urls->root always return a forward slash for me?)

Hey Antti - I just tried creating a CropImage field on the latest version of PW (2.2) and while the field shows up, the "Crop Setups" section (under the field where you can preview and define the crop area for the image) does not show up. Basically, it looks like a standard image field on the edit page. I tried the following code in my template anyway: echo $page->my_photo->eq(0)->getThumb('thumbnail'); And I get the following error: Error Exception: Method Pageimage::eq does not exist or is not callable in this context Any ideas? Anyone else had the same problem with this module in the latest version of PW?

Thanks for the feedback guys! Ryan - you bring up a great point that this fieldtype results in non-relational data being stored in the database. This could potentially cause problems for people down the road - so I am really glad you brought it up (I failed to mention it). But your point that some folks may be okay with that drawback because they're running smaller-scale websites. For large scale usage, I would agree with you that the Page fieldtype is the way to go. Also, thanks for the code tips! I've implemented those changes (with a few tweaks because of the additional functionality suggested by Adam). Adam - adding value/label pairs was actually something I thought about. But for my immediate needs, I decided to skip it. However, I decided to take a stab at it right now and found that for some reason, the data isn't being saved to the database for that field. I've attached the updated module. Ryan - do you have any idea why it isn't saving the selected option to the database? I dived into the code (processInput, savePageField, etc.) but couldn't seem to find out what was going on. (No rush on this issue for me - whenever you get some time.) Thanks, guys! EDIT: Removed the attachment. Module is on github. Link in first post.

Just wanted to let you guys know that I created a plugin that creates a Select/Drop Down field with configurable options. Check it out here: http://processwire.com/talk/index.php/topic,245.0.html (I personally feel it is much more direct than creating pages for each of the items - in your case, categories - that you want in your drop down list.)

Here is a fieldtype that creates a drop down list of the US States from which to select. Hope it is of use to someone! Let me know if you experience any issues with it. Note: I was considering extending the last plugin I created (FieldtypeSelect) but decided to simply extend FieldType (in PW's core) so that it wouldn't be necessary to have the FieldtypeSelect module installed as well. FieldtypeUSStateSelect.module

I noticed that although there's an InputfieldSelect module, there wasn't a FieldtypeSelect that would produce a drop down list (via a "select" input) that would allow you to define a list of options in the field's configuration. (Somewhere in this forum, I saw that the "Page" fieldtype was suggested to do this - and it works - but it didn't seem as easy as it should be.) So, I went ahead and created a module to do it! After installing, you'll have a new "Select" fieldtype that will allow you to define the items you'd like in the drop down. You'll be able to define these options in a text box on the field's configuration screen. Just put each option on it's own line. Hope this helps someone out! Let me know if you experience any issues with it, find any bugs or if you have some ideas on improvement. EDIT: The module is now on github: https://github.com/Hani79/Processwire_FieldType_Select_Drop_Down (Thanks for the prompt to put it up there, Soma.)

Oops! I'm probably missing something critical in the instructions. I've got a busy few days ahead of me. After I get through them, I'll go through and set this up on a clean PW install documenting the entire procedure - and include any necessary templates. Sorry for the confusion!

I got really swamped, so it took me a while to finish this up. I went ahead and finished it the way I was doing it (multiple pages) due to my lack of time and since it was pretty much done - but I love the idea of having it all attached to a single page. When I get some time, I'm going to rework this so it uses one page instead of separate pages to list, add, and edit videos. For anyone interested in this, attached is what I came up with. The rundown to use this as-is: Put the contents of the attached zip file under modules Install all 4 modules Create a new template called "video" with all the fields you want. Add a page under the Admin section and have it run the ProcessVideoList module (also set the default child template to be "video" Add two pages under the other page you created - running either the ProcessVideoAdd and ProcessVideoEdit modules All of them use the admin template Enable page numbers for the admin template (for pagination in ProcessVideoList) I think that's it! Don't hesitate to drop me a note if you have questions about any of this! Also, when I get some time soon, I'll actually go through the code and add comments. I know, I know - I should have done it as I went. Bad developer! Bad boy! VideoLibrary.zip

So I took some time and digested everything you said. You indicated many drawbacks (that I wasn't aware of) concerning the method I was trying to acheive my goal. One of the things you said was really simple, but it redirected the approach I was taking. That second sentence really stuck. Since that is what pages were designed for, why would I want to extend the WireSaveableItems class? I SHOULD have each of the videos be a page. But I really would like to be able to view the videos out of the Pages hierarchy and be able to add them under a seperate section in the admin console. It would make sense, then, to extend the classes that are more appropriate: ProcessPageAdd and Process. (ProcessPageEdit and ProcessPageList both extend the Process class.) By doing that I can add a new pages under Admin that execute my ProcessVideoAdd, ProcessVideoEdit, and ProcessVideoList modules. (Actually, I don't know if you would classify them as modules since they're class extensions? But I was able to integrate them just like modules.) And guess what? It worked out so well to do that! Using those class extension/modules, markup for the list, and a "video" page template - I was able to get it working beautifully! But now with the benefit that all the videos also show up in the site's hierarchy. (Not that it has a direct benefit in how videos are managed - but a bonus that it jives with PW's architecture.) I have more work to do on the ProcessVideoList module to enable pagination and filters - and I'm hoping to get to that later this evening or tomorrow. After I do that, I'll post my work so you can check it out - and it may help someone else that's trying to do something similar. I probably sound like a broken record every time I say, "thank you". So I'll just tell you that you rock! This is actually working out a lot better than I thought it would - it doesn't seem so "hackish" now!