Leaderboard

This is a topic I check out every now and again because, especially on photo-heavy websites, some "seamless" way of resizing images before they are uploaded is something I've always wanted. You know the scenario - someone shoots a bunch of images with their 21 megapixel camera, tries to upload them not thinking about file sizes and the page hangs for ages whilst the image is resized. Or, worse, it times out because you didn't give PHP enough memory or increase the max execution time. I've tried a few PC-based tools to make like easier for clients - some in Windows are part of the right-click menu even, so they just need to remember to right-click and resize. But wouldn't it be nice to have something that does it automatically? Well this might just be the answer: https://github.com/blueimp/jQuery-File-Upload/wiki/Client-side-Image-Resizing - which is part of a larger library: https://github.com/blueimp/jQuery-File-Upload My question, because I just don't have time right now (lame excuse, but I've got a lot on and this may be of interest to you guys anyway), is whether anyone else has tried this particular set of scripts out, or if the image manipulation gurus amongst us (I'm looking at you Horst ) have considered something like this (canvas to blob conversion on-the-fly before upload seems to be what's happening here) or whether something like that seems simply too volatile - I imagine on huge images it could consume a lot of memory on the person's PC, which is still quicker as a smaller file is uploaded, but may have other side-effects. I have used a Java applet in the past primarily to handle huge files, but that also had some client-side image manipulation built-in, but Java is such a security issue nowadays it's unbelievable. Plus it requires Java to be installed in the first place, so something JavaScript-based, using browser features like canvas if they're available seems ideal, with fallback to simply uploading the large file and letting the server resize the image. One to think about anyway. I'm sure the W3C will eventually roll out a recommendation for browser-side manipulation, but as we know update and implementations are always guaranteed to come quickly or work consistently.

You want to use addStatus so that your change goes from 1 to 2049 so that when you remove unpublished via the admin it takes off the 2048 that means unpublished and returns it to one. If you set the status directly to unpublished, it will end up being 2048 which is not what you want. $page->of(false); $page->addStatus(Page::statusUnpublished); $page->save();

I know everything is pretty locked down for this version (2.6) but I wonder if this could be a consideration for a future release. And that is: when adding a new template and using 'duplicate fields used by another template' there could be an option to also copy the field widths too.

