Leaderboard

You can use WireIncludeFile core function and pass something like $p (Page) as variable into it. In the included file you can use $p instead of $page, so it will be something like $this for ya.

When working with Namespaces, (PW3), it is allowed to use different namespaces in one file. Assuming you have a php file you want to include with this code: <?php echo "<p>I love $var!</p>"; you can have a template file like this: <?php namespace ProcessWire { // ... } namespace fake1 { $var = 'apples'; include('./_namespace-include-test.php'); } namespace fake2 { $var = 'bananas'; include('./_namespace-include-test.php'); } namespace ProcessWire { $var = 'oranges'; include('./_namespace-include-test.php'); // ... } The output will be: Why and how this works is in the PHP manual. There you also can read that this is bad practice.

Have not tried it so no gurantees. 404 page is just a page (though with it's id or name or both hard coded somewhere in the core). It is accessible in the page tree. So try to change the template of that page and write some code in template file to handle your case. Something has to be availiable there, like the url initially requested. But honestly I do not think that throwing a 404 for a product out of stock is a good idea in the first place. Maybe show some message (but with the 200 code) and handle the case in the product template file.

Ok, the latest version comes with the new Console panel that I introduced a few posts back. Here are the key points/features on this panel: Has full access to all PW variables: $pages, $page, $user, etc Works really nicely with fl() calls, but you can also make use of d(), l(), or even simply echo() All output is generated via ajax, and so is virtually instant No need for editing a template file and reloading the page in browser - simply type your code in the console panel for an instant result Only available to superusers Caches code in the filesystem so it stored between page reloads, navigation to other pages, and even browser restarts Note that for those of you upgrading you will need to install the new Process Tracy Console module that is now included. For new installs, this will be installed automatically with the main module. Remember that this allows you to run any PHP code, so be careful! Please let me know what you think. Here are some example calls and their results:

How about printing just the exception's message instead if the whole object?

hi hector and welcome to the forum, this video shows exactly what you are looking for - but it is in german: you should also get the context if you do not understand german also worth to read to get the basics: http://code.tutsplus.com/articles/4-reasons-to-choose-processwire-as-your-next-cms--cms-25062 http://webdesign.tutsplus.com/tutorials/how-to-install-and-setup-processwire-cms--cms-25509 +1 for the tutorial link edit: also this one: https://processwire.com/talk/topic/6388-how-to-create-a-custom-admin-settings-page/ https://processwire.com/talk/topic/12198-modifying-config-property-eg-sitesettings-from-readyphp/ have a look at my signature how to use google to find information about processwire in the forum or on processwire.com: https://www.google.at/search?q=site:processwire.com+global+settings&gws_rd=cr&ei=0ldZV5n9K9G0gAaq_pOYDw#q=site:processwire.com+settings

Thanks @monchu and @Robin S - I have checked here and also see the problem based on deleting the default Find Lister. I have posted a Github issue: https://github.com/ryancramerdesign/ProcessWire/issues/1868

included_file.php <?php $fruit = 'banana'; echo "<p>My fruit is a $fruit</p>"; main.php <?php $fruit = 'watermelon'; call_user_func( function() { return include func_get_arg(0); }, 'included_file.php' ); echo "<p>My fruit is a $fruit</p>"; Output: <p>My fruit is a banana</p> <p>My fruit is a watermelon</p> Credit

I had this problem, and I believe it's caused by deleting the default lister (aka "Find"), which is something that becomes possible when Lister Pro is installed. If you have done this the solution is to create a new lister called "Lister". Because the default lister is used by the core it would be better if Lister Pro did not allow you to delete it, but instead made it simple to disable it for non-superuser roles. If you have other Lister Pro instances and you don't want certain roles to see the default lister you have to set up a special permission for the default lister and then not apply it to a role. There's definitely scope to make this process a bit clearer and easier for Lister Pro users.

I would like to take issue with this as well. It’s awkward for non-superusers not to find pages (or other users) they can otherwise reach, and I don’t really see why this restriction is in place by default. It is also not easy to implement a hook to change this behavior, which would be trivial to do the other way around. I.e. if the “include” parameter weren’t overridden by the Process function, that feature could be retrofitted like so: wire()->addHookBefore('ProcessPageSearch::executeFor', function($event) { if(!$this->user->isSuperuser()) wire()->input->get->include = 'hidden'; }); As well as any other custom restrictions one might need to respect custom roles and permissions. However, as it is now the restriction is hardcoded into the function and I’m not sure how to modify it in a non-destructive manner. Are there security reasons for the way it’s currently done?

Welcome to the forums Mr. yuters! Just a guess... the files might not be actually added to WireArray untill the page is saved. So try $this->pages->addHookAfter('save', $this, 'adminFileAdded');

Thank you for your hint...but i'm a just a poor spare time programmer...so very often in the late evening i don't get things sorted right It happens often that if i hit the "Post" button i change my mind and get the solution by my self.... $form->get("somefield")->required = true; // add only CSS class required to the field so simple get the "*" - NOT change the form processing/handling like // you set the field to required in the admin>field>settings!! Basic problem was the pass (password) field from the user template....in the admin i don't wanna change it to be required so i have to fill in on every change of the other user fields....and i have frontend forms to edit users profile...so on this frontend stuff i have to check for this field myself on processing and all is good. // get the input values for processing $email = $form->fhValue("email", "email"); $password = $form->fhValue("pass", "text"); // check for email duplication if (email_valid($email) == true) { // email exists $out .= message("email exists","danger"); } elseif ($password == ''){ // no password is there $out .= message("forgot to enter password","danger"); } else { //... // all is there so go process form Best regards mr-fan BTW i can't say it too often - your modules for Forms are really really great - have you known that the FormHelper Module even renders MapMarker Fields on frontend....usable!!

This is the first time I heard of this module and it's freaking nice, thanks!

Hey Teppo, Thanks for the fast response. Your correct in that it was the $login_date which was causing the issue. In the LoginHistory settings for 'Date Format', I had inserted a character (-) separating the time and date. Just removed this and works fine again. Thanks for your help!

Hi Hector, Welcome to ProcessWire and the forums. Best to begin here: http://processwire.com/docs/tutorials/

There is nothing like that in ProcessWire's backend. Almost everything is stored in pages and if you need such a section just create a template and a (hidden) page (e.g. named settings) and use it. Another option is to extend the $config variable (site/config.php) with custom properties. There's also a module, which allows you to change those properties in the backend, but it's not as flexible in terms of UI as a page with custom fields would be.

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

This module extends WireMail base class, integrating the PHPMailer mailing library into ProcessWire. Module Directory - Githup repo

Hi All, While editing a template (any template) then if I click the Usage section, there is an error notification Unrecognized path and the process returned no content. If someone can help give me a clue how to fix this error. I'm not sure what is the cause of this error. 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/

Hey folks, If I search for a page that is unpublished it can not be found by using the ajax search in the right corner in admin. It can only be found when I am logged in as a Superuser, but not if I am logged in as an Editor (who has page-edit rights!). Searching through lister works - but only if I choose to only search unpublished pages; but not via the ajax search at all. I already looked at the process page search module file and there is a line that allows unpublished pages to be searched if someone has paeg-edit rights, but somehow it does not work at all. Can someone help? Thank you so much!

Hey gentlemen! I just happen to need this kind of js on a project of my own and am experiencing some trouble with implementing it. So please post the solution here if it is possible. Or just do not go private .

I'm not sure if there's really a better way to do this, without potential for breakage. $pageNum = 1; $limit = 20; $start = $pageNum - 1 * $limit; $base = "template=news, id=$mySearchedPage->id"; while($pages->count($base . ", start=$start")){ $count = $pages->count($base . ", limit=$limit, start=$start"); if($count) break; $pageNum++; $start = $pageNum - 1 * $limit; }

This is the one I have always liked: http://jeffreysambells.com/2012/10/25/human-readable-filesize-php But I would also vote for an option to automatically calculate the number of decimal places / significant figures.

I am sorry but I can't reproduce your issue. A fresh install of PW-2.4, with some image fields in the home template, and an upgrade to PW-2.7.2 everything work as expected.

Thank you adrian for your links and information. This will do fine for me at the moment. by the way, this is what apeisa answered:

Thanks for reporting this, @grimezy! One issue I can see right away is that date_diff() can indeed return "false" on failure, and this case is not properly handled by the code visible above. Real question, though, would be why this happens. Mostly guessing from the error you're seeing and the code visible above, most probable cause would be some kind of an issue with $login_date, which in turn could either mean that login_timestamp row in database is empty or contains something unexpected.. or it could mean that $date_format is somehow broken. I was unable to reproduce this issue based on a quick test and I'll have to step away for a few hours now, but I'll try to debug this further (hopefully) later today

After digging a while I found out it has to do with namespace. "is_callable() doesn't seem able to resolve namespaces. If you're passing a string, then the string has to include the function's full namespace." found here: php.net/manual/en/function.is-callable.php#107105 $featured->each('\ProcessWire\preparePost'); // works $featured->each(__NAMESPACE__.'\preparePost'); // works $featured->each('preparePost'); // works ONLY if no namespace is declared I posted an issue on github: https://github.com/ryancramerdesign/ProcessWire/issues/1869

Did you seached the form api related topics here? Additional features / attributes Markes with "fh" linke "fhValues". Set form attributes, CSS and so on is form api related.

I found the problem, when i add a <base> tag inside <head> tag, this problem appear.

v016 was uploaded today to GitHub: enable setting template latte file with/without extension ($view->viewFile = 'basic-page' and $view->viewFile = 'basic-page.latte') $view->json_encode returns JSON encoded string/markup. Possible values are true and PHP's json_encode options (eg. JSON_PRETTY_PRINT). if "viewFile" begins with "//", $config->paths->templates and viewDir is not prepended to the view path These updates make it easier to get Ajax results, and allow placing latte files outside templates/views directory. The latter was also possible earlier using relative paths ("../"), but now it's more flexible. Getting json output was only possible using wireRenderFile() and applying json_encode() manually, which was less convenient.

Hi, http://php.net/manual/en/function.include.php "When a file is included, the code it contains inherits the variable scope of the line on which the include occurs. Any variables available at that line in the calling file will be available within the called file, from that point forward. However, all functions and classes defined in the included file have the global scope." "Is it possible to have variables valid for the included file alone?" So I suppose the answer is no.

I'm mainly thinking about the way ProcessWire makes it possible for third party modules to alter the source of a page, inject their own scripts or styles, etc. While this does require a lot of trust in installed modules, it's also something we wouldn't want to disallow. Inputfields are another thing consider: many third party inputfields rely on existing libraries, in which case the implementation details are more or less out of our hands. Unless I'm missing something obvious, CSP would mostly be useful if users were able to inject their own scripts or styles for other users to see. In order to do that, you'd either have to be a superuser and use some rather specific features to achieve this, or exploit a third party module that allows this. Latter option is absolutely something to consider, but the first one not that much: generally speaking we consider users with access to the admin interface "trusted"... and superusers even more so. While we could introduce a method of "registering" embedded content with the system, I'm not entirely sure if that's worth it. It could make the lives of perfectly legitimate developers more difficult, while the benefits are — in my opinion — somewhat questionable. It's also good to keep in mind that this isn't something that would protect you from malicious / hacked third party modules: a module could simply hook into an earlier (or later) point in program execution and override any CSP rules you've got in place. That being said, I'm not against the idea of implementing this as a configurable option. It would no doubt be possible for ProcessWire to generate nonces for any inline content it requires, and as long as this would be a configurable setting, it shouldn't come as much of a surprise if some third party features stopped working afterwards. I don't see this as such a big thing and I'd imagine the potential use cases to be limited, I for one would be OK with this as long as it doesn't needlessly complicate things ?

You don't need anything like this. Just make sure that your php files are really stored in utf-8 encoding!! (PHP files you need to check in this reagrd are: the calling template file(s), the WireMailSMTP module files and the base WireMail files) Normally they all should be in utf-8 encoding, but better you check this thouroughly. Then it works with simply using: $subject = 'Ö Ä Ü ö ä ü ß'; I tested this just yet. The source of the received email looks like: Subject: Wiremail-SMTP Test 15:57:23 =?UTF-8?q?=C3=A4=C3=B6=C3=BC_=C3=84=C3=96=C3=9C_=C3=9F?= X-Mailer: ProcessWire/WireMailSmtp Date: Wed, 8 Jun 2016 13:57:25 GMT +00:00 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It does automated encoding, but you don't have to do anything by yourself.

see: https://processwire.com/talk/topic/13373-switching-hosts-may-25-at-noon-est/#entry121251

Got more plugins, but recently discovered ToDo Review (thanks for the mention OrganizedFellow!) and really love it..always tried to find a way to organize some code notes/todo's but using a separate note app didn't work out because I forget to review it^^ Then I was in the process of writing a little PHP script which would scan project files for @todo and create a website, while coding a stumbled upon the ST3 plugin..yeah

Here you go: new InstagramFeed version 1.0.0 add required scope public_content to retrieve tagged media with getRecentMediaByTag('tag') (thanks @gebeer) add ProcessWire 3.x compatibility add endpoint to get a list of recent comments on a media object: getRecentComments($media) Example: <?php $feed = $modules->get('InstagramFeed')->getRecentMedia(); ?> <div class="instagram> <?php foreach ($feed as $media): ?> <?php if ($media['type'] === 'image'): ?> <a href="<?=$media['link']; ?>" class="instagram-item"> <img src="<?=$media['images']['thumbnail']['url']; ?>" alt=""> </a> // display comments <?php $comments = $modules->get('InstagramFeed')->getRecentComments($media); ?> <?php if ($comments): ?> <ul> <?php foreach ($comments as $comment): ?> <li><?=$comment['text']?></li> <?php endforeach; ?> </ul> <?php endif; ?> <?php endif; ?> <?php endforeach; ?> </div> A comment ($comment in the example above) contains the following data: "created_time": "1280780324", "text": "Really amazing photo!", "from": { "username": "snoopdogg", "profile_picture": "http://images.instagram.com/profiles/profile_16_75sq_1305612434.jpg", "id": "1574083", "full_name": "Snoop Dogg" }, "id": "420"

Coming from a Rails background years ago, I think it's best to stick with web application frameworks for any web applications that will have heavy iterations and multiple team members. With a webapp framework, you get a testing suite, migrations, ORM, REST, MVC, specific deployment tools and many other necessities. You would have to re-do all those with ProcessWire. Furthermore, using pages to act as a router doesn't feel right. "Use the best tool for the job" and all that.

If you're interested in running ProcessWire using PHP's built in Webserver this one's for you: <?php /***************************************************************************** * Router script for emulating Apache's "mod_rewrite" functionality. * This router script is designed for testing ProcessWire instances quickly. * Don't use this script and/or PHP's built in Webserver in production. * * Usage: php -S localhost:8000 -t /ProcessWire /ProcessWire/routing.php *****************************************************************************/ $uri = urldecode(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH)); if ($uri !== '/' && file_exists(__DIR__ . $uri)) return false; $_GET['it'] = $uri; // emulate index.php?it=$1 require_once __DIR__.'/index.php'; Enjoy!

Module in development and this solved the current issue https://github.com/adrianbj/ProcessMigrator/issues/4

Hi, Are we talking about ProcessWire 3.x? Then it might be the namespace issue. The easiest way to fix it is to start all your template files, _func.php, _init.php, etc... with <?php namespace ProcessWire; More on this: https://processwire.com/blog/posts/processwire-3.0.14-updates-file-compiler-fields-and-more/

Hi, I think your question has already been answered in a different topic here: https://processwire.com/talk/topic/11955-page-field-based-on-parent/ As suggested there, you might even want to use the AJAX way by using the custom selector (instead of custom PHP). In your case that should be something like: parent=page.project_research_field_selector I hope this helps.

These work great! I would much rather do it this way and use pdo. This is the working code I am using: $statement = wire()->database->prepare('INSERT INTO tablename (comment) VALUES (:comment)'); $statement->bindParam(":comment", $comment); $statement->execute();

@joer80, You should be able to use the PDO prepare(), bind() and execute() methods. Here's a short example; $statement = wire()->database->prepare("INSERT INTO `tablename` (`comments`) VALUES (:comment)"); $statement->bindParam(":comment", "The boat is 17' long. "); // Defaults to binding as a string. $statement->execute();

I'd recommend using prepared statements. ProcessWire's database class extends mysqli, so you can do: $statement = $this->database->prepare('INSERT INTO tablename (Comments) VALUES (?)'); $result = $statement->execute(array($comment)); (This is written off the top of my head, not tested)

Maybe you have an autoload module or an init file somewhere that puts the output formatting off.

Add this to /site/ready.php: <?php namespace ProcessWire; // modify longclick duration $page->addHookAfter('render', function ($event) { if ($this->page->template != 'admin') return; $js = <<< HTML <script> $(document).ready(function () { if (jQuery && jQuery.longclick) { jQuery.longclick.duration = 2000; } }); </script> HTML; $event->return = str_replace('</body>', $js . PHP_EOL . '</body>', $event->return); });

As any javascript feature you can surely use this with processwire. Nobody does care how you create your markup and if it comes from an index.html or any server side scripting.

Just in case someone stumbles across this in the future - forceLogin() is now available (since 2.6.8): https://processwire.com/blog/posts/processwire-2.6.8-brings-new-version-of-reno-admin-theme-and-more/#new-session-gt-forcelogin-user-method-to-login-user-without-a-password

Thanks for the question @tinacious and answers @all, it's a reminder for me to do this stuff before I go live, can't have too many of them... Thanks for the list @formmailer, the only two I would add are: don't forget that you can have two config files, one to control your local (MAMP XAMP etc) environment (inc' db credentials etc) and another for the live/remote, see Maintaining a separate development configuration file. This is not really a thing to do at go-live time, but seemed worth noting in this context once you have two config files, for your local file only, enable "$config->debug = true;" — I have just started doing this and already it uncovered something slightly dirty in my PHP for me to tidy up. This ability to maintain local and remote configs is for me yet another differentiator for PW where something small yet really useful in the real-world has made it into production, a testament to the thought and care gone in to this product. PS: UPDATE: I just remembered that assuming you use the above dual config files setup you need to configure your FTP client to not transfer a file called config-dev.php or the remote env' thinks it is a dev env I just tripped myself over with that.