Leaderboard

I've just posted a Fieldtype and Inputfield module combination that support the use of MySQL time fields in ProcessWire. Ryan's Datetime module is great but I needed something that dealt specifically with times for a scheduling system and this is one of the results. For 24 hour clock format ('HH24MM') you now get a clock-picker pop-up by default... ...but you can inhibit it if you don't want it... Although the input time format is selectable, as this is stored as a MySQL time field, you currently need to specify values in selectors in full "H:MM:SS" format. So if you wanted to get all events starting on or after 9am you'd do something like this... $events = $pages->find("template=events, starts>=9:00:00")->sort("starts"); This is definitely a beta module as I've not tested every single input format yet. Currently does not support negative time-periods or fractions of a second. FieldtypeTime on Github FieldtypeTime in the Module Repository Releases Version 0.2.0: Adds support for the use of this input field in repeaters and repeater matrix types. Version 0.1.0: Adds clock picker.

Hi David, I'd be glad to take care of AIOM. I'm coming from the South of Germany. I work together with @phil at Conclurer, a web development company. If you want to, I can send you my personal mail address so that we can talk about AIOM. Thanks in advance, Marvin

A proof concept of a preloader module with the function .load() Github

We have created an LDAP module for PW that supports mapping groups, setting the base dn and storing the e-mail address of the user (for an example). It also has an "Active Directory" -mode. I don't think Marvin's current code works with every AD-instance since it's missing a couple of ldap_set_option() calls that are needed for some. The only reason we haven't released it earlier is that we wouldn't have the time to maintain it. @Marvin: If you want to take a look at the code I can post it on Github and throw you a link. You could always implement all the stuff by yourself as well, I would understand

Those are a couple of good questions - with the new core upgrade module I've started setting the dirs on my development boxes as 777 just to allow easy updates as the dev branch gets commits but I won't be doing that on production machines. I wrote the rule about making the site folder unwriteable by the webserver process in case someone managed to craft an attack against PW that tried to write to the file system; I'd prefer that such an injection/scripting attack - if found - would not be able to write to the disk. So that's definitely a me thing rather than an official PW rule. To try and anwser your question about how to set it - well, it depends on a few things... Going with 0550 means the owning user (the first 5) gets read and traversal rights, the next 5 means users in the owning group get read and traversal rights and the final 0 means other users get no rights. This is the most secure setting but requires that the user the webserver process runs as be either the owning user or a member of the owning group. Going with 0750 (owning user can write to the tree) would be better if the owning user were different from the webserver user and if the webserver user were a member of the owning group. Going with 0755 (owning user can write the tree and any user can read & traverse) would be the one to go for if the owning user were different from the webserver user and if the webserver user were not a member of the owning group. In this respect, this option is the most universally applicable but it allows anyone on the box the right to read and traverse into your file structure and, on a shared host this is a security risk as they can then possibly do things like read your config file - with your DB access credentials in it - if that has read permissions for other users too! If you are on a VPS with no shared accounts - then this setting is fine. To find out the user and group ownership you'd do an "ls -l" from a linux command line and it should show you the owning user and group names. The diagnostic module works by checking if the directory is writeable by the user the webserver process is running as; it doesn't try to analyse or recommend how to fix it (if I remember correctly.)

Hey guys, sorry for the late feedback. I currently have so much with my company around the ears and stuck in large projects that I currently have no time to maintain AIOM+. I'm sorry. The project will continue to maintain. Did any of you like to take care of to AIOM+? At best a German developer. Then I give him on Github access to the Repositority. Dave

@Peter This might not be exactly what you want but I think you can get a long way towards making things easy using PWs existing per-template label feature for fields. Just edit your Staff Directory template and locate the "title" field in the list of fields and click on the word "title" to bring up the per-template field config sttings editor. You can now change the label for the title field from "Title" to "Full Name" and save that and the template you should now be able to use the title field and it will be displayed as "Full Name" on every page you edit or add. In effect you can re-purpose the title field and remove the need for a separate full_name field. I know that might not be 100% of what you are after but it goes a long way toward it.

The previous advice you gave about checking plugs was on the money, in the sense that it paid to go back to the beginning and step it through. It was caused by the images. Two things compounding. One, I had for some reason uploaded very large images, something I normally never do, but if I remember, I was checking pim and forgot to go back and optimise afterwards. Also, that was compounded by me not using pim properly and stating the quality. I also have a feeling (may be wrong) that the image was being resized every time as opposed to the cache being used. But can't be sure about that. It may have just been the sheer load on the page. I have reverted to previous practice and optimised the images first. Quick with imagemagick and everything appears to be sorted. So with your help, Joss, and Soma's I have managed to swirl back up and out of the rabbit hole I got myself into. Thanks once again. By the way, I reverted to just using size() as well.

Well, the only place I can really think of is from your config.php file - but in that case you might as well just put your spl_autoload_register() directly in there. Should be safe from core upgrades too.

Hi @Gazley, have you tried a before hook on session::init() ?

Remember that you can use more than just one Process module and admin pages hierarchically in the admin. Don't limit yourself to one module or admin page. Also each admin page (nested maybe) can have the same process module attached. Not sure if that would be helpful at all but it's very well possible. I see what you mean with the routes and how they can be used in a REST-like structure. I think if you try to rebuild those you're left with trying urlSegments, but maybe not. I would suggest to try and experiment some time before you deciding on something. Up to you. I mean adding or editing a page can be something like using the ProcessPageEdit and ProcessPageAdd in your module. As you said it's just pages and templates and fields, you already have the - and can extend the crud, and you can use what is there or build completely your own things. Everything fits nicely together with admin modules, Pages, Templates, Fieldtypes and Inputfields. It took some time to get into, but I'm maybe not the best person to advocate all this. Lister and Lister Pro is something that may be of interest for you also, cause it can build Admin pages simply by entering a Name in the module settings and click "add". It will generate a new Lister admin page, that can list pages/entries with the InputfieldSelector field type Ryan built, that let's you build filters/selectors for what to list, you then can edit or add pages etc, run actions (also add your own action modules you can build and extend on) on the results. It's what is new in PW 2.5 and the light version is now in Users and Admin page search. The pro version might also be available soon. It seems all to go very far and is complex, but also shows what's possible. I would try to study some process modules in core and what Ryan have built. But feel free to try implement your way of working, just keep in mind that maybe with a more PW way you also can ensure it will be more "compatible", if that's really an issue. Ryan said once Process modules are just mini apps inside PW, and they can be verstaile and modular. I'm not sure Ryan was ever into REST-like routing, as it's also not something that is an absolute best way.