Just tested this and it works really well. I'm sure there's a more elegant way of changing the settings, but if you put this package on your server, edit js/main.js and change this near the top: $('#fileupload').fileupload({ // Uncomment the following to send cross-domain cookies: //xhrFields: {withCredentials: true}, url: 'server/php/' }); to this: $('#fileupload').fileupload({ // Uncomment the following to send cross-domain cookies: //xhrFields: {withCredentials: true}, url: 'server/php/', disableImageResize: /Android(?!.*Chrome)|Opera/ .test(window.navigator && navigator.userAgent), imageMaxWidth: 800, imageMaxHeight: 800, imageCrop: false // Force cropped images }); Then open the "Basic plus ui" tab on that package with Firebug on in Firefox then you can see it's sending image data rather than a file, so is resizing client-side really nicely. I just tested it on a massive image from my PC and the upload was really quick - I added a 3.5mb photo to the upload queue, it generated a tiny thumbnail instantly and told me it was going to upload just 171.24kb and it did EDIT: 7mb file worked just as quickly. This is like magic!

FrontendUser The FrontendUser module provides a frontend login, logout and user registration functionality. Features See module documentation for details. login with error handling and value sanitizing Plugin: ProcessForgotPassword core module integration Plugin: LoginPersist module integration user registration with username and email address already in use check email adress pre-register validation (email verification) Extendable with additional fields and by PW hooks forms generated by PW form api Custom style / script Requirements FormHelper (0.7.1+) Usage Documentation / examples Repository PW module repo GIT repo ToDo / Issues Issues I hope it will be helpful to the community and I would be glad to get feedback or suggestions for improvement!

There's Luna which might be worth a look. It's active, lightweight and has all the features you'd expect. https://github.com/GetLuna/Luna http://getluna.org/index.php

I'm definitely seeing old cached stuff there, or remnants from the old admin theme. Particularly on that uninstall box, the colors of the PW 2.3 admin theme are bleeding through. Do a hard refresh on your browser cache. Make sure that your entire /wire/ directory was replaced in it's entirety and not replaced into (with potentially merged files). Lastly, make sure you don't have a /site/templates-admin/ directory present.

Hey guys! Just announcing that from now on we will have a newsletter. Those that want to know about what we are doing besides of what I post in the showcase forum should subscribe it here http://eepurl.com/bk-QJz

Ok, all new features have now been merged to the master branch. I have changed the release state from Stable to Beta for this release. Really just as a precaution for the Update mode options until I have had more feedback on this. Please let me know how this new version works out for everyone. It will probably take you a while to go through all the new configuration options, but I think it's worth the effort. You can use this module as a simple replacement for the Children/Subpages section of the Children tab (which allows for much quicker editing of child pages), all the way through to a fully customizable CSV import tool for site site editors to create and update pages. Feel free to send through any other ideas along with any issues you come across.

After messing around config and php templates I finally got the script to work. Your idea of building a template to handle the ajax call was right on! I now have the script functioning inside its own folder with the ajax calls being handled by a page that has a special template that includes the script itself. Two big advantages: 1. No need to make changes to .href; 2. The problem that I was having with this script session was solved. I guess that calling a PW page means that the session is kept intact. Both problems were killing me for the past two days, I can now move on! Thanks Diogo, always nice to have some discussion about alternatives to solve problems. Greetings from Lisbon!!

Welcome to the forum! You could of course add an exception to that file only on the href, but IMO the best way to do this is to have that file as a normal PW template and create a page with it, then, just call the page instead of the file: example.com/utilities/xcrud (or whatever you want)

May this one is it worth to test with AdminCustomFiles on the existing UI File input? https://github.com/blueimp/jQuery-File-Upload/wiki/Client-side-Image-Resizing would prefer a js/canvas magic that could be tied on the existing file/image upload... Since i'm working with shared hosting a lot - i would be interested in a easy solution, too. Until now i'd no big problems to tell the client to resize images before upload - but this workflow feel not really like "working in web 2015" it feels more like "working in web 2005" regards mr-fan

This module serves as an example of creating an editable table of data as a Fieldtype and Inputfield in ProcessWire. In this case, we create a simple table of events each with date, location and notes. This pattern can be adapted to nearly any table of information. Note that this module is intended as a proof-of-concept. If you find it useful for the example scenario (events) then great, but keep in mind it is not intended as a comprehensive events solution, where using ProcessWire pages may be a better fit. This is a pattern I've used for creating tables of data in ProcessWire for many different Fieldtypes/Inputfields and thought it would be good to setup a proof-of-concept example like this to share. Module Page / GitHub Page Install Copy the files for this module to /site/modules/FieldtypeEvents/ In admin: Modules > Check for new modules. Install Fieldtype > Events. Create a new field of type Events, and name it whatever you would like. In our examples we named it simply "events". Add the field to a template and edit a page using that template. Output A typical output case for this module would work like this: foreach($page->events as $event) { echo " <p> Date: $event->date<br /> Location: $event->location<br /> Notes: $event->notes </p> "; } This module provides a default rendering capability as well, so that you can also do this (below) and get about the same result as above: echo $page->events; ...or this: foreach($page->events as $event) { echo $event; } Finding events This fieldtype includes an indexed date field so that you can locate events by date or within a date range. // find all pages that have expired events $results = $pages->find("events.date<" . time()); // find all pages with events in January, 2014 $results = $pages->find("events.date>=2014-01-01, events.date<2014-02-01");

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/

Try this: $t = $templates->get("basic-page"); $nt = $templates->clone($t); $nt->save();

Sorry to suggest something obvious - still happens when trying on an alternate browser not previously used for the site (so guaranteed no old cached stuff)? Craig beat me to it

horst, have you done a full/hard/forced refresh on the admin? I've had some odd behaviour in the past, which has just turned out to be cached module javascript files.

I remember this behaviour. It depends on the PHP version. With php 5.5 (?) and higher you get the // when creating new translation files in the backend.

Hello, I have tried to install this language (spanish (es-ES) v.2) on PW2.5 Wenn I try to edit a file from "admin/setup/language-translator/add/". It shows a message: File does not exist: /wire\modules\Inputfield\InputfieldPageName\InputfieldPageName.module (Translation file not needed? Textdomain: wire--modules--inputfield--inputfieldpagename--inputfieldpagename-module) But the file /wire\modules\Inputfield\InputfieldPageName\InputfieldPageName.module exists. I have opened the json file with the translations I have observed that the attribute "file" is: Wenn I use the translator manager to create a new translation file, the value of this parameter ist: I have changed in all my language files the // by \/ and it works. Can someone test if I'm wrong or this error are produced due to this wrong attribute in the translation files? Thank you in advance. Raul Garcia.

I should be easy to extend the register form with additional fields (like done with the login and register plugins examples). A FrontendUserProfile is planned and should be easy to build with the FormHelper module (and also without, but I like it It simplify some tasks like sanitize values or form processing). Maybe ProcessProfile core module could do the job... I take a look and maybe add a simple example, but that should be moved to the FormHelper topic.

I know there are other options with Plupload, but I was looking for something that required no other browser plugins (yes, I know Flash and silverlight are optional, but I believe they are also declining in popularity quite rapidly).

Glad it worked. It wouldn't have worked because of variable scope and attempting to assign multiple results to a single variable in one shot. In other words, the $warning = "" would have been reset each time the function executed. That's why the write access (reference) to $warning (outside the function) is needed. I'm surprised about the {title}, though... Not sure why that had to be changed. I think the {title} had to be changed because that seems to only be worked with after the function has returned a value. It can't just guess.

Thanks for your reply. $warning will not be available inside the each() callback function because of variable scope. Also the callback function needs to either echo or return something. So I'm afraid your code won't output anything and give a PHP notice like "variable $warning not defined" because you define $warning outside the callback function. This is mentioned in the link that I posted in #1 EDIT Sorry, I overlooked the "use (&$warning)" part. So forget about what I just said I implemented your proposed solution. But still the return value gives me the page ids of pages within the $divesites page array where I would expect it to be empty. EDIT again Got it. I still had $warning = $divesites->each(function... After removing the $warning = part, it works. Only I had to replace {title} with {$item->title} Thanks again. But with my limited PHP knowledge I still don't understand why that is so.

Just thinking out of the box here: $warning = ""; $divesites->each(function($item) use (&$warning) { if (!$item->marker->address) { $warning .= "<div class='alert alert-warning'>coordinates for {title} not set</div>"; } });

Update: This eventually solved itself thanks to a solution for another related problem posted here: https://processwire.com/talk/topic/9818-how-can-i-add-an-href-security-exception/

at the end fo a day a joke keeps the pain away.... http://www.googlefight.com/index.php?word1=Processwire+&word2=Joomlapress sorry no real argument but since we here in "Pub"....i wish a good week.

You can also put the file on the root of the website and call it directly, the .href rules are prepared to bypass the index if you call an existing file (that would imply moving the script also, probably).

Damn that looks really slick.

Thanks teppo - changed loadImageMaxFileSize to 100mb and it worked with a 19.5mb image. The thumbnail only took a second to display on the uploader @mr-fan - that's a much larger job unfortunately, but hopefully this proves impressive enough that it will be considered for the backend. Here's a screencast for those wondering what the fuss is about: http://www.screencast.com/t/CuAwqAc8G (ignore the white rectangle that appears when browsing files to upload, that's just me hiding stuff ) That's about 26mb worth of images resized to max width or height of 800px. So 26mb becomes 1.37mb prior to upload. My jaw is somewhere near the floor right now that this is all just JS, HTML canvas etc with fallbacks for even really old browsers No sound on the audio clip at the end but use your imagination - it plays direct from your PC before upload. That's probably more useful for videos to make sure you're uploading the right one!

I'm seeing two settings that could have something to do with this: maxFileSize and loadImageMaxFileSize. Latter seems to be 10MB by default, so not too far from what you've mentioned here.

Hi Sasa I think I've used that one in the past. It has Flash fallback etc, but the one I linked to (same one that mr-fan linked to ) seems to be pure javascript so compatible with most browsers without needing to rely on a client's device having anything else installed other than javascript - I think that's where it stands out against other solutions.

Have you set the image field to single image?

Hello Pete, I made custom Media manager for Joomla 3 and there used Plupload javascript library for upload process. Also have some clients where they uploads >20 of large images at once (cheap shared hosting). Here is link with few images (upload process, and resized images after uploads). regards, Sasa

You're invoking the function with a single argument of the type "string" and the value "690,425", but size() needs two arguments/values, best of the type int. You cannot fake the comma between function arguments. list($w, $h) = explode(",", $size, 2); $w = (int) $w; $h = (int) $h; $slideimage = $slideimage->size($w, $h);

Yep the problem is the one tpr describes. Beside that, you should consider the following: Don't build your urls manually, let ProcessWire do it for you: $action = $pages->get('/checkout/')->url; <form action="$action"> Sanitize input $id = (int) $input->urlSegment1; // Must be an integer Cache the page you're searching; I'm sure that ProcessWire also returns a cached page, but in theory, each $pages->get() call fires an SQL query: $myPage = $pages->get($id); // Assign the found page to variable $myPage if ($myPage->id) { // Make sure we found a page echo $myPage->title; } Escape output $title = $sanitizer->entities($myPage->title); echo "<input type='text' name='product' value='{$title}'>"; Edit: This is only needed if your title field does not have the "HTML Entitiy Decoder" textformatter applied. Cheers

Isn't your checkout page end with a slash? (yoursite.com/checkout/) If so, you may have a redirect so post values are lost (checkout -> checkout/), so you need to append a slash to the form action. Check it on the Dev Tools/Firebug Network tab.

I've done a site for a big german company. Unfortunately I'm not allowed to say which one. But... they were unsure if ProcessWire will be the right decision. After showing them the scyscrapers example the felt in love with ProcessWire. Maybe it helps to describe the unlimited possibilities which can easily built with ProcessWire.

New kid on the block https://code.visualstudio.com ! Is this the same Microsoft that kept IE6 alive for so long??

Looks like a bad typo on my part, sorry guys. I've corrected it.

Been working in pw for nearly 5 years and it's still receiving constant updates and getting better and better. (While some other cms' have fallen by the way side). Show them some of the other agencies using pw and refer to the security supports tickets (I am yet to have had a security issue with pw which hasn't been server not application level). Also tell them Drupal is verbose and painful to template and create modules for, and Wordpress is shit for most things... Both are the case

Best way would be to show them in real time. Take your laptop and show them, depending on who you are dealing with: admin, editor, end-user, site owner, techie or non tech, etc., the part they are going to do on the website: a) setup b) admin c) pagetree (editing and maintenance) Now compare that to the others in time, learning curve, easiness, etc. Speaks for it self so never try to convince them. They should convince them selves.

