Leaderboard

ok well yes, i was apparently running an older version (weird, just downloaded this from modules directory), but no idea how i had an out-of-date version, and the upgrades module shows nothing about this module... so this is fixed, by upgrading manually to the version on github

Any chance you are running an old version of the module. That method is no longer used: https://github.com/horst-n/CroppableImage3/blob/e87b602cffbbdd648a48aa7a4975f927ff58f4d7/FieldtypeCroppableImage3/FieldtypeCroppableImage3.module#L80-L81

just popping by to say that Tracy made it possible for me to convert an old site where i was using direct output, to a delayed output model, which i needed to be able to handle the new requirements of the site; in particular, the template path feature was crucial – i was able to simply duplicate each template one at a time, rename to -dev, and work on the conversion until it was ready... Also the new styling looks great!

Configurable. I have seen mock-ups around the forum which have a Windows Explorer (never thought I would bring up MS to make my point) kind of sidebar. Which shows the tree on the left and the editting screen on the right. It was based on another CMS. I can imagine if you have very nested structure with very long titles this might not be very handy. On the other hand I've seen (lesser tech savvy) clients struggling with the connection between the tree and the edit screen. To others it is instantly clear.

'Passenger Drones" sounds like a good name for the next Angular type JS framework.

Hi @theo - this looks related to (https://github.com/adrianbj/ProcessMigrator/issues/4). What commit are you using? Please try this one (two back from current) - https://github.com/adrianbj/ProcessMigrator/tree/3e2121b8fdb68e9d9dc0c6aca8aae75e923a2669 I will likely recreate this module in the future after Ryan fully implements the new core methods for exporting/importing pages http://processwire.com/blog/posts/roadmap-2017/ I just don't have the time to put more effort into the current iteration of this, especially given that future versions should make use of the new core features.

SSL everywhere. Google is pushing HTTPS sites up in their results now. should we all be using HTTPS? and are you now and how?! also this was a great wake up call for me: http://shoptalkshow.com/episodes/250-web-security-april-king-alex-sexton/ For me I'm using Digitalocean and Serverpilot and it was a matter of enabling the Let's encrypt script so supppppppper easy (full disclosure, those two links have affliates)

Welcome to the forums @looper . You'll need to upgrade to at least ProcessWire 3.0.46 for that feature according to the docs here.

Ah man, this is awesome. It'll make it a lot easier to use Processwire as the CMS for a front-end not built on Processwire. =D

Thanks! The old method is better to forget, the module is the way to go. The latest filters and latte-only template files make templating even more enjoyable. Recently I updated an earlier site of mine and I could throw off about half of the template files and the code is also much cleaner/maintainable.

This should be the keyword here. Also meaning a related API dedicated to support custom configuration options as well. No one likes to reinvent the wheel I guess, so some sort of "sub-theming" or better yet transportable settings and customizations would be nice to have instead of two or more completely separate admin themes.

Another minor (but hopefully useful addition) - you can now use keyboard shortcuts to move between items in the console panel history stack. Back: CTRL+CMD+↑ Forward: CTRL+CMD+↓ The up and down arrows are to mimic unix based terminal history shortcuts. Unfortunately I had to add the CTRL+CMD in there as well because it's hard to find a combination that isn't already used for something else, either by the browser or ACE editor. Anyway, hope you will find it useful for speedy switching back and forward between snippets of code you have recently run.

A few updates to the server type indicator ribbon: It's now possible to display it on the frontend as well. It might seem weird, but on occasion I have been looking at the frontend in the wrong tab (live vs dev) and wondering why my changes aren't doing anything You can now hide the indicator along with the Tracy debug bar when you use the hide icon. Here is the css to use if you'd prefer to have the indicator along the bottom: body::before { content: "[type]"; background: [color]; position: fixed; left: 0; bottom: 0; color: #ffffff; width: 100%; padding: 0; text-align: left; text-indent: 5px; font-weight: 600; text-transform: uppercase; z-index: 29999; font-size: 15px; height: 22px; line-height: 22px; pointer-events: none; } which looks like this rather than the default sidebar. It is of course also fixed so it always visible when you scroll.

Hi all. For a while now been wondering how many would be interested in a backend and frontend shop catalogue built on top of PadLoper? I've previously spoken to @apeisa about this and his take is that there are no plans to develop PadLoper in this direction but he's happy to support such efforts. The gist of the backend shop catalogue is to provide one place (think ProcessModule) where you can manage your PadLoper products - add, edit, delete, track sales, etc without having to set up the underlying structure yourself. The frontend would be like a shop/webstore profile, a frontend cart basically, that's customisable. The shop would be 100% powered by PadLoper. This means that to use the 'shop catalogue' would require that PadLoper is installed. These are just loose ideas at the moment for a pro module. This might or might not see the light of day depending on feedback. Anyway, would love to hear thoughts, thanks.

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/

Madness! Would you get into one of these?!! http://www.bbc.co.uk/news/technology-38967235 https://www.engadget.com/2017/02/13/ehang-184-passenger-drones-dubai/ Aah, just letting off steam..

If it does not take off then why not? However if it does, I do not even want to be nearby... I do NOT trust software as I've already seen some in operation

@Macrura thanks, I can confirm that I no longer have the issue after downloading the module from Github manually.

Hi @Adrian Yes, 0.6.9 seems to work better than 0.7.0 Thank you!

Seems like a futuristic surveillance/monitoring repression drone. No protections around the propellers. For the moment, I'd rather try something like the Vusion 250 Extreme FPV Race Pack, for example. Or a flying car like the AeroMobil, for instance.

Sounds like a namespace issue because bootstrapped files don't get run through the file compiler you will either need to add namespace ProcessWire; to the top of the file, or do: $page = new \ProcessWire\Page(); to reference the ProcessWire namespace

one of these was upgraded from the old cropping module to the new one, and one was started on 3x branch, and just added the cropping module; the module was probably installed after the upgrade to 3.0.52; not sure if any of those things make any difference; I can get you access to the admin and the FTP - i'm assuming you need both; will PM you in a bit.

yeah, when i first started the conversion, i was basically scratching my head about how hard/complex it would be to change from direct to delayed; At some point along the way i remembered the tracy template path, and after that it just went really fast.. now that site's code has been completely refactored and it's so much cleaner!

The custom PHP option in @Robin S' module (http://modules.processwire.com/modules/custom-inputfield-dependencies/) should make this possible.

3b. Or PHP's DOM Parser .

Yes...it is.

I can't tell from your first post what you're trying to do. $coaches = $pages->find("template=coach, sort=coach_locatie"); This gets all coach pages, regardless of province. If you want the coaches for a single province you include that province in your selector: $friesland_coaches = $pages->find("template=coach, coach_locatie=Friesland"); You can put the coach pages in any order that suits you - the point is that you don't want to make coach pages children of province pages if a coach may belong to more than one province. Otherwise you get into a situation where you need duplicate copies of coach pages under more than one parent. You can just put all your coaches under a parent called "coaches" and then set any attributes for them such as province using a Page Reference or Options field (a Page Reference usually works out being more flexible in the future). If there is going to be a front-end page "Friesland" that lists all coaches for Friesland then a Page Reference field is definitely preferable to an Options field.

You can always use the cache for time/resource demanding code and you can update it with a cron or hook so users never get long load times.

Thank you! I've been missing it

Did you check the template id of the repeater template against the template_id specified in the data column in the "fields" table for the repeater field? And of course remember that repeater templates are named: repeater_repeaterfieldname

Not planning on it - just trying determine whether the post actually belongs in the PW forums or not

Aah, good to know .

As a personal experience I would not recommend taking equity only projects. They are too risky.

Sanitization does not have much to do with queries per se. You sanitize user input not the query. And to answer the question about automatisms. When editing a page the fieldtypes of the fields add their own sanitisation based on how things are set up (see Fieldtype::sanitizeValue and child classes). Elsewhere there's nothing automatically sanitized.

In my last couple of projects I've used a hacked version of this module with an extra field for inputting image map coordinates. With a little snooping around and a good dose of patience my lack of module building knowledge didn't stop me So now this shopping centre's website has a store locator where you can hover hotspots, the marker appears in place and everything is configurable in the CMS. Before this was a Swiffy converted flash object. Here's the result in the frontend: http://www.miramaiashopping.pt/lojas/ And here's what it looks like in the CMS: Now I do have another project where I also have to add hotspots to an image for showing some text. But for that the module needs some serious work. I'm just going to make subpages of a type that only has a body field and use that. It would be cool to have this work like a repeater where you have full control of the fields for each marker and only link to pages if you need to, but that would mean rebuilding from the ground up.

@bmacnaughton. That's not what I meant. What I meant is that ProcessWire offers you a number of tools to sanitise values. Depending on whether you are a frontend developer vs, say, a module developer, you will probably be using a subset of tools more than another subset. In other words, at the end of the day all input should be sanitised; the tools you use will vary depending on the job at hand.

Hey Kongondo, I think 3rd-party admin themes will be even easier than before. What I meant was that since Reno is kind of a core theme, it doesn't make sense to develop it separately *if* — and it's still a giant *if*— the new default theme allows you to configure a setup that is basically the same as the current Reno theme. We are deeply invested in the Reno theme here, so either the new admin will be customizable to something very similar, or I'll keep developing Reno as separate theme. I have some things I'd like to implement that UIKit will make easier, and I'm excited to dive in once Ryan has a stable base theme to work from.

Hey @renobird - I have one site that is 5 levels deep and I think it would be great. How many levels are you thinking would be too many? What do you think the issue is with too many levels? Maybe I am just not seeing what the issue would be yet? Maybe long page titles (like journal article titles) would be a problem?

I've to agree with adrian. I'd also like to see api access to those theme colors, so if one does need to add custom styles in modules, they update with the theme settings.

Just my 2 cents, but I'd rather see just the one official admin theme that supports top and side menus. The key thing is that I'd like to have that official theme easily skinnable. I would love the options to color and style the theme with CSS while keeping all the html and php standard. The problem with some of the third party themes back in the early PW 2 days was that new features added to the default theme never made it to the third party themes. I'd also love to see the page tree in the sidebar and the other menu items (setup, modules, access) in the top menu. I am not certain, but I think now that the page tree is cached it won't be a performance issue to have it in the sidebar anymore?

Hey @bcartier and everyone who is following. I implemented a basic language support. Nothing really changed, except now with LanguageSupport enabled in your ProcessWire app, the GraphQL api will return the content in whatever language the user is assigned. In addition, when Language Support module is activated, there is a language field in your GraphQL api. So you can request the exact language you want. It looks like this. { language(name: "de") basic_page{ list{ title summary } } } You need to put the language field on the top. Well, not exactly on top but just before fields that return translatable content, like title, headline, body etc. It's because GraphQL processes requested fields from top to bottom and it will not know what language you want till it gets to language field. Did you also know that in GraphQL you can query same field multiple times with aliases? Here, take a look at this { basic_page_default: basic_page{ list{ title summary } } language(name: "de") basic_page_de: basic_page{ list{ title summary } } } Curious what will be the response? Try this with site-languages profile and find out.

Hey, @VirtuallyCreative! The first thing that occurs to me is that you're echoing the $item li before you check to see if it has children, after which you're also echoing the $item li, and that's what is causing the top-level duplication. You could handle this a few different ways, but whatever approach you take, you basically want to determine if $item has children, and, based on that, decide what href to use and whether or not to include the arrow. I haven't tested this to see if it works, but something like this might give you a place to start: // top navigation consists of homepage and its visible children foreach($homepage->and($homepage->children) as $item) { echo "<li class=''><a href='". ($item->hasChildren() ? "javascript:;" : $item->url) ."'><span class='title'>$item->title</span>"; if($item->hasChildren()) { echo "<span class='arrow'></span></a><span class='icon-thumbnail'><i class='pg-form'></i></span>"; //loop through the top navigation child's children pages and output them as nested menu item foreach($child->children as $childitem) { echo "<ul class='sub-menu'>"; echo "<li class=''><a href='$childitem->url'>$childitem->title</a>"; echo "</a><span class='icon-thumbnail'>"; echo substr($childitem->title, 0, 2); echo "</span></li></ul>"; } } ... Hope that helps! If it doesn't work as expected, or if you have any questions about it, let me know. That first echo statement uses PHP's ternary operator for a shorthand if. If you aren't familiar with this, here's a pretty good article that covers the basics. Good luck to you!

@Nurguly Ashyrov, this is really awesome. My front-end work is mostly JS/SPA work these days and I learnt to love the “headless”/“api first“ approach of commercial CMSes like Contentful. So I often thought about what a perfect and easy to manage back-end ProcessWire would be with a solid HTTP-based api built right in to allow uncoupling actual front-end/ui parts like admin and user interfaces (as actual self-contained apps) from the CMS itself. A module like yours makes a huge leap in this direction and will make ProcessWire much more interesting for a lot of front-end devs and e.g. as a flexible and fast to set up back-end for app prototyping/mvp development. A pity this didn’t exist 9 month ago!

Would be nice to know, if you can use this as a feature It would make a custom front-end login with email easier (if you make sure email-address updates are reflected to the username as well).

Interesting layout but it works However, at first I was stuck because I didn't know where to click. Finally I found the Projekte in the Menu - I think there should be at least a link or a button on the Home page linking there. Also the images seem too heavy.

$input->whitelist does not store values. It does just mark $input variables of the current request, so they can be appended to (pagination) links as ?my_data=xyz variables, which on the next request can be read again. If non of those links is clicked the values are gone. The most prominent use case is preserving any user filter values while going through pages of results. Having the values in the url also makes sure you can send that url to your peer and he or she can open it as well. Anything you don't want the user to see/modify you'd use the session.

I recently discovered an app that maybe help you on that, it's called Blackfire https://blackfire.io See a screenshot of an example from its website. Install on your server (or local) and give it a try and maybe compare with @teppo's diagram above. Edit: this is a Symfony app, and not mine, just to clarify.

I posted something like this a few years ago, but that's obviously not up to date with current versions of ProcessWire. Would be interesting to create an updated version and compare these side by side, just to see how far we've come since then

Here are two macros that I started to use recently to avoid passing full page objects and make things easier. I usually set "common" pages in ready.php like this: // Pages $view->homepage = $pages->get(1); $view->contactPage = $pages->get(1033); // PageArrays $view->menuItems = $pages->find('id=1010|1020|1030,sort=sort'); But instead of this I set only ID (selector): // Pages $view->homepage = 1 $view->contactPage = 1033; // PageArrays $view->menuItems = 'id=1010|1020|1030,sort=sort'; Now in latte template files I use the macro "n:page" or "n:pages", which automatically sets the "$p" variable ("$pArr" in case of n:pages). Basically it sets the context: <a n:page="$contactPage" class="contact" href="{$p->url}">{$p->title}</a> <ul n:pages="$menuItems" n:inner-foreach="$pArr as $p"> <li class="{$p|activeClass|noescape}"> <a href="{$p->url}">{$p->title|noescape}</a> </li> </ul> You can use this if you prefer "normal" macros instead "n:macros": {page $contactPage} <p>{$p->httpUrl}</p> {/page} And here are the macros (put it in site/ready.php): $view->_addMacro['page'] = array( 'page', '$p = \ProcessWire\wire("pages")->get(%node.word)', ';' ); $view->_addMacro['pages'] = array( 'pages', '$pArr = \ProcessWire\wire("pages")->find(%node.word)', ';' );

Auto https does have the disadvantage, that as soon as there's some issue with the certificate the site is essentially down, even though it's running fine via http. As processwire.com is mostly running with guest users and mostly there to supply public information I'm not sure it that's worth the hassle to disallow http.