ryan

What page would you view if you clicked that? The homepage, or something else? If homepage, I'm thinking maybe it should be labeled like "view site".

Stewart, to log a user out, you just need to call $session->logout(); before outputting any data. If you want, you could use your existing login template and do something like this: <?php if($input->get->logout == 1) { $session->logout(); $session->redirect("./"); // start them on a fresh page, or redirect to another } Your logout link should be to: /your/login/page/path/?logout=1

I think that using LazyCron or regular cron (with a PW bootstrapped shell script) is a good way to go for auto-scheduling stuff like this. I'd recommend using an unpublished status for pages that shouldn't appear on the site yet, and then changing them to published once the time is right. Something like this: <?php $unpublished = $pages->find("status=unpublished, publish_date<" . time()); // assuming publish_date is your date field's name foreach($unpublished as $p) { $p->removeStatus(Page::statusUnpublished); $p->save(); }

Thanks Nico, looks good. In a future version, it might be good to have it pull from $config->dateFormat for the date format used in the list. Here in the US we have our dates backwards.

This sounds awesome! Great ideas, definitely just let me know anything I can do. That would be great on mobile devices (if people use mobile devices for this sort of thing). I want to do the same thing for the main PW site and PW basic site profile. What you put in there with the most recent update looks great. Since there isn't actually a variable called $template or $field, I think it's best to label them in a manner that isn't literal and indicates it applies to any individual item of that type, i.e. $any_template->name $any_field->save(); etc. For singular items of a type that do have a literal placeholder in the API (like $page and $user) then I think maybe it's better to use the literal $page or $user, even though all those properties/methods still apply to any $page or $user. Actually they are all there in the API already. There just hasn't been time to add them to the docs. They also weren't quite as high of a priority because they are just filters on top of the $pages API var that enforce pages with a specific template or parent. But I should add these to the API docs... it should be easy since they are all basically the same in terms of the methods they provide.

I'm thinking you want something like this? <?php function listChildrenTree($children) { echo "<ul>"; foreach($children as $page) { echo "<li><a href='{$page->url}'>{$page->title}</a> "; if($page->numChildren) listChildrenTree($page->children); echo "</li>"; } echo "</ul>"; } listChildrenTree($pages->get('/')->children); That would do something similar to the sitemap, but has the first level of pages as root leaves rather than the homepage.

Soma, this is really great. Just keeps getting better and better. It's so useful. Would you mind if I added this to the PW API section? I also have a few comments: I would drop $page->pageNum (deprecated). $page is missing some functions like render(), removeStatus(), isHidden() ... I'm guessing the cheat sheet is missing them because the online docs might be too, so this is something I may need to add. If it's helpful to you for me to add them first, I'll be glad to do that. Seeing the API docs like this makes me think of some things I should add to the API, like a $page->isPublished() function. WireArray now has insertBefore and insertAfter function. The WireArray::has() function can also accept an item of the type that it holds, i.e. $a->has($object) I wonder if PageArray might be useful to have in addition to WireArray. PageArray is the one people are more likely to interact with (and it's a type of WireArray, but with some added capabilities). I kind of think $templates and $template should be split? Right now they are one group. I'm confused by some of the items in the Selector Properties section. I'm thinking some of them don't belong there and may not actually work as selector properties. Instead, i'm thinking something like this (below) and calling out that they are Build-In Page Selector Properties: ? limit=n start=n end=n sort=field include=all include=hidden check_access=0 children.count=n parent=id parent=$page parent=/path/to/page/ path=/path/to/page/ template=name template=$template created=timestamp modified=timestamp ...maybe something like this too? any_field=any value any_field>any value any_field<any value any_field>=any value any_field<=any value any_field!=any value any_text_field=any value any_text_field*=any value any_text_field~=any value any_text_field%=any value any_text_field^=any value any_text_field$=any value In the "Selector Status" section, I recommend listing "check_access=0" rather than (or in addition to) check_access=1". that's because check_access=0 is the one you are most likely to use, as =1 is usually assumed. MarkupPager and MarkupPageFields are modules and wonder if they should be left off? I'm loving this cheatsheet!! Thanks again for your great work here.

Great! Glad that was helpful. I'm thinking we'll have to setup a tutorials board here, as the request for tutorials has come up quite a lot, so would like to do more and more of these.

I've not seen the API like this before. This is really awesome! Gives me new perspective, ideas, and very thankful for your effort here! And its hugely useful, usable and really pretty! Today was a day that I just wanted to work on PW and was forced to work on client rush work all day (like most of this week) and seeing this really makes my day (and week!) Thanks Soma!!

If you want to make one, that'd be awesome–definitely go for it! If you do, let me know if there's anything I can do to help.

The only thing I can guess here is that your version of PCRE doesn't have UTF-8 options bundled into it. I think this is one of those things that is not universally part of all PCRE installs, and I've found the PCRE version sometimes varies even on the same version of PHP. Another route you could take would be to just match all non-word characters up till the http, like this: $page->body = preg_replace("#<p>[^\w]*https://www.youtube.com/watch\?v=([^\s&<]+).*?</p>#i", $replacement, $page->body); There isn't any reason why that shouldn't work, but I won't make any assumptions as these characters are clearly difficult to match and may be affected by the PCRE version since I can match them here but you can't there. Except that Youtube, Vimeo, Facebook, etc., are companies, not universal standards (though I'm sure they'd like you to think otherwise). Companies and their services come and go. My opinion is that anything tied to a company or specific outside service belongs as add-ons rather than native to PW or TinyMCE. So I think this would be a great idea for an add-on module for PW, something that knows how to recognize the URLs for major services and automatically inserts the proper iframe/embed code... sure would be convenient anyway.

I think in this case you'd point both domain.com and campaign.com to the same IP. If your needs were simple, your template file could just check what host it's being served from, i.e. <?php if(strpos($config->httpHost, 'campaign.com') != false) { // display or load something for campaign.com } else { // display or load something for domain.com } If your needs were more complex, then you could create an autoload module to handle your flow control. That module's init() would modify $_GET['it'] that hold's the path to the page requested. That $_GET['it'] var is the means by which PW's .htaccess file sends the requested URL to ProcessWire. Since an autoload module is init()'d before the page is loaded, it has the opportunity to change it, i.e. <?php public function init() { if(strpos(wire('config')->httpHost, 'campaign.com') !== false) { // change path like /about/contact/ to /campaign.com/about/contact/ $_GET['it'] = '/campaign.com/' . ltrim($_GET['it'], '/'); } } Then your campaign.com site structure would just be created below a page named '/campaign.com/' in your site tree. I've not tested this out, but I can't see any reason why it wouldn't work. Also, I'm sure the same thing could be accomplished via the .htaccess file rather than an autoload module, but I'd have to do more research on that before I could post an example.

I like the idea of a quick 1-page reference to PW's API. I actually think we could fit the whole API on a coffee mug. But a 1-page printable PDF API quick-reach document would be great. I will think more about this.

Lets see if we can get a quick-start tutorial going here. We'll start with something really simple and then work up from there. Tell me when something makes sense and when it doesn't and we'll adjust as we go. My thought is that we'd make a tutorial that plays on the 'hello world' phrase and lists information about planets in the solar system, starting with Earth. To keep it simple, we'll assume that the basic site profile is installed, as that's what comes with ProcessWire (so there's no need to uninstall anything). But we won't start using any of it's files tat this stage. Instead, we'll start out by creating our own files. STEP 1 – Create a template file Create a new file called: /site/templates/planet.php, and copy+paste the following HTML into that file: <html> <head> <title>Earth</title> </head> <body> <h1>Earth</h1> <h2>Type: Happy planet, Age: Millions of years</h2> <p>Earth (or the Earth) is the third planet from the Sun, and the densest and fifth-largest of the eight planets in the Solar System. It is also the largest of the Solar System's four terrestrial planets. It is sometimes referred to as the World, the Blue Planet, or by its Latin name, Terra.</p> </body> </html> The above is just a plain HTML file with nothing specific to ProcessWire. We will use this as the starting point for our template, and we'll go back and modify it later. STEP 2 – Add a template to ProcessWire Login to ProcessWire admin and go to Setup > Templates. This page shows a list of templates currently in the system. Click the Add New Template button. On the next screen that appears, you'll see it found your "planet" template file. Check the box next to the planet template and click Add Template. You may ignore any other options that appear on this screen. STEP 3 – Creating a page using your template Your planet template is now in the system and ready to use, but it's not being used by any pages. So lets create a page that uses the planet template. In the ProcessWire admin, click Pages in the top navigation. This is a site map if your page structure. We want to create a new page under the homepage, so click the new link that appears to the right of the home page. The next screen has 3 inputs: title, name and template. Enter "Earth" for the title, and the name should populate automatically. For the template, select planet. Then click Save. Now you have created a new page using the template that you added. You are now in the page edit screen and you should see your title field populated with "Earth". Click the View link that appears on this page edit screen. You should see the output of the HTML from step 1. Click the back button in your browser to return to the edit screen. STEP 4 – Creating a new field Now you know how to create a template and a page using that template. You could create more pages using the same template if you wanted to. But that wouldn't be particularly useful – this template file is just a static HTML file. Lets make it dynamic by creating some fields and adding them to it. We are going to create 3 fields to represent the pieces of data that currently appear in our static template. These include the planet's type, age in years, and a brief summary. We will call these fields: planet_type, planet_age and planet_summary. In ProcessWire admin, click Setup > Fields. This screen shows a list of fields currently in the system, most of which are general purpose fields for the basic profile. For the purposes of this tutorial, we are going to ignore those and create our own. Click the Add New Field button. On the next screen, enter "planet_type" for the Name, select "text" as the Type, and enter "Planet Type" for the Label. Then click the Save Field button. Now that your field is saved, you are on the Field Edit screen. At this point, your field is created and ready to be added to your planet template. Optional: While editing your field, click the details tab where you'll see a select box for Text Formatters. Select "HTML Entity Encoder" – this ensures that characters like "<", ">" and "&" will be converted to HTML entities and not confused as HTML tags. While not required, it's a good practice for text fields like this. After you've done that, click the Save Field button. STEP 5 – Creating more new fields In step 4 we created the planet_type field. Now we want to create the planet_age and planet_summary fields. So in this step, you'll want to do the same thing for the remaining two fields: Create the planet_age field exactly like you created the planet_type field, but enter "Planet age in years" for the label. Create the planet_summary field exactly like you created the planet_type field, but chose "textarea" as the Type and enter "Planet summary" for the label. Note that a "textarea" field is just like a "text" field, except that it can contain multiple lines of text. STEP 6 – Adding new fields to your template Now that you've created 3 new fields, you need to add them to your planet template. In ProcessWire admin, click Setup > Templates > planet. You are now editing your planet template. In the Fields select box, choose planet_type, then planet_age, then planet_summary. You will see each added to the list. Cick the Save Template button. STEP 7 – Editing a page using your template Now that you have new fields added to your template, go back and edit the Earth page you created earlier and populate the new fields that are on it. In ProcessWire admin, click Pages at the top, then click the Earth page, and click the edit button that appears to the right of it. You are now editing the Earth page you created earlier. You should see the new fields you added, waiting for text. Enter "Terrestrial planet" for Planet Type Enter "4.54 billion" for Planet Age in Years Paste in the text below for Planet Summary and then click Save. STEP 8 – Outputting dynamic data in your template file While still in the page editor from step 7, click the "View" link to see your page. Note that it still says "Happy planet" for type (rather than "Terrestrial planet") and "Millions of years" rather than "4.54 billion years". That's because the page is still being rendered with just the static data in it. We need to update the template file so that it recognizes the fields we added and outputs the values of those fields. Edit /site/templates/planet.php and replace the static text in there with tags like this, replacing field_name with the name of the field: <?php echo $page->field_name; ?> If supported by your server, you may also use this shorter format which some people find easier to look at and faster to enter: <?=$page->field_name?> Here is the /site/templates/planet.php file updated to output the content of the page using tags like the above: <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <h2>Type: <?php echo $page->planet_type; ?>, Age: <?php echo $page->planet_age; ?> years</h2> <p><?php echo $page->planet_summary; ?></p> </body> </html> After making these changes, save your planet.php template file. Now view your Earth page again. You should see it properly outputting all of the content you entered on the page, including "Terrestrial planet" for Type and "4.54 billion years" for age. Any changes you make from this point forward should be reflected in the output. STEP 9 – Creating more pages, reusing your template For this last step, we'll create another page (for Jupiter) using the same template just to demonstrate how a template may be reused. In ProcessWire Admin, click Pages and then click the new link to the right of the home page. Enter "Jupiter" as the Title and select "planet" for the Template. Click Save. Now that you are editing the Jupiter page, enter "Gas giant" for Type, enter "4.5 billion" for Age in Years, and copy+paste the following for Planet Summary: Click the Publish button and then View the page. You should now see your planet template being used to output the information for Jupiter rather than Earth. CONCLUSION In the above, we covered the basics of how to develop in ProcessWire, including the following: Creating templates and their associated template files Creating basic text fields and adding them to templates Creating and editing pages that use your templates Outputting the values of fields in template files If all of this makes sense so far, I thought we'd follow up next with a tutorial to take this further: Adding and outputting photos for each planet Creating navigation that lists all the other planets that have pages in the system …and we'd keep building upon the tutorial from there. If you all think this tutorial is helpful, then perhaps this can be a draft for a real tutorial we'll put on the site, so all of your help is appreciated in making this as good as it can be.

Not without installing a module to do it. The LoginNotifier module keeps track of logins in a log file in /site/assets/logs/. I don't know of any modules that log every page edit at present, except for the Page Revisions module I'm working on–though that's not technically a log, but a revision/version system. But all the hooks are there to make very detailed logging possible–good idea for a future module.

Great, that's it then. That also explains why the floats were getting rounded to integers. Now maybe I should go back to floats in the DB, not sure. But I've just committed an update that replaces any commas with periods when it sets the lat/lng values, so hopefully that will fix it regardless of the localization settings. Thanks again for your help testing. The whole family is now up and I'm getting told to turn off the computer. Glad we were able to fix this one.

Interesting. Still can't duplicate here, so I'm wondering if this has something to do with PHP or JS localization. Would a number like 33.7766779 be represented any differently than that where you are? like 33,7766779 (comma rather dot). The module will set the number to blank if is_numeric() fails, so I'm wondering if is_numeric() is failing due to differences in localization.

Try it with the 'u' modifier at the end. Just tested here and it does work. That enables "\s*" to match whatever those odd whitespace chars are. I was also able to duplicate that \s won't match without the 'u' modifier.

Unfortunately I don't know where it could be getting rounded to an integer. There are 3 places where it could be: PHP, MySQL or JS. I'm guessing it's not JS though. Clearly there's some server side precision setting that's breaking the floats. Rather than worry over that, I'm just going to use strings instead. I just pushed an update that changes these to be strings in MySQL rather than FLOAT(10,6). If this doesn't fix it, then I'm really wrong about what the problem is. You'll have to delete your current MapMarker field and create it again since the schema has changed. Thanks for our help in testing this.

There must be some unusual UTF-8 whitespace in there or ascii 160s or something like that. Adding the 'u' (UTF-8) modifier to the end should fix it: $page->body = preg_replace("#<p>\s*https://www.youtube.com/watch\?v=([^\s&<]+).*?</p>#iu", $replacement, $page->body);

Not trying to hide anything. Just figured I should test it a little more before announcing it in the modules forum. But I was thinking I'd post something about it tomorrow. As it is now, I thought it was probably the best example I had of a Fieldtype/Inputfield that has multiple columns of data, and how to create one. Since Rob had these needs in his Fieldtype, I thought it would be useful to post here. I didn't originally plan to make it a Fieldtype, but realized it would translate to a good example or starting point for a tutorial. I can't seem to duplicate the integer floats issue. Just testing here again geocoding various addresses and am always getting the full exact lat/lng. Is there a specific address you are geocoding that does that, or is it any address? I'm wondering if it's getting cut by a float precision setting in PHP or MySQL. I might have to keep these numbers as purely strings from the PHP side to keep out any uninvited float precision settings. But before I do that, I want to find out more and see if I can duplicate here. If not, then I want to at least understand where they might be getting converted. Let me know if there's anything I need to duplicate, and I'll do more research here. Thanks for letting me know.

Tested here too. Seems to work great – nice work Nico! I have a couple of suggestions. For loading/writing to the log file, I recommend replacing this: '../assets/logs/errors.txt' With this: $config->paths->logs . 'errors.txt'; I was also wondering about this: $url = explode('/', substr($_SERVER["REQUEST_URI"],0,-1)); unset($url[count($url)-1]); $url = implode($url, '/').'/'; header('Location: '.$url); Couldn't you just do this instead? $session->redirect("../"); In your getInstalledPage() function, I recommend adding this before the $page->save(): $page->sort = $parent->numChildren; That will ensure it gets placed as the last item on the Setup page, rather than potentially in between Template and Fields. Lastly, take a look at PW's FileLog class: /wire/core/FileLog.php. This is what PW uses to create the log files. It includes two functions that may be handy in a future version of your module – particularly if you ever have to deal with really large log files (which may not be very likely with PW's error log). It includes a get($bytes) function that returns lines from the end of the file, without having to load the whole file. It also includes a prune($bytes) function that prunes a log file down to a specific size, leaving all lines in tact from the end of the file. This is preferable to clearing sometimes as it still leaves the most recent entries in tact. PW doesn't currently utilize either of these functions anywhere but just wanted to let you know they were there in case you ever find them useful. I originally coded them thinking of a log viewing/management utility module.

I haven't been able to test this one out yet– I want to learn more about the Piwik software and understand it all before I install to my server. However, I'm very intrigued by what I've read so far on their web site. I did get to look at your module's code and it looks very well put together in all respects: code, comments and documentation. Thank you for your work with this module. I can't wait to use it and am thinking this is one I will definitely be using a lot on my sites and client sites.

Not sure I understand what you mean about the templates labels in the page tree? But the reason for the name 'label' is for consistency with the 'label' and 'description' used by Fields. In PW, 'description' means something that can either be any length, short or long. Whereas 'label' is implied to be short (word or phrase) just like the English dictionary meaning. We want the template labels to be short so they can be used in select boxes and the like. This also leaves room for us to add a 'description' field to templates down the road (should we want it) that would be consistent with the same thing from Fields. Technically template labels aren't really necessary except in a multi-language situation. So PW will likely keep the label field collapsed by default and one can utilize it if they want to.

Well the good news is that I got my virtual machines going again (a VMWare Fusion upgrade did the trick). But I've only got a few minutes online today because it's a holiday here and not likely to get enough time to test today. Everyone is taking a nap so figured I'd try to catch up with some forum posts while I had the chance. I'm going to be online tomorrow though so will plan to test then. Thanks again for all of your help in tracking this stuff down. Edit: This reply is for both of the IE threads (this one and the one about the link selection0