Hi! Just finished my first module This module adds a new "Google-Analytics" Page in your Admin-Panel and displays various Statistics from a Google Analytics Account. It uses the JQuery plugin "jqplot" to display the charts. Github: https://github.com/w...GoogleAnalytics Modules directory: http://modules.proce...ogle-analytics/ Features Visits by Date (Chart) General Statistics about Visits (Total visits, Visit duration, New visitors, Returning visitors etc.) Demographics: Countries, Cities, Languages System: Browsers, Operating Systems, Screen Resolutions Mobile: Operating Systems, Screen Resolutions Pageviews by Date (Chart) Top Content Traffic Sources: Keywords, Referral Traffic by Domain and URI Choose a default date range displaying statistics: last 24 hours, 2 days, 1 week, 1 month etc. Custom date range by setting a "start date" and "end date" Requirements Google Account and Analytics Account A Project in the Google APIs Console cURL Installation 1) Create a Project in the Google APIs Console: Create a new Project in the APIs Console: code.google.com/apis/console/ Under Services, enable the Analytics API Under API Access: create an Oauth 2.0 Client-ID Give a Product Name, choose "Web-Application", Domain doesn't matter Enter a Redirect URI to the GA-Page in your Processwire Installation: http://yourdomain.com/processwire/google-analytics/ Notes: The redirect URI must exactly match with the URL from the new "Google Analytics" page in Processwire. Open the Page and copy the URL from the address-bar (localhost does work too!) The project created in the APIs Console can be reused for every Processwire installation using this module. You just have to enter more redirect URIs 2) Install the module: Place the module's files in /site/modules/ProcessGoogleAnalytics Install the Module via the Admin-Panel Enter Client-ID and Client-Secret keys from the created project in the module config Load the newly created page "Google-Analytics" and click on the button "authenticate" Grant the module access to the Analytics Data Choose a Google Analytics account (Domain) from the dropdown Done: You should see the statistics. Check out the module config options for further customization In order to let other users see the Google Analytics page, you must give their role access to the "ga-view" permission. Ps. Processwire is awesome and so is this community!