Updated module today to 1.0.3 with a small fix - where the markup would break if there's not encoded single quotes in title or texts for linkedin and twitter. It's now using htmlspecialchars_decode() and rawurlencode().

A bit OT, but if you can plan the languages hirarchy right from the start of a new site, you can do it this way: enable languages support set Title / Label of the default language to your desired none english native language, (e.g. 'Deutsch' (German)) drop in the none english language pack (for admin backend) into the default language, (e.g. german langpack) add a new language to it and drop in a language pack for any none english language or simply don't drop in a language pack to get the english version (but not as the default one!) As a nice sideeffect every new user in your system gets the native language per default without have it to select from the list. So, yes, this is no solution if you once have set it up and need to switch the default language afterwards, but just want to note it.

This isn't exactly what I had in mind (thought you had those users already, just wanted to give them permission to edit a page), but there's an example of creating an user at the bottom of the $user page. If you just want to use Page Edit Per User and grant specific user access to a page via API, that looks more like this: // I'm assuming that you're already creating pages via API; not going into detail about that.. $p = new Page; $p->template = $templates->get("some-template"); $p->parent = $pages->get("/some-parent/"); $p->name = "some-page-name"; $p->save(); // give current current user access to edit previously created page $user->editable_pages->add($p); $user->save('editable_pages');

