Leaderboard

This module -- actually pair of modules -- keeps track of login attempts to your site, both successful and unsuccessful. The point of this is to give you better understanding about users' activity and environments they use and favor; browsers, browser features such as Flash and Javascript, devices, screen and window sizes. Based on my experience it could also prove out to be rather helpful when debugging error reports by users. Since most of this module was written during one weekend (short time for someone like me who way too often gets stuck trying to make meaningless little details "perfect") I'm very much aware that there are still quirks and even missing features I'd consider "very important." If anyone finds this module interesting enough to give it a try, any and all ideas, comments and problem reports would be very much appreciated! http://modules.proce...-login-history/ https://github.com/t...essLoginHistory How does it work? Process Login History itself is pretty simple and focuses on showing logged data. Probably only thing worth mentioning is that user agent strings are saved to database in their original format and converted here run-time into human readable values. Currently this is done with a private function that tries to identify most common platforms, device types and browsers, but I've planned to add support to either phpbrowscap and/or PHP's native get_browser(). Login tracking is achieved by hooking after Session::login and ProcessLogin::buildLoginForm, though latter is only used to add some extra fields to login form in order to collect slightly more information about user agent. Hooks are added by separate autoload module Process Login History Hooks to avoid loading unnecessary stuff all the time. I'm not sure if this naming convention is correct though.. it's not a process module but still very much related to one -- ideas, anyone? How do you use it? When installed this module adds new database table (process_login_history) for storing data and new page called Login History under Admin > Setup. What this page should look after couple of logins / login attempts is visible in the screenshot below. For more information and some ideas I've planned for later revisions, see README.md.

Greetings, Aha...Yes! That solved it. Now that you turned my attention to that section of the .htaccess file, I see it states that there might be problems with "temporary" sites with a "~" in the URL. Hey, while I was there I corrected a typo om line 70: changed "aern't" to "aren't"! See, I'm being helpful already (sarcasm on). Thank you for the quick help everybody! Matthew EDIT: I just voted for ProcessWire at the Critics Choice CMS Awards. Even just what I have seen in recent days tells me I have found the right thing. Don't know how I went this long without knowing about ProcessWire.

Btw, I just now added a replace() method to WireArray so that we'll have the above contained in 1 function for PW 2.3

Ajax Search 1.1.0 There was a request for a ajax live search. So I went and created a simple module. Added in 1.1.0 * added key support for browsing results with arrow down and up. * added escape key to close results. * added close results on click outside http://modules.proce...es/ajax-search/ From the readme: This module progressively enhances the search form to an ajax live search. It will perform a search like you would use the form normally, and returns the output of the search page. So the search will still work without js enabled. There's some basic styling attached to this module in the "styling-example". You can use it to get started. See readme in there. Setup the search.php So it works almost out of the box with the basic install profile of ProcessWire, you only need make a minor change to the search.php template file to only return the content part (results) on a ajax request. To get the ajax search only return the content, open search.php and change the output on the bottom to this: ... if(!$config->ajax) include("./head.inc"); echo $out; if(!$config->ajax) include("./foot.inc"); Module Settings It comes with some module options to define various settings regarding the search form. Following a list with the defaults. Minium length = 3 min length for starting ajax request Close button text = 'close' close button text ID of searchform = #search_form if you have a different search form id,class ID of input = #search_query if you have a different search input id,class Query name = 'q' this is the default param name as_query_url = '' if left blank the script will take the action of the form Any help testing this module is appreciated. If you have any questions or problems setting this up feel free to ask here. Also feel free to use this as a starting point for your own, or take out the script to implement it differently. It's quite simple and can be adapted really quickly.

Perhaps even better: /** * Select random pages from a PageArray * * If no $seed is provided, today's date is used to seed the random number * generator, so you can use this function to rotate items on a daily basis. * * @param PageArray $pages the list of Page object to select from * @param int $amount the amount of items to extract from the given list * @param int|string $seed a number used to see the random number generator; or a string compatible with date() */ public function randomPages(PageArray $pages, $amount=1, $seed='Ymd') { if (is_string($seed)) { $seed = crc32(date($seed)); } srand($seed); $keys = $pages->getKeys(); $selected = new PageArray(); while (count($keys) > 0 && count($selected) < $amount) { $index = rand(0, count($keys)-1); $key = $keys[$index]; $selected->add($pages[$key]); array_splice($keys, $index, 1); } return $selected; } Now you can seed with a date()-compatible string, so you can rotate weekly (for example) using "YW", or monthly using "Ym", etc.

