ryan

Sure, I'll be happy to add this. I've added it to my list here: https://github.com/ryancramerdesign/P21/issues/51 So far I haven't come across any characters that need to be translated differently from language to language, but I've been wondering if they are out there. I'm guessing not, considering the relatively small scope of a-z 0-9 ascii. But if so, we will need to move this into a config option as you suggested (though we may do it either way).

If it's possible to create a separate textarea field (with no textformatters) for handling this need, I would suggest doing that. At least, that's what I usually do. Tags like <script> <object> <embed> are kind of like EXE files on a PC in that they are usually legitimate, but can occasionally be malicious. So it's one of those things that I don't like clients pasting into a TinyMCE field because they may not even be able to see that it's there (short of the HTML view, which few know how to use). Using a plain textarea for the specific purpose of handing these tags isn't any better from a security standpoint, but at least it's always done with intention and you always know it's there. As an example, on processwire.com I have a plain textarea called video_embed where I paste in youtube/vimeo embed links. If the page sees the video_embed field is, then it outputs that above the bodycopy. If using a separate field for your object/embed isn't an option, then it should still be possible to make it work with TinyMCE. It seems like your object and param tags are consistent with what's in your valid_elements, so it's not immediately clear to me why those are being stripped. Can you paste in the resulting HTML after it's been stripped? But your embed tag doesn't have any attributes assigned to it, so I can see why that one is getting stripped. If it helps, here is what's in TinyMCE's documentation for valid_elements of these tags: object[classid|width|height|codebase|*],param[name|value|_value],embed[type|width|height|src|*] If that doesn't work, it's also worth trying the object/embed/param from their full XHTML valid_elements set too: http://www.tinymce.com/wiki.php/Configuration:valid_elements

I decided to make the 'forgot password' function optional, and disabled by default. I would say that more than half of all installations simply don't need it. Then there are others that really need it. A good security best practice is to never have any more submittable forms running on your site than you absolutely need. So I figured we'd provide this 'forgot password' function for those that want it, and keep it off for those that don't. I'm not suggesting there are any security concerns with using this function. Only suggesting that every form (especially login/pass-related ones) can be sources of unwanted traffic consuming server resources.

I did a silent soft launch of the PW 2.1 final version on Friday, and changed all the readme files and site copy to reflect v2.1 as the current stable version. So version 2.1 is now officially out as the current/recommended/stable version! I don't yet have the Skyscrapers demo site updated to 2.1 (though it will be the first to use the upgrade script). I also want to get a video done that outlines everything new with 2.1 vs. 2.0. Once those are ready, I figured we would send off a press release to to all the applicable sites and get the momentum going. Beyond the obvious user system updates, template enhancements and ajax uploading, are there any areas that you all think I should cover in the video?

Amazingly these are just the accounts that get through the 1) Captcha image (on most difficult-to-read setting), and 2) email verification. I don't know what the purpose is, but apparently a lot of forums get hit with these same accounts because stopforumspam.com nearly always recognizes them. A large amount of our spam accounts come from China for some reason. I don't think we have any legitimate current ProcessWire users in China (?) right now, but I'm hopeful we'll have lots in the future.

Great site Nikola! Nicely done. Thanks for posting this. Amazing this is your first site with PW, looks like you are already a pro with it.

Good idea. I think we're going to get much deeper into locales and internationalization very soon.

Strangely I couldn't get it to work before (must have been something up with my browser). It works great now. Seems like quite a nice solution they've got here. What's your opinion of this vs. Aloha?

Great job! I look forward to trying out this module. Thanks for the great screencast too.

I'm interested to know what you find here. I'm no expert with JS debugging, so ignore this if it sounds obvious. Placing a console.log(event) in your onchange event handler may make it easy to find, but might not help much if the page gets immediately loaded/reloaded. So an old fashioned alert() after a console.log of the event will pause everything and might make it possible to see what is doing the change.

Marty, looks good except that page reference fields in a selector expect a page ID (number). If your $urlcat variable represents the page ID, then your example will work. However, I'm pretty sure that's not the case in your example. Also, I don't personally like using page ID numbers in URLs, much preferring to use the name, which is more meaningful. So assuming you agree, here's what you'd want to do (below). This is your example, but I just added one line: <?php if($input->urlSegment1 == 'categories') { if($input->urlSegment2) { $name = $sanitizer->pageName($input->urlSegment2); $urlcat = $pages->get("/categories/")->find("name=$name"); // this is the only line I added $notes = $pages->get("/notes/")->find("template=notes, sort=-publish_date, note_category=$urlcat"); foreach($notes as $note) { echo "<p>{$note->title}</p>"; } } }