Hi Wilsea, It really depends on how you want to use and present your data at the end of the day + how much data we are talking... A search of the forums will tell you that most people would choose pages over custom tables. Why? For one, you get access to the powerful PW API. Of course, behind the scenes, it is all db tables, but PW takes care of that. There is (almost) a selector for any query you would want to make....If this is not the case, you can also query PW tables using normal MySQL queries. If you want to present your data at unique URLs, then pages is the way to go.... How many tables are we talking? You have probably noticed that PW is insanely fast. Ryan has done a tremendous job in optimizing selectors. With power comes responsibility; so, limit=xx is a good friend when using "find".... Relational db/References...pages is the way to go...Page Reference Fields in PW make this very easy!! If you went the pages route, you can also harness the extended power of templates, e.g. using templates to control page access... For some people, having thousands of pages in the pages tree is not desirable. However, depending on how you structure your site, this may not be a problem. If it is a problem, then you might want to think of custom tables....although, there are ways around displaying your pages in a grid (as in a table) in the backend rather than the tree..Btw, I reckon you are talking about a local db table? (i.e. not external to your domain..). Easy-on-the-eyes...PW API is beautiful and easy to read....even though MySQL-like code is easy enough to read as well... Bottom line is this: If you really don't have to, do not reinvent the wheel. PW already gives you an easy, consistent and powerful way to query your data....using the API.. It is late and I am not thinking straight. I could have missed something. Others will chip in. Also use Google to search the forums (e.g. custom tables...). You might also find it useful to read the various threads detailing how some folks here imported data from other platforms/websites into PW....There are also bulk editing modules such as CSV Import module... Hope my comments give you a little idea how you might proceed... Edited: for clarity + additions...