This basic tutorial is primarily aimed at those new to PW. It could also serve as a reference to others more seasoned PW users. The question about how to categorise content comes up in the forums now and again. Hopefully with this post we’ll have a reference to guide us right here in the tutorials board. Many times we need to organise our site content into various categories in order to make better sense of the data or to logically and easily access it. So, how do you organise your data when you need to use categories? Here are a few tips gathered from the PW forums on how to go about this. Using these tips will, hopefully, help you avoid repeating yourself in your code and site content and keep things simple. See the links at the end of this post to some useful discussion around the topic of categorisation. Before making decisions about how to organise your site, you need to consider at least three questions: What items on my site are the main items of interest? These could be people or things (cars, plants, etc.). In most cases, these are the most important content on which all the other stuff point to. Where do items need to be grouped into categories? This is about where items need to “live”. It is about the attributes of the items of interest (e.g. responsibilities, job types, colour, etc.). Attributes can have sub-attributes (e.g. a category job type = driver could be further sub-classified as job type role = train driver). Can they live in more than one place? - This is about having multiple attributes. There could be other issues such as the type of content your main items of interest are but that’s for another post. We’ll keep these examples simple. The main principles explained below still apply. There are at least three possible ways in which you can organise your content depending on your answers to the above three questions. These are: Single category Simple multiple categories Complex multiple categories These are illustrated below. Note that this is what I call them; these are not PW terms. 1. Single Category Suppose you need to do a site for a company that’s made up of several Departments each with employees performing unique functions. These could include “Finance”; “Media Communications”; “Administration”; “Technicians”; “Human Resources”; “Logistics”. We ask ourselves the following questions based on our 3 questions above: 1. Q: What items on my site are the main items of interest? A: Employees. 2. Q: What attributes of our items of interests are we interested in? A: Departments. (Single main category) 3. Do the Departments have sub-categories? A: Yes. (Multiple sub-categories) 4.Can Employees belong to multiple sub-categories? A: No. (Single sub-category) We conclude that what we need is a Single Category model. Why? This is because, in Single Categories model, items of interest can only belong to 1 and only 1 main/parent category and within that only 1 sub-category Employees in this company can only belong to one and only one department. Finance guys do their finance and Logistics guys do their stuff. Letting Techies do press conferences is probably not going to work; that we leave to the Media guys . Assuming the company has the following employees - James, John, Mary, Ahmed, Peter, Jason, Barbara etc., arranging our site content to fit this model could look like the following: Items of interest = Employees Categories = Departments Adopting out strategy to keep it simple and logical, let us write down, hierarchically, our employee names against their departments to mimic the PW tree like this: James Finance John Finance Mary Technician Ahmed Logistics Barbara Media Etc. We notice, of course, that departments start repeating. It doesn't look like we are doing this very logically. If we think about this carefully, we will conclude that, naturally, the thing (attribute in this case) that keeps repeating should be the main criteria for our categorisation. This may seem obvious, but it is worth pointing out. Also, remember, that as per the responses to our questions, the categories (Finance, Logistics, etc.) do not have sub-categories. In this aspect, we are OK. Using this principle about repeating attributes, we find that Departments, rather than Employees, need to be the main categories. Hence, we categorise our PW site content by doing the following. Create a template for each Department. Hence, we have a template called Finance, Logistics, etc. Add the fields needed to those templates. This could be a text field for holding Employee phone numbers, email field for email, title field for their names, etc. Create top level pages for each Department and assign to them their respective templates. Give them appropriate titles, e.g., Finance, Media, etc. Create a page for each employee as a child page of the Department which they belong to. Give them appropriate titles, e.g. James, John, etc. We end up with a tree that looks like this: 1. Finance (ex. main category) a. James (ex. item of interest) b. John c. Shah d. Anne 2. Logistics (ex. main category) a. Ahmed b. Matthew c. Robert d. Cynthia 3. Media a. Barbara b. Jason c. Danita 4. Human Resources a. Michael b. Pedro c. Sally 5. Technician a. Mary b. Oswald c. Dmitri d. Osiris Since an employee can only belong to one Department, our work here is done. We can then use PW variables, e.g. $page->find, $pages->find with the appropriate selectors to find employees within a Department. This is a very basic example, of course, but you get the idea. You have the choice of creating one template file for each category template as well. I prefer the method of using one main template file (see this thread). You could do that and have all Departments use different templates but a single template file. In the template file you can include code to pull in, for example, the file “technician.inc” to display the relevant content when pages using the template “Technician” are viewed. Example code to access and show content in Single Categories model $hr = $pages->find("template=human-resources, limit 50"); foreach ($hr as $h) { echo "{$h->title}"; } But sites do not always lend themselves to this model. Many times, items of interest will need to belong to multiple categories. 2. Simple Multiple Categories Let’s say you were building a site for cars - red cars, blue cars, 2-seaters, 5-seaters, etc. Again, we ask ourselves our questions based on our initial three questions: 1. Q: What items on my site are the main items of interest? A: Cars. 2. Q: What attributes of our items of interests are we interested in? A: Colour, Number of seats, Models, Year of manufacture, Types. (Multiple categories) 3. Do these multiple attributes have sub-attributes? A: Yes. e.g., the attribute Colour has several sub-categories - red, white, green, etc. (Multiple sub-categories) 4. Can Cars have multiple sub-attributes? A: No. e.g., a yellow car cannot be a green car. (Single sub-categories) We therefore conclude that what we need is a Simple Multiple Category model. Why? This is because, in Simple Multiple Categories, items of interest can belong to multiple parent categories. However, within those parent categories, they can only belong to one sub-category. Assuming we have the following cars, manufactured between 2005 and 2008, as items of interest: Mercedes, Volvo, Ford, Subaru, Toyota, Nissan, Peugeot, Renault, Mazda, arranging our site content to fit this model could look like the following: Items of interest = Cars Categories = Model, Year, Colour, Number of seats, Type Sub Categories = Model [Prius, etc.]; Year [2005, 2006, 2007, 2008]; Colour [Red, Silver, Black, White, Green]; Number of seats [2, 5, 7]; Types [sports, SUV, MPV]. Adopting out strategy to keep it simple and logical, if we wrote down our cars names against their attributes like this: Mercedes Model-Name: Year: 2005 Colour: Silver Seats: 2-seater Type: Sports Volvo Model-Name: Year: 2007 Colour: Green Seats: 5-seater Type: SUV Ford Model-Name: Year: 2007 Colour: Red Seats: 7-seater Type: MPV Etc We notice, again, that car attributes start repeating. In order not to repeat ourselves, we want to avoid the situation where our child pages “names” keep repeating. For instance, in the above example tree, we want to avoid repeating year, colour, etc. within the tree. Of course in the frontend our output needs to look like the above where we can list our cars and their respective attributes. We just don’t need a tree that looks like this in the backend. Since we have multiple categories and sub-categories, we need to rethink our strategy for categorising our content as illustrated below. The strategy we used in the first category model will not work well here. Hence, these repeating attributes (year, colour, etc.) need to be the main criteria for our categorisation. We need to end up with a tree that looks like this: 1. Cars a. Mercedes (ex. item of interest) b. Volvo c. Ford d. Subaru e. Toyota f. Range Rover g. Peugeot h. Renault i. Mazda 2. Model (ex. main category) a. Fiesta (ex. sub-category) b. Miata c. Impreza d. Matrix e. Prius f. E-Class g. XC-90 h. Scenic i. L322 j. 505 3. Year a. 2005 b. 2006 c. 2007 (ex. sub-category) d. 2008 4. Colour a. Red b. Silver c. Black d. White e. Green 5. Number of Seats a. 2 b. 5 c. 7 6. Type a. MPV b. Sports c. SUV d. Other At the top of the tree, we have our main items of interest, Cars. They do not have to come first on top of the tree like that but it just makes sense to have them like this. Next, we have the Cars’ categories (attributes). The main categories are parent pages. Each main category has children which act as its sub-categories (cars’ sub-attributes). For instance, the main category colour has sub-categories “red”, “green”, etc. Grouping them under their main category like this makes better sense than having them dangling all over the tree as parent pages themselves. Now that we know what we want to achieve, the next question is how do we go about relating our categories and sub-categories to our main items of interest, i.e., cars? Fields come to mind. OK, yes, but what about the sub-categories (2006, red, 5-seater, etc.)? Surely, we can’t keep typing those in text fields! Of course not; this is PW. We like to simplify tasks as much as we can. What we need is a special type of field. Page Reference Fields or Page Fieldtypes add the ability to reference other pages, either single or multiple pages, within a page. For instance, we could have a Page Reference Field in the template that our Car pages use. Let’s call this “car-template”. When viewing Car pages, we would have the ability to select other pages on our site that we wish to reference, for instance, because they are related to the page we are viewing. In other cases, we could also wish to reference other pages that contain attributes/values of the page we are viewing. This is the situation with our Cars example above. Hence, the sub-categories/sub-attributes for our Cars will be pulled into our car pages using Page Reference Fields. There are two types of Page Reference Fields; single page and multiple pages. What each do is obvious from their names. Single Page Reference Fields will only reference one page at a time. Multiple Page Reference Fields will reference multiple pages. OK, let’s go back to the issue at hand. We need to categorise Cars by various attributes. Do we need to reference the main categories (Year, Type, etc.) in our Car pages? In fact, we don’t. What we need to reference are the sub-categories, i.e. 2005, red, SUV, etc. These will provide the actual attributes regarding the parent attribute of the Cars. We have said we do not wish to type these sub-categories/attributes all the time hence we use Page Reference Fields. Which type of Page Reference Field should we use? Remember that our Cars can have only one sub-category/sub-attribute. That’s our cue right there. In order to select one and only one sub-attribute per Car, we need to use the single Page Reference Field. Hence, we categorise our Cars PW site by doing the following (you may follow a different order of tasks if you wish). Create a template to be used by the Car pages. Give it a name such as car-template Create a page for each of your cars and make them use the car-template Create one template to be used by all the main attribute/categories and their children (the sub-categories). We do not need a template for each of the categories/sub-categories. I name my template “car-attributes” Of course you can name yours differently if you wish. Add the fields needed to this template. You don’t need anything other than a title field for each actually. Create top level pages for each main category and assign to them the template car-attributes. As before, give your pages meaningful titles. Do the same respectively for their child pages. E.g., you should have the following child pages under the parent “Year” - 2005, 2006, 2007 and 2008. Create the Page Reference Fields for each of your main categories/parent attributes. Using our example, you should end up with 5 Page Reference Fields (model, year, colour, seats and type). Each of these should be single Page Reference Fields. It’s a good idea, under the BASICS settings while editing the fields, to include some Description text to, include additional info about the field, e.g. instructions. In addition, you don’t want any page that doesn't belong to a particular attribute to be selectable using any of the Page Reference Fields. For instance, when referencing the year a car was manufactured, we want to be able to only select children of the page Year since that is where the year sub-categories are. We do not want to be able to select children of Colour (red, green, etc.) as the year a car was manufactured! How do we go about this? PW makes this very easy. Once you have created your Page Reference Fields, while still in the editing field mode, look under the settings INPUT. The fourth option down that page is “Selectable Pages”. Its first child option is “Parent of selectable page(s)”. Where it says “Select the parent of the pages that are selectable” click on change to change the parent. By now you know where I am going with this. For the Page Reference Field named Year, choose the page “Year” as the parent whose children will be selectable when using that Page Reference Field to select pages. Similarly, do this for the remaining 4 Page Reference Fields. Note that under this field settings INPUT you can change how you want your pages to be selectable. Be careful that you only select the types that match single Page Reference Fields, i.e. the ones WITHOUT *. For single Page Reference Fields, you have the choices:Select - a drop down select Radio buttons PageListSelect Now edit the car-template to add all 5 of your Car Page Reference Fields. We are now ready to roll. Go ahead and edit your Car pages. In each of them you will see your 5 Page Reference Fields. If you followed the instructions correctly, each of them should only have the relevant child pages/sub-attributes as selectable. Do your edits - select year when car was manufactured, its colour, type, number of seats, etc. and hit Save. By the way, note that Page Reference Fields give you access to all the fields and properties of the page being referenced! You have access to the referenced page’s title, name, path, children, template name, page reference fields, etc. This is really useful when creating complex sites. I call it going down the rabbit hole! These properties of the referenced page are available to you on request. It does mean that you will have to specifically echo out the property you want from that page. Page Reference Fields are echoed out like any other field. Example code to access and show content in Simple Multiple Categories model $cars = $pages->find("template=car-template, limit=10, colour=red, year=2006, seats=5"); foreach ($cars as $car) { echo $car->title; echo $car->year; echo $car->colour; } I have made the above verbose so you can easily follow what I'm trying to achieve. The above code will find 10 red 5-seater cars manufactured in 2006. Remember, colour, year and seats are the names of your custom Page Reference Fields that you created earlier. Some sites will have content that belong to multiple categories and multiple sub-categories. We address this below. 3. Complex Multiple Categories Suppose you are developing a site for a school. The school has teachers (duh!) some of whom teach more than one subject. Besides their classroom duties, some teachers are active in various clubs. On the administration side, some teachers are involved in various committees. You know the drill by now. Let’s deal with our basic questions. 1. Q: What items on my site are the main items of interest? A: Teachers. 2. Q: What attributes of our items of interest are we interested in? A: Subjects, Administration, Clubs (Multiple categories) 3. Do these multiple attributes have sub-attributes? A: Yes. e.g., the attribute Subjects has several sub-categories - History, Maths, Chemistry, Physics, Geography, English, etc. (Multiple sub-categories) 4. Can Teachers have multiple sub-attributes? A: Yes. e.g., a Teacher who teaches both maths and chemistry (Multiple sub-categories) Apart from the response to the final question, the other responses are identical to our previous model, i.e. the Simple Multiple Categories. We already know how to deal with multiple categories so we’ll skip some of the steps we followed in the previous example. Since our items of interest (Teachers) can belong to more than one sub-category, we conclude that what we need is a Complex Multiple Category model. In Complex Multiple Categories, items of interest can belong to multiple parent categories and multiple sub-categories both within and without main/parent categories. By now we should know what will be the main criteria for our categorisation. We need to end up with a tree that looks like this: 1. Teachers a. Mr Smith (ex. item of interest) b. Mrs Wesley c. Ms Rodriguez d. Mr Peres e. Mr Jane f. Mrs Potter g. Ms Graham h. Mrs Basket i. Dr Cooper 2. Subjects (ex. main category) a. History (ex. sub-category) b. Maths c. English d. Physics e. Chemistry f. Geography g. Religion h. Biology i. French j. Music 3. Clubs a. Basketball b. Debate c. Football d. Scouts e. Sailing f. Writing 4. Administration a. Discipline b. Counselling c. Exams board d. Public relations e. Education We are ready to build our site. Which type of Page Reference Field should we use? Remember that our Teachers can teach more than one subject and can be involved in various sub-category activities. That’s our cue right there. In order to select multiple attributes/categories, we of course go for the multiple Page Reference Field. Similar to the previous example, create necessary templates and fields for the site. For our multiple Page Reference Fields, remember to select the correct input field types. These should match multiple Page Reference Fields and are marked with *. For multiple Page Reference Fields, the available choices are: Select Multiple* AsmSelect* Checkboxes* PageListSelectMultiple* PageAutoComplete* Remember to add the multiple Page Reference Fields to the Teachers template. Go ahead and test different selectors, e.g. find Teachers that teach Maths and Chemistry and are involved in the Writing club. Whether you get results or not depends on whether there is actually that combination. An important point to remember is that your multiple Page Reference Fields will return an array of pages. You will need to traverse them using foreach (or similar). Example code Complex Multiple Categories model Find the subjects taught by the Teacher whose page we are currently viewing. You can use if statements to only show results if a result is found. In this case, of course we expect a result to be found; if a Teacher doesn't teach any subject, he/she has no business teaching! subjects is the name of one of your custom Multiple Page Reference Fields. echo "<ul>"; foreach ($page->subjects as $x) { echo "<li>{$x->title}</li>"; } echo "</ul>"; There will be situations where you will need to use both Single and Multiple Page Reference Fields (independently, of course). For instance, in our Teachers example, we might be interested in the Gender of the Teacher. That would require a Single Page Reference Field. Summary What we have learnt: Categorising our site content need not be a nightmare if we carefully think it through. Of course not all sites will fit neatly into the 3 models discussed. By providing answers to a few simple key questions, we will be able to quickly arrive at a decision on how to categorise our content. There are at least 3 models we can adopt to categorise our content - single category; simple multiple category; and complex multiple category. In the latter two models, we make full use of PW’s powerful Page Reference Fields to mimic a relational database enabling us to roll out complex sites fast and easy. Useful links: http://processwire.com/talk/topic/3553-handling-categories-on-a-product-catalogue/ http://processwire.com/videos/create-new-page-references/ http://processwire.com/videos/page-fieldtype/ http://processwire.com/talk/topic/1041-raydale-multimedia-a-case-study/ http://processwire.com/talk/topic/683-page-content-within-another-page/ http://processwire.com/talk/topic/2780-displaying-products-category-wise/ http://processwire.com/talk/topic/1916-another-categories-question/ http://processwire.com/talk/topic/2802-how-would-you-build-a-daily-newspaper/ http://processwire.com/talk/topic/2519-nested-categories/ http://processwire.com/talk/topic/71-categorizingtagging-content/ http://processwire.com/talk/topic/2309-best-way-to-organize-categories-in-this-case/ http://processwire.com/talk/topic/2200-related-pages/ http://processwire.com/talk/topic/64-how-do-you-call-data-from-a-page-or-pages-into-another-page/