PW will adapt wherever you put it, whether on a subdirectory, different domain, subdomain, etc. You don't have to tell it anything about where it's running because it figures it out at runtime. It's a little harder to design the CMS that way (which is why most CMSs don't do it), but I think it's well worth it. Likewise, it doesn't care whether it's being accessed by HTTPS or not unless you specify that you only want one or the other in your template settings. Because you are using a different domain for HTTPS, you'll want to skip using that template setting and instead do this: To detect if the request is coming from an HTTPS connection: <?php if($config->https) { // user is on an HTTPS connection } else { // regular HTTP } If you wanted to logged-in users to always redirect to the same page at a different domain, you'd do this: <?php if($user->isLoggedin && !$config->https) { // redirect to the same page at the alternate https domain $session->redirect("https://clientname-fi.pwire.fi" . $page->url); } else { // user is in the right place } You probably want to put that in some universal/header include file so that you don't have to code it in more than one spot.

I've just added it to ProcessPageSearch and committed the update to the P21 source. Now you can do something like this: var url = config.urls.root + 'page/search/for?template=basic-page&body*=something'; $.getJSON(url, function(data) { console.log(data); }); The example above shows "search/for?" as the URL. When you add the "for" to it, it assumes that you are going to specify a selector in the URL. This works with either Ajax or regular mode. In ajax mode, it returns JSON. In regular (non ajax) mode it's going to output the results in interactive/html mode as usual. This "selector mode" isn't used in the search engine by default, so it's only used when you include the "for?" in your URL and specify a selector after it. I believe this selector mode is much more convenient than the regular mode for AJAX use, as well as regular non-ajax links to the search engine. The selector can be identical in format to a regular selector with the only difference being that you separate each part of the selector with a "&" rather than an ",". Here is an example: /processwire/page/search/for?template=villa&body*=luxury&bedrooms>5&bathrooms<=3 The above is a valid URL, but it's also a valid selector. If we replace the "&" with ", ", then we get this: template=villa, body*=luxury, bedrooms>5, bathrooms<=3 PW abstracts away the parsing of GET vars that lack an equals sign, like "bedrooms>5", and translates all of PW's 2-character operators just fine too (like *=, ~=, %=, <=, >=). Of course, you can also do this (specify a parent path): /processwire/page/search/for?parent=/path/to/parent&featured=1 If you want to specify what fields should appear in the JSON output (or the interactive table), then just add a "get=" var to your URL, like this: /processwire/page/search/for?template=basic-page&get=title,path,categories Separate out the fields you want to "get" with commas, like above. When you specify what fields should be included, it will include them in the output, in addition to the native fields that are included in all (like id, name, template, parent, etc.). Because JSON can represents objects nicely, PW will also include partial objects (like page references) as JSON objects. For something like a Page reference, it'll include most of the native fields for each page, as well as the title and path. By default it will paginate by 50, though you can increase that up to 250 by specifying your own "limit=123" var in the URL (where 123 is the limit you want to specify). To retrieve the next pagination, specify the same limit but precede your URL with the page number, i.e. /processwire/page/search/for/page2?template=basic-page&limit=100 If you prefer, you can specify a "start=123" var in your selector (just like with other PW selectors), to indicate the result number you want to start from. But I'm guessing most will prefer the simplicity of using the page number pagination. If you call jQuery's getJSON() on the search URL, you will get your results in JSON format. Here's an example of a call we might use: $.getJSON("/processwire/page/search/for?template=basic-page", function(data) { console.log(data); }); jQuery's getJSON automatically converts it to an object in jQuery, but the JSON string is probably the simplest way to envision it, so here is the actual JSON string as it's returned from that query. This query was performed on a stock install of PW 2.1 using the included profile. <?php // ignore the PHP tag, I just wanted syntax highlighting { "selector":"template=basic-page, limit=50", // just a repeat of the selector you used "total":"4", // total number of results found. if there were 1230 matches, this would be 1230 "limit":50, // the max number of results that will be in this request (default=50) "start":0, "matches":[ // array of matches { "id":1001, "parent_id":1, "template":"basic-page", "path":"/about/", "name":"about", "title":"About" // plus any fields you specify with get=... }, { "id":1002, "parent_id":1001, "template":"basic-page", "path":"/about/what/", "name":"what", "title":"Child page example 1" }, // and so on for each match ] } I'm sure there are tweaks and improvements still to be made, so please let me know if you find any issues or areas for improvement.

I missed the spam post, thanks for taking care of that. We get 50+ new spam accounts per day, and the stopforumspam blacklist takes care of nearly all of them. But I do have to go in and delete all the filtered accounts every week or so. 600+ accounts means it's time for me to delete them (tomorrow).

Great! thanks for testing, I will commit.

Some properties are only populated at page load time. When you create a new page in memory and save it, that page has still never been loaded from the database. As a result, it won't have created/modified properties since those are DB generated. PW doesn't automatically reload a page from the DB when you save it. But you can reload it yourself: $page = $pages->get($page->id); However, I think an even better strategy is to perform a redirect after you've committed any kind of major changes. That ensures that you are dealing with a fresh copy of everything and prevents a browser reload/refresh from re-posting your form and potentially creating a duplicate. So I would do something like this: <?php $template = $templates->get('new_page_template'); $parent = $pages->get('/path/to/parent/'); if($input->post->submit == 'save') { $p = new Page(); $p->parent = $parent; $p->template = $template; // ...populate the page... if($p->save()) { $session->newPageID = $p->id; $session->redirect('./'); } else { echo "error saving page"; } } else if($session->newPageID) { $p = $pages->get($session->newPageID); // a little security check, that may not be necessary since we're using $session // but i always veer on the side of more security. if($p->parent->id == $parent->id && $p->template === $template) { // display the results } }

Attached is an entire Fieldtype and Inputfield that show an example of 3 inputs for each image (title, tags and description). I've also set it up so that you can just change the schema in the getDatabaseSchema() function and it should automatically work with whatever varchar or text fields that you add. Though note that you'll want to make those changes before you create any fields with it. This works because the only place these custom fields are defined is in that schema, and everything else in the Fieldtype and Inputfield just picks it up from that schema. In the future, I will probably use this as a foundation for a more advanced image/file fieldtype where you can specify the schema from the field's configuration in the admin, rather than modifying the code. But figured this would be a good example for what you asked for. Ryan FieldtypeImageExtra.zip

Soma I was wondering if you could try out this /index.php file attached and let me know if it fixes it on your end? Since I don't have an example like yours to test from I just wanted to double check before committing. Thanks, Ryan index.php.txt

Okay cool so it looks like realpath fixes it. I'll make the update and commit it. Thanks!

Have you tried it? I think it should work out of the box. At least, I can't think of any reason why it wouldn't. Let me know of any specific areas of concern. The only thing I can think of that may have to be a consideration is the https vs. http settings for each template. If you access a page on an http addr using an https-only template, it will redirect to the same URL but with https. That may not be a problem. But if you find it's creating any issues, you can always leave the template set at the default (which is to accept traffic from both https and http), and then perform your https check in your template using $_SERVER vars.

I just updated my original message, wondering if realpath() fixes it. Not sure it'll tell you my message was updated, so you may have to click back to page 1.

Thanks for sending that. Can you try this in your strap.php and tell me what the output is? <?php include("../index.php"); echo "<pre>"; echo $_SERVER['SCRIPT_FILENAME'] . "\n"; echo __FILE__ . "\n"; Here is the output on mine for instance (two of the same lines): /Applications/MAMP/htdocs/skyuser/test/index.php /Applications/MAMP/htdocs/skyuser/test/index.php I'm guessing yours are different and we may have to use realpath(). So if they are different, try this and let me know if that does it? <?php include("../index.php"); echo "<pre>"; echo realpath($_SERVER['SCRIPT_FILENAME']) . "\n"; echo realpath(__FILE__) . "\n"; Thanks for your help testing this.

Thanks for posting this, it is really helpful for me to see! Hopefully I can duplicate and find a solution.

Something like onkeyup may not be ideal not only because of the overhead but because those events may or may not represent changes (arrow keys being an example). Are you using the ed.isDirty check? My understanding is that is necessary in order to really tell if it changed. Below is quoted from the TinyMCE page on the onchange_callback: Also, make sure that you are just monitoring TinyMCE and not also the textarea separately. If the field is using TinyMCE, you will want your other code to ignore the textarea. These are just ideas and you may have already tried this stuff, but I'll keep thinking here too. TinyMCE is always a hassle no matter what we try to do with it, but thankfully it's always great once things work.

Soma, can you try this test: 1. Create a subdirectory off of your PW installation directory, i.e. /test/ 2. Put this file in there: /test/test.php <?php include("../index.php"); echo $wire->pages->get("/some/page/")->url; If your site is installed at root, it should say: /some/page/ If your site is installed in a subdir, it should say: /subdir/some/page/ Are you getting something different? If so, what's the server environment? If you have phpinfo output that you want to PM me a URL to, that's all I would need to see. Also, double check that your /index.php is the latest version from yesterday (which is where this change was made). Very often when people (at least me) update their PW install, they just replace the /wire/ dir and not the /index.php, but this is one case where you'd need to replace the /index.php in order for it to work. Thanks, Ryan