That solution doesn't scale, if client adds new page each day... I would add new image field called background image, set it to have only one image and then add this to template file: <style> body { background: url(<?= $page->background_image->url ?>; } </style> (written in mobile)

Hi Tina, I've done something similair for a project. You need an autoload module which executes a code like this: class YourAutoloadModule extends WireData implements Module { //... public function init() { if ($this->user->hasRole('yourFrontendRole') { $this->addHookBefore('ProcessHome::execute', $this, 'redirectToFrontend'); } } public function redirectToFrontend(HookEvent $event) { $frontend = $this->pages->get('yourPage'); $this->session->redirect($frontend->url); } }

I haven't done much front-end user stuff but the API and flexible role/permission/user system makes this pretty easy. Of course, depending on the exact needs it could get more complex. So for example you could create a new permission called frontend-edit. Create a role called frontend-editor and give it page-view and frontend-edit permissions. This will keep a user with (only) the role frontend-editor out of the back-end but allows you to log him and check for permissions in templates, allowing stuff you want. if ($user->hasPermission("frontend-edit")) { echo "<a href='{$page->url}edit'>EDIT</a>"; } else { echo "you are not logged in or you do not have permission to edit this page"; } if ($user->isLoggedin()) { echo "here you go, view this awesome page"; } else { echo "plz login if you wish to view this awesome page"; A front-end login could be as simple as creating a page, why not name it login, and putting this into the template file: <?php /** * Login template * Based on a forum contribution by Ryan, can't locate it, but the are many examples of login forms. * */ if($user->isLoggedin()) { // user is already logged in, so they don't need to be here $session->redirect($config->urls->root); } // check for login before outputting markup if($input->post->user && $input->post->pass) { $user = $sanitizer->username($input->post->user); $pass = $input->post->pass; if($session->login($user, $pass)) { // login successful $session->redirect($config->urls->root); } } include("./inc/head.inc"); ?> <?php if($input->post->user) echo "<div class='alert alert-error'>Vekeerde combinatie van gebruikersnaam en wachtwoord</div>"; ?> <form class="" action='./' method='post'> <label for="user">Gebruikersnaam</label> <input type="text" name="user" id="user" placeholder="Gebruikersnaam..."> <label for="pass">Wachtwoord</label> <input type="password" name="pass" id="pass" placeholder="Wachtwoord..."> <label></label> <button type="submit" name="submit" class="btn btn-primary">Login</button> </form> <?php include("./inc/foot.inc"); ?> These are just some examples but most if not all what you need is already available. It's up to you to code it the way you want. The API cheatsheet gives a nice overview of available building blocks. For the Create, Update and Delete stuff i think you would need to roll your own forms, populate them via the API and do with it what you want. Of course making sure you properly sanitize the inputs, maybe do some of your own validation etc.

Regarding workflow: the default profile is pretty much always my starting point. It's rare that I don't end up repurposing the fields and templates that are already there to start building things out. Likewise, I usually end up just renaming (as necessary) and repopulating the pages that are already in the default profile. Then I will start adding new fields, followed by templates, specific to the needs of the site. While I try to determine most of the templates/fields that I'll need ahead of time, I will continue adding fields and templates throughout the entire development process as necessary to make the site do what I want it to. Most larger PW sites are pretty relational and make good use of Page references. But this is also the part that I think is most important to outline when it comes to workflow. This part is quite a bit different from other systems, but has major advantages. I try to make my selectable Page references part of the site's structure, if at all possible. For example, on tripsite.com, every bike tour has a "country" page reference field, and those countries are useful in the site's overall structure (Netherlands in this case): http://www.tripsite.com/countries/netherlands/ In other cases, page references might not fit as part of the site's general structure, so I'll have a /tools/ section in the site where they live. Though it's easy enough to make them function as pages, so I figure why not. Here are a few examples (they are all using the same template): Multi-page reference field "months" (April in this case): http://www.tripsite.com/tools/months/april/ Multi-page reference field "tour_types" (Guided in this case): http://www.tripsite.com/tools/tour-types/guided/ Page reference field "difficulty" (Difficult in this case): http://www.tripsite.com/tools/difficulty/difficult/ The template used on those pages is not much more than this: $tours = $pages->find("template=tour, {$page->parent->name}=$page, limit=10"); foreach($tours as $tour) { // output the tour } Admittedly, most of my projects are rebuilding existing sites, so I usually have some (or a lot) of data to migrate to the new site. This becomes a major component of the development workflow, so I figured I should mention it here. After I've setup the necessary fields and templates (and usually before front-end development), I'll work on bringing in the new data. If it's a relatively simple conversion job, I might use the ImportPagesCSV module. But most jobs require some markup replacement, character set conversion or other things, so I'll build my own import script. This is where I like to bootstrap PW from a command line PHP script. Here's a simple example: /import-airports.php #!/usr/bin/php <?php require("./index.php"); // bootstrap PW $fp = fopen("./airports.csv", "r"); while(false !== ($data = fgetcsv($fp))) { $page = new Page(); $page->template = 'airport'; $page->parent = '/building-types/airports/'; $page->title = $data[0]; $page->location = $data[1]; $page->year = $data[2]; $architectName = wire('sanitizer')->pageName($data[3], true); $architect = wire('pages')->get("/architects/$architectName/"); if(!$architect->id) { $architect = new Page(); $architect->template = 'architect'; $architect->parent = '/architects/'; $architect->title = $data[3]; $architect->name = $architectName; $architect->save(); } $page->architect = $architect; $page->save(); echo "\nCreated page: {$page->url}"; } Once I've got a lot of data to work with in the system, I'll start doing front-end development: creating the template files, markup, css and anything else necessary to handle the output for the site. The files from the basic profile either get used as a starting point, or replaced completely at this point. These are my main workflow components I can think of, but let me know if there are any specific areas you'd like more detail on or can think of anything I've missed.

There's a lot in PW (like the Template > Family tab) that is really useful when you get things going, but not really necessary when getting started. It's one of those things that you tend to find once the need comes up. I'd used ProcessWire for years without a lot of this stuff. So it's always a bit of a battle balancing simplicity vs. power. I think it will be good for these tutorials to outline what's essential [to get things started] and what's not. One of the problems I had with EE years ago is that I would get lost in it's endless configuration screens, and not really know what I needed and what I didn't. I'm writing this here so I won't forget when it comes time to expand upon the tutorials.