Hi everybody, I'd like to share a new module with you. Its purpose is to let users sign in with their Active Directory accounts using LDAP. It works similar to the module jimyost released in 2012, but adds some new features to it. You can define specific roles that are applied to new LDAP users Passwords are automatically updated by LDAP Local users still work like a charm You can translate it in the language you want to deploy your ProcessWire site New: Connect to a LDAP server via SSL New: Debug Mode New: Your configuration will be validated on save In my opinion, LDAP authentication is a must-have for ProcessWire being successful in the enterprise. What do you think? Is there a feature you miss? You can find the repository here: https://github.com/conclurer/LdapSignIn You can find the module in the ProcessWire module directory. Thanks in advance! Marvin Edit: Updated to Version 0.5.1 Beta including some minor fixes

Hi all, today I stumbled upon yeoman and went searching for a PW generator. Larry Botha mentioned in a side not in his thread about MVC template approach that he has put a yeoman generator for PW together. I test installed it and it is working great. Pretty fascinating how quick we can setup a PW project with yeoman. This definitely can be a great timesaver. Larry's generator sets up a pretty opinionated PW install with his MVC structured fixate template and KSS etc. It would be great if we could have an unopinionated version that gives us a clean PW install. We could add options to the generator for installing a choice of boilerplate templates like the blank template, Foundation, Bootstrap, Blog etc. Just wanted to get your opinion on this. If any of you are interested, we could pull something together. Cheers Gerhard