Your if() statements will always execute since a PageArray (returned by find) would never resolve to false. The find() could be replaced with a get(), assuming there is only one page with template=student per student. Also there are some out of scope variables, and what looks to be unnecessary foreach() loops. Lastly, the 'name' could use sanitization. I rewrite it like this: if($input->post->submit) foreach($input->post->delete as $s) { $name = wire('sanitizer')->pageName($s); if(!$name || $name !== $s) continue; $dp = $pages->get("template=student, name=$name"); $du = $users->get($name); foreach(array($dp, $du) as $item) { if(!$item->id) continue; $pages->delete($item); echo "<p>$item->path has been deleted!</p>"; } }

Hi Matthew & welcome to the forum. Looks like apeisa got there with a suggestion first so I'll just add: here is some additional reading on the matter.

It probably requires RewriteBase to be set. See this line and comment above it: https://github.com/ryancramerdesign/ProcessWire/blob/master/htaccess.txt#L76 So edit your .htaccess and add this line on line 77: RewriteBase /~racc/

Hi and welcome! First thing would be checking if you have mod_rewrite enabled, but if you didn't get that error during the install, it must be. Second thing would be changing the Apache directive AllowOverride from None to All http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride. The file where you have to do this depends on the operative system.

have a good night sleep and look at my code again tomorrow

ProcessWire modules are by nature meant to save time. There are 3 modules that I think can be big time savers on almost every project: The MarkupPagerNav module included with ProcessWire is hard to imagine being without. Yet, I was doing pagination without this for a long time before making it, and... things get done a lot quicker now. The MarkupSimpleNavigation module can be a big time saver when it comes to many common navigation scenarios. The FormBuilder module is a big time saver when it comes to creating forms. It's turned the most annoying and consuming part of development (for me at least) into one of the quickest and easiest. When it comes to front-end development, I'll admit that I've always preferred starting from scratch. But lately I've been enjoying what some of the CSS frameworks like Skeleton, Foundation and HTML Kickstart bring to the plate (and Twitter Bootstrap I'm guessing, but have not used it). With the appropriate project, these are huge time savers. The project I'm working on now (for a boarding school) needed to be responsive and very unique in design, and I found Skeleton to be the perfect balance there. It provides just enough to make things responsive, and very little else. That left little room for the design to be influenced by the framework (which was desirable in this case). If I didn't need responsive on a particular project, and could let the design benefit from some framework influence, I'd go straight to HTML Kickstart as the biggest time saving framework. Lastly, I'd say that using the Basic Profile as a starting point has always been a big time saver for me. Almost every site I build needs the core framework of fields and templates included with the basic profile. While all the markup and CSS ultimately get replaced, it saves a lot of time having these things there ready to implement.

The main reason why name isn't on the content tab by default is because you could be breaking links (internal or external) every time you change it. It's one of those things that ideally should never change after its been created. But if you do expect changes, I suggest installing the Page Path History module, which will keep track of those changes and setup 301 redirects.

I sometimes use CSV import module to create lots of pages from one list or names or titles. It's very handy and even can import images or files from an old website.

This is not specific to PW projects, I would use the same approach or techniques for plain HTML sites or projects with a blog system. This is because I always start with an HTML prototype which later is converted into a PW template. I actually have … well, I wouldn't call it a framework, but a “starting point”, a boilerplate. This is derived from the HTML5 Boilerplate and combined with some basic CSS and JS stuff. Just some reliable CSS (see later) snippets and jQuery plugins I use often or all the time. Having (and knowing) that helps a lot, but beware - it can result in repeating yourself in your designs. I also have a (small, but growing) collection of PW snippets, most of them stripped from the default page profile or used in projects. (Also saves me having to look it up in the forum again.) Two other things which have really helped me to save time … well, it's not so much about actually saving time, but more about saving nerves by not having to manually do things … anyway, it's using a CSS preprocessor (I prefer Sass/Compass, but I honestly think it doesn't make a big difference if you prefer LESS or Stylus) and a build process to automate things (I have recently switched to a Grunt-based build system, but other build scripts should work just as good) like combine/minify CSS/JS, optimize images etc.

There's also a textformatter for the Textile lightweight markup system if you'd prefer

Actually there is. http://modules.processwire.com/categories/textformatter/

Hey Antti, Not a theme (yet) - just a few CSS tweaks I made. Nico has seen it and keeps encouraging me to make a theme out of it.

Hi Michael, I have not seen any fields like that, but as an alternative you could try using a "page" type field. It would create a new page for each tag, but has a nice friendly interface for the user to manage them. 1. Add a new page in your tree called "Tags Collection", and make it hidden. 2. Create a new field called Tags and make it a "page" type. 3. On the input field settings, make the "Parent of selectable page(s)" the Tags Collection page 4. For the "Input field type" try one of : Select Multiple, asmSelect or PageListSelectMultiple (I prefer the asmSelect) 5. Check the “Allow new pages to be created from field?” to allow the user to easily add new tags directly from the field