Ok since some different things are up to the client now - but the main work was done i'd like to show my first work with PW and give some feedback and kind words about the workflow. First i've to say thank you - ryan for this awesome diamant of code and all members here that treat every other with respect and patience! Domain is not open until some bureaucratic things are ready. http://gs-altfraunhofen.de/ This was no big project but not really easy, since there was no real basic stuff to start with, and the existing things (like a strange version of the logo you could see now) are done by some teachers and changing them was a little hot political thing....hot pavement! For such a little project with less budget i give the easy http://purecss.io/ a try and work with that. Tried to give the website some individual notes, but stay with many given elements by the small CSS Framework (buttons, forms) to save time/budget for the client. Here some screenshots of the page and changing on responsive: Desktop Mobile Backend Some special modules that i used: FieldtypeEvents (with some changes) FormTemplateProcessor (with adding some spamdetection, hidden honeypot and a "leave blanc" field) MarkupSimpleNavigation PageListImageLabel ProcessAdminCustomPages VersionControl Some special adjustments and using of some modules: FormTemplateProcessor Get a Form from given fields in a backend template and save them as pages and/or send them to a mailadress....easy task with the FormTemplateProcessor. For some spamdetection a added a hidden field as a honeypot and a questfield to leave blanc to check against bots. //Changes for better Spamprotection with a hidden additional field as a honeypot // create a text input a hide it via CSS .Inputfield_name2 display:none - see CSS example on the end of this module $field = $this->modules->get("InputfieldText"); $field->label = "Name2"; $field->attr('id+name','name2'); $field->required = 0; $form->add($field); // append the field to the form //end changes /**and at the end**/ //Create a field quest in the form template with heading like "please show us youre human an leave this blanc" //Set the Spamfilter and check if field quest or spam are blank! $questfield = $this->input->post->quest; $spamfield = $this->input->post->name2; if(empty($spamfield) && empty($questfield)) { echo "<h3>Ihre Email wurde gesendet!</h3>"; // see if any errors occurred if(count($form->getErrors())) { // re-render the form, it will include the error messages $out .= $form->render(); } else { // successful form submission, so populate the new page with the new values. foreach($form as $field) { $this->contact->set($field->name, $field->value); } if($this->email) $this->sendEmail($form); //if($this->parent) $this->savePage($form); $out .= $this->successMessage; } return $out; } else { echo "<h3>Es ist ein Fehler aufgetreten - Sie haben das letzte Feld ausgefüllt bitte versuchen Sie es erneut!</h3>"; } //end changes Frontend Backend ProcessAdminCustomPages This is a real great module for custom made admin pages. You simple add a page to the admin setup the process and add a templatefile in your site folder! Admin stuff made easy even for non devs! example code from the imageoverview (CutomAdminPage Template): <?php // Bilderübersicht Custom Admin Page ?> <style type="text/css" media="screen"> /** * larget magnific popup */ .mfp-iframe-holder .mfp-content { max-width: 1200px!important; } </style> <script type="text/javascript"> $(document).ajaxComplete(function() { //add trigger class and modal setup $('.PageListActionEdit a').each(function(){ $(this).addClass("lb-edit").attr("href",$(this).attr('href')+"&modal=1"); }); $('.PageListActionNew a').each(function(){ $(this).addClass("lb-edit").attr("href",$(this).attr('href')+"&modal=1"); }); //setup lightbox $('.lb-edit').magnificPopup({ type: 'iframe', disableOn: 0 }); }); </script> <?php //get Magnific css and js $this->modules->get('JqueryMagnific'); //render PageListtree with setting the parent page $formImages = $this->modules->get('InputfieldForm'); // prep the form $wrapperImages = new InputfieldWrapper; // a wrapper $wrapperImages->attr('value', '<h2>Bilder</h2>'); $i = $this->modules->get('ProcessPageList'); // get the pagelist process $i->set('id', 1015); // setting the parent page $pageTreeImages = new InputfieldMarkup; // the placeholder $pageTreeImages->value = $i->execute(); // fill the InputfieldMarkup form field... $wrapperImages->add($pageTreeImages); // put inside the wrapper... $formImages->append($wrapperImages); // append the wrapper echo $formImages->render(); And as result i've a adminpage just with the imagetree. For this kind of websites where i've very less images and use it on different pages - i'd like to have a mediacenter - and this is the way i get it work. Using the image approach from somas imagemanger module: https://processwire.com/talk/topic/3219-images-manager-beta/ But only the setup for the templates (single image fields and cats) - and have an easy administration like the whole site in a PW style. One bad thing with a own usage of the ProcessPageList - while editing after save you will be redirected to the "real pagetree" not the custom one! So no problem, it would be much better to use a kinda a modal editing on this special content - no problem all there just to find and use. (Combined it with the PageListImageLabel to show some thumbs in the pagetree) For the images first i thought i change the Tree where in the Wysiwyg the image is choosen to insert - this works so far mor details here: https://processwire.com/talk/topic/7439-processpageeditimageselect-hook-and-change-default-page/ But then i decided to don't let the users handle images in the wysiwyg and added a fieldset TAB for images and populate them if the users choose some on the right place on every page. So i've with a Pageselect field (parent page is the image-root) a simple "click on the images to show gallery" possible on every page: Here some screens on the backend of the custom admin page for the images with the template from above: Did the same for the documents section where i again use soma setup for files as pages: https://processwire.com/talk/topic/4602-flexible-downloads-using-pages/ This is a real great tutorial - you can expand all you need for such documents for eg. a counter is simple as easy PHP: 1. Setup a single file field, a counter integer field and a template for the kind of files you are using f.e. doc.php, docx.php, pdf.php and now use such a template file <?php /** * doc.php */ if($page->doc){ $page->of(false); $page->counter += 1; $page->save(array("quiet" => true)); $page->of(true); wireSendFile($page->doc->filename, $options); } Benefits from files as pages are real SEO Links on documents and images like: http://gs-altfraunhofen.de/dokumente/morgenbetreuung.doc/ some tweaks on the contact-page and some others in the admin.php to get them always in the state i want them i've some code like this: /** * setup choosen templates to hidden - equal witch setting the user takes */ $pages->addHook('saveReady', null, 'makePageHidden'); function makePageHidden(HookEvent $event) { $page = $event->arguments(0); if($page->template != 'doc' && $page->template != 'docx' && $page->template != 'pdf' && $page->template != 'image-category' && $page->template != 'image' && $page->template != 'contact_form') return; // replace 'category-site' with your template name if(!$page->is(Page::statusHidden)) $page->addStatus(Page::statusHidden); } For me like wrote i'm not a developer, not a real good coder, but i like the way that PW (and this awesome community) teach me in the right direction and let me be free in the way to solve my challenges! So closing the circle and say again thank you to all that read this and contribute to PW and this forum! Have fun - best regards mr-fan

Hello, Wow ok, there is so many ways to do what you are trying to do. I would have to understand your site better to be able to say what would be the most efficent way. But just to give you an idea, you could create a module that hooks the matching inmuebles as a property for the cliente-pages. I have done this by taking the big if(...) you created and turning it into a selector. public function init() { $this->addHookProperty("Page::inmuebles", function (HookEvent $e) { $page = $e->object; // We only execute for cliente-templates if($page->template->name != "cliente") return; $sanitizer = wire('sanitizer'); // Create the selector "template" $selector = "template=%s"; $selector.= ",prop_precio<=%s"; $selector.= ",prop_habitaciones>=%s"; $selector.= ",prop_tipo_inmueble=%s"; $selector.= ",prop_tipo_transaccion=%s"; $selector.= ",prop_zona=%s"; // The values $values = Array( "Inmueble", $page->prop_precio, $page->prop_habitaciones, $page->prop_tipo_inmueble, $page->prop_tipo_transaccion, $page->prop_zona, ); // Make the selector safe $selector = vsprintf( $selector, array_map(Array($sanitizer, "selectorValue"), $values) ); // Make the property hold the pages found by the selector $e->return = wire('pages')->find($selector); )); } Then you can do $clientes = wire('pages')->find("template=cliente, cliente_busca=1, include=all"); foreach($clientes as $cliente) { $out.= "..."; foreach($cliente->inmuebles as $inmueble) { $out.= "..."; } } This only makes sense if you always want to fetch the inmuebles in real time. There are other ways to achieve the same results too. Of course if you don't want to create a module, then you could just make a function that returns the selector for the cliente and use that with a find().

I left the iteration in place for possible future use, but good to know the clean way too! And no, I'm not using ZIP extraction currently.

The 403 means there's something wrong with your .htaccess -file or you are trying to access the asset-folder itself (and not an actual file inside there). Could you show us the link and/or code? This shouldn't have anything to do with the 403 you were getting. 128M is perfectly fine for basic web page -stuff. There might be some serious design errors in your code if you are hitting the memory limit, I'm afraid If you could tell us a bit more - paste actual code and so on - we could help more. How large are the catalogs you are uploading?

Hey! Sorry for the late response - I've been fairly busy lately. First of all, no, I don't think it's documented anywhere else but here: https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/core/Pagefile.php#L441-L444 The reason for that probably is because it's very rarely needed. I'm glad you worked it out. However I would like to mention that you should rather do // Process the upload only once $filenames = $u->execute(); if(count($filenames)) { // If there's always just one file, no looping needed $pagefile = new Pagefile($p->files, $filenames[0]); $p->files->add($pagefile); $p->save(); echo $pagefile->hash; } You don't need to use the last() -trick - internally ProcessWire is changing the string you are passing to add() to a Pagefile object anyway. Also I assume you haven't enabled zip-file extraction? Because then you should handle all the files returned from the execute() - then you would also have to separate the hashes with something you can parse.

The title function renderRepeaterLabel is hookable. Here's a generic example, which applies to all Repeater fieldtypes: class RepeaterTitle extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( // The module'ss title, typically a little more descriptive than the class name 'title' => 'Repeater Title', // version number 'version' => 0.1, // summary is brief description of what this module is 'summary' => 'An example module used for demonstration purposes.', // Optional URL to more information about the module 'href' => 'http://processwire.com', // singular=true: indicates that only one instance of the module is allowed. // This is usually what you want for modules that attach hooks. 'singular' => true, // autoload=true: indicates the module should be started with ProcessWire. // This is necessary for any modules that attach runtime hooks, otherwise those // hooks won't get attached unless some other code calls the module on it's own. // Note that autoload modules are almost always also 'singular' (seen above). 'autoload' => true ); } /** * Initialize the module * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. * */ public function init() { $this->addHookBefore('InputfieldRepeater::renderRepeaterLabel', $this, 'repeaterLabel'); } public function repeaterLabel($event) { // Replace function $event->replace = true; // Arguments: $label, $cnt, Page $page $page = $event->arguments(2); // Show repeater page body instead $event->return = $page->body; } } Not sure what the best way is to replace the title per specific instance of a Repeater field -- I'm still learning my way around hooks. But I'm sure someone else knows!

Depends where you want to start with this really. The very simplest way would be to use Ryan's form builder module. This form could be made available only to each of your two types of users that can create other users. The form builder can publish straight to pages. Users are also just pages. Just make two identical forms, one for managers and one for supervisors; the only difference being one has extra options in the role drop down. Just make sure your fields match the 'user' page fields. Or, it's fairly simple to make your own user registration page. Create a form in html. Post the form back to the same template and process it. You'll find $user->hasRole($role) useful. Here's a simple example from the docs: <?php $u = new User(); $u->name = "gonzo"; $u->pass = "BamBam!"; $u->addRole("guest"); // substitute this for your worker, manager or supervisor role $u->save(); Both are pretty simple. Personally, I'd start with the do it yourself method so you understand how pw works better. You'll find lot's of help if you have a go.

I don't know about bumping the limit further up. But when setting up file downloads, there are some useful functions in the API that you could use. E.g. if you want to allow downloads only for certain users. Here's a post that helped.me.out: https://processwire.com/talk/topic/3634-down-uploads-on-a-per-user-policy/

The quickest way to check the page weight is to stop rendering the images. One thing I had with PIM the other day (the first time I had used it) was that in its default configuration, the images it was producing had a significantly higher file size than the originals, despite being smaller pixel wise. This was because it was saving at a much higher quality than I had saved the originals. Then again, you only have 12 images here. I am not sure if you are also overworking your code a bit (this is the point when Soma might tell you that I am talking rubbish - he knows WAY more than I do) Just digging out a similar bit of code from an old blog of mine: function getPostsbyCategory() { $thisCategory = wire("page"); $posts = wire("pages")->find("post_category_select=$thisCategory"); $out =" "; foreach ($posts as $post) { $text = implode(' ',array_slice(str_word_count($post->summary,1),0,$maxpostlength)); $out .="<div class='posts clearfix'>"; $out .="<a href='{$thisCategory->url}{$post->name}'><h4>{$post->title}</h4></a>"; $out .="$text...<a href='{$thisCategory->url}{$post->name}'>read more</a>"; $out .="</div>"; } echo $out; } Ignore me truncating the text in the middle. I don't appeared to have explicitly referenced the title field, but I cant remember why. I have left out any limits or pagination here.

Glad you got it sorted.. For the curious, the reason why the option 'tag' is not being hidden on selection of another select input is because the following doesn't work with pageautocomplete: $tags->attr('class', 'batcherAction'); I guess the reason is that it is a different kind of inputfield. Don't know how to get around this. Because of the above, the following js doesn't catch: $('#batcherAction').change(function(){ var option = $(this).find('option:selected').val(); $('.Inputfield_tags').closest('li.Inputfield').hide(); $('#wrap_'+option).show().css('list-style-type', 'none'); }); Of course there are other ways to get around this using js...

Well, at least that means that your script structure is probably fine. Thinking back to the maintenance man in my old studio who used to shout to us to check the plug was in the wall before phoning him saying "its broke again," start going through the obvious. I am assuming that the categories are a group of pages under a set parent using the same parent. And you are using the title field to search by. To start with, the problem with using the title field is if you rename the category you might have an issue. So, just for interest, search by id instead. See if that is okay.

Hello everyone, Thank you for your fast answers. Looks like there's definitely a need for an extended LDAP module. @teppo: Yes, I'll enhance the module's functionality over time. For ideas and feature wishes, you can just open up tickets on GitHub. Furthermore, if you can extend the module's functionality, you can open up a pull request on GitHub at any time. @horst: Thank you for finding the spelling mistake. I'll fix that one in the next update. @Pete: This is heading in the same direction as teppo's thoughts. Maybe in addition to mapping the groups into different ProcessWire roles, mapping some user-defined Active Directory attributes to ProcessWire user variables could be a nice extension. I'd be glad if we could talk about this in a separat GitHub thread so that this does not interrupt this one. The idea with the GUID is nice, although it needs an additional field in the user model and I'm not sure if that is a proper way to solve this issue. @Nico Knoll: Of course I'm German. How could you be unable to see that. ;-) I work together with @phil at Conclurer.

Assuming you have your Javascript in your templates folder, do exactly as you would for css. So, if your scripts are in a folder called js, then <script src="<?php echo $config->urls->templates?>js/jmyscript.min.js"></script> EDIT: The trick here is to think of your /site/templates/ folder as the root of your site, with the exception that you need to be explicit about the paths when including script and css files. So, you might have /site/templates/ --js --css --images mytemplatefile.php

OK, I have gone ahead and customised Batcher to do this. Almost ready but there are a few kinks (js/css). The 'Tag' action is hidden on load (similar to Change Parent) but it is not hidden on selection of a different option; js is not my forte. PW API side works fine although you may want to limit the number of pages you apply batch tags to. You can apply single or multiple tags. There are also some hard-coded things in there that you might want to change such as the name of your 'tags' field. Just search for @@kongondo in the ProcessBatcherExt.module and ProcessBatcherExt.css files for changes I added. Feel free to do with it as you please BatcherExt.zip

Thanks Sinmok and netcarver. It would be really useful when we are using a front-end framework like Bootstrap. <?php $list = $pages->find("template=basic-page"); // Returns 5 pages $chunked = array_chunk($list->getArray(), 3); ?> <?php foreach($chunked as $i => $row): ?> <div class='row'> <?php foreach($row as $item) : ?> <div class="col-md-4"> <?php echo $item->title; ?> </div> <?php endforeach; ?> </div> <?php endforeach; ?>

Thanks BernhardB after reading the info in the link you showed i got it to work thanks alot

Are you actually importing pages with other content fields, or just wanting to create a series of pages and child pages with titles, ready to populate with other content? If the latter, then try: https://processwire.com/talk/topic/6102-batch-child-editor/ OR http://modules.processwire.com/modules/process-batcher/

Netcarver, ProcessDiagnostics is beautiful–really enjoying it. I have one suggestion though, which is to either have ProcessDiagnostics install at least one of the diagnostic modules, or to have it display some error if none are installed when you go to Setup > Diagnostics. I tested on a new installation this morning (before I had my coffee) and couldn't figure out why I was getting a blank admin screen when viewing the Diagnostics page. After hunting around in the code trying to figure out why, I eventually slapped myself for forgetting to install any of the related Diagnose modules. But I'm guessing other people might run into the same thing.

This may be a bit off-topic (nothing new from me), but I remember someone saying that "Page" makes much more sense than "Node" (for an example) for web use, and I really do agree with that. Still it's interesting to see how people not used to ProcessWire's jargon (and often coming from other systems and/or custom-built applications) get confused here. CMS/CMF such as ProcessWire has to manage content as nodes / items / pages / rows of some form and in this case those items are called Pages. They're not that different from Nodes in Drupal or Posts (and, these days, a whole bunch of different "post types") in WordPress.. or even from simple database rows. The main difference between database rows and Pages, of course, is that Pages have mostly web-related helpers (methods) attached to them and the built-in ability to pull content automagically from multiple tables. Sure, you could say that Pages are objects and thus have some overhead from there, and you'd be absolutely right. Then again, it all depends on your use case and what really matters for you. Most things built in ProcessWire could be considered "web sites" and web sites usually consists of (surprise!) Pages. Makes sense, huh? It is also important to note that you don't actually have to use Pages for everything. Saying "in ProcessWire everything is a Page" is misleading. It's true for the bulk of everything built with ProcessWire, but there are exceptions. For my Version Control, Changelog and Login History modules, for an example, I chose another route: a custom database table. In my opinion custom database tables are better option in some cases, but this way (like Pete already pointed out) you won't be able to use ProcessWire's selector engine; you'll have to write all your queries as plain, old SQL instead and route them through $db (MySQLi) or $database (PDO) objects. Doable, but potentially less secure (with selectors there's no risk of SQL injections, for an example) and more complicated. There's also the option of creating custom Fieldtypes. Each Fieldtype defines it's own schema, so this is very viable alternative to custom database tables. This way you'll still be able to work with native selector engine, but you'll get some of the benefits of plain database tables also. Ryan's Events Fieldtype is a good example (and starting point) of this. ProcessWire sets very few limits on the way you work. Want custom tables? Sure, go ahead, do it. Want to use Pages you can add fields to later with ease, edit with built-in admin tools and find using selectors? Sure, we can do that too. Combination of both, pages with fields of custom type and schema? No problem, we've got you covered. .. and this is one of the main reasons I love ProcessWire.

Not exactly what you are looking for, but you could use this module: http://modules.processwire.com/modules/process-page-field-select-creator/ to create the page field and populate the categories. Might be of some help. You can paste comma separated values when entering the select options (Option 2).

I just (like 5 mins ago) implemented "Most Viewed Pages" widget for a client. I used Wanzes excellent ProcessGoogleAnalytics module and it was easy enough pull data when it was first setup. It might be that this is not a fit for your project Martijn (if you need the data for selectors for example), but this is how I did it: $pga = wire('modules')->get("ProcessGoogleAnalytics"); $ga = new GoogleAnalyticsAPI(); $ga->auth->setClientId($pga->clientId); $ga->auth->setClientSecret($pga->clientSecret); $ga->auth->setRedirectUri($pga->page->httpUrl); $ga->setAccessToken($pga->accessToken); $ga->setAccountId($pga->accountId); $defaults = array( 'start-date' => date('Y-m-d', strtotime('-1 month')), 'end-date' => date('Y-m-d'), ); $ga->setDefaultQueryParams($defaults); $params = array( 'metrics' => 'ga:pageviews', 'dimensions' => 'ga:pagePath', 'sort' => '-ga:pageviews', 'max-results' => 11, ); $visits = $ga->query($params); $out = "<h2>Most read articles</h2><ul>"; foreach($visits['rows'] as $row) { if ($row[0] == "/") continue; // Skip the homepage, should be on top 10 always, if not, then 11 articles is shown $p = $this->pages->get($row[0]); if ( ! $p->id ) continue; // For some reason page is not found anymore... $out .= "<li><a href='$p->url'>$p->title</a></li>"; } $out .= "</ul>";

@bcartier: The ImportPagesCSV-module can't do this as is. But I tried making a tiny addition to make it support FieldtypePage (those used to make page references) and it worked amazingly well. The only change needed was to add 'FieldtypePage' to $fieldtypes array (just before init() function if you take a look at the module file), like this: protected $fieldtypes = array( 'FieldtypePageTitle', 'FieldtypeText', 'FieldtypeTextarea', 'FieldtypeInteger', 'FieldtypeFloat', 'FieldtypeEmail', 'FieldtypeURL', 'FieldtypeCheckbox', 'FieldtypeFile', 'FieldtypePage', // add this line ); After that addition it's possible to choose a Page field when connecting the fields from the CSV to the ones in the chosen template. I had pre-populated categories at the target site and used their id's in the CSV file to reference those categories. Multiple categories worked like a charm as well, just use a pipe in between id's (123|456|789). Moreover, if you've got only one category per entry to reference, then you don't even need the id's of the categories - you can use paths as well. Here's a little example: cat.csv: title one two three four entries.csv: title,categories a,/cats/four/ b,/cats/three/ c,/cats/one/ d,/cats/two/ Import cat.csv using a template for categories with (at least) title field, under a page at /cats/. Then import entries.csv using a template for entries, having a title field and a page field. This should leave you with entries that are connected to categories. I hope this gets you somewhere. @ryan: Looks like page references could be supported very easily. I just used this successfully to import ~3500 pages with category references from an old site to a new PW one. But maybe there's still something else to be done before they're fully supported?

Thank you guys! In the meanwhile, the Project is on Github and the modules overview: http://modules.processwire.com/modules/process-google-analytics/ https://github.com/wanze/ProcessGoogleAnalytics I never used Github before and had to create an account first, thanks Soma for your Tutorial! Still I'll have to explore git a bit more ;-) Please let me know what you think and if it works for you! One feature that is on the Roadmap: Compare the statistics taken from the last month (Audience) with the previous month and show +/- percentage

I often type some random chars into the .htaccess to see if a 500 (?) is thrown, which helps to see if htacess is really working/enabled.