ryan

I just added this to the 2.1 source. Once I got it in there and started using it, I realized locks and keys with unrelated purposes are probably confusing. Plus, now that we've had it there for a couple months, I don't know how useful it really is to show the "locked" status of a page in the PageList. What you proposed with showing pages that remove access is a lot more useful to see in the PageList. So I've dropped the 'locked' status and have re-purposed the lock icon to show pages that remove 'guest' access. Also added a corresponding 'unlock' icon that shows pages that add guest access under a tree that's already locked.

I guess that's another way to put it ;D

I've just posted a fix. Strangely, I could duplicate it in 2.1 but not 2.0. Then I discovered I had an update already waiting in the 2.0 source for this particular problem and it just hadn't been added to Git or committed. I must have fixed it at some point, been distracted, and completely forgot about it. But now it is committed in both the 2.0 and 2.1 source. Please let me know if this fixes it for you? Thanks again for letting me know of this problem. https://github.com/ryancramerdesign/ProcessWire/commit/03b60394fddc186aa8cfe3dd9f4de7670dc73c8a I wasn't able to duplicate the image alignment issue that you mentioned. Are you referring to image alignment in the actual TinyMCE editor, or in your site? If it's in your site, note that you have to add your own classes to your site's stylesheet. This is what I have in the default profile, which may serve as a good solution or starting point for further tweaks: /** * Alignment styles that are used by the InputfieldTinyMCE for * positioning images in bodycopy. If you are using this field type, * you may want to include these or similar styles in your site. * */ .align_left { float: left; margin: 0 1em 0.25em 0; } .align_right { float: right; margin: 0 0 0.25em 1em; } .align_center { display: block; margin-left: auto; margin-right: auto; }

Thanks for the report. I was able to duplicate it and am now working on a fix.

What browser (and version)? There are a few known issues with Internet Explorer (7, 8, haven't tried 9) which I've been unable to resolve in a manner I'm happy with. That's one reason why I'm looking at developing an alternate Inputfield type that uses the CKEditor instead. So I don't recommend using the TinyMCE Inputfield with IE (7,8) at present: though basic edits should be fine, but anything that involves popup dialogs are buggy in IE. Mozilla and Webkit browsers should work well, and if a bug is found in these it's something I can fix. In addition to knowing what browser (and version) you are using, I have the same question as Apeisa: which PW version and are you running the latest commit of that version?

Entire pages are rarely saved (except when creating it for the first time). Even when you do a $page->save() without specifying a field, PW will only save the fields that actually changed after the page was loaded. But if you only need to update a single field, it's still preferable to specify it like $page->save('field_name') because it doesn't have to check any other fields, doesn't have to clear caches (2.1), and doesn't have to do anything else. As of this week, 2.1 is quite a bit more efficient with saving an individual field than it was before. That's because it no longer attempts to clear the cache when saving individual fields. As a result, I would suggest that you use the latest 2.1 in this case.

This is not an easy yes/no question. I think that officially it's not good for me to say to use a development version for production use. But the reality is that we're all using it for production and it has some benefits over 2.0 that are worthwhile relative to the risks... but you have to determine that. The primary difference between the dev version and the stable version is that the dev version (2.1) has some newer code in it that hasn't yet been used on hundreds of sites. So when you use a dev version, you may be using some code that has only been tested by myself. It implies a higher chance that you may run into bugs, and that you are not just using it, but sort of testing it as well. I don't ever knowingly push buggy or partially finished code to GitHub. So this may be different from the way other projects keep their development version. I only push updates after I've got them to a point where I think they are usable and I've tested to confirm it works. So in that sense, there is more stability in the dev version than people may assume at first. Lastly, with the dev version, it may take a little more work on your part because you have to pay more attention to the updates. And it's a good idea to keep your source up-to-date, at least until there is a formal 2.1 release version. But that's just a recommendation... One other recommendation when using a dev version is to stage and test updates before you push them to production. And of course, back up stuff before you replace it. Though I think this recommendation applies for any update, and for any CMS, whether on a stable version or not... Adam's "tldr" version: Given your involvement here and the fact that we communicate here a few times a week, 2.1 is probably the way for you to go in most cases. But if you just want to quickly setup a site and never got back to it, then 2.0 may be better in that case.

I think this would be pretty straightforward to do. Assuming you are recording a per-page count, then you'd want to add a integer field to the page (called 'pageviews' or something like that). Then at the bottom of your template: <?php $key = "pageview" . $page->id; if(!$session->$key) { $page->pageviews++; $page->save('pageviews'); $session->$key = 1; } You may also need to add a $page->setOutputFormatting(false) above that if PW throws an error. And you might prefer to take it a little further and use an array in your $session var. The only real problem with this method is that a portion of pageviews on any site are going to be from bots, spiders, etc. You can eliminate nearly all of those by setting up a new template/page that does nothing but record pageviews and hit it with javascript. The example assumes you set this up at /tools/pageview.js (a PW page), and you would paste this somewhere in your template that powers the pages you want to track: <script type='text/javascript'> // write the script statement with JS so that spiders don't attempt to include it document.write('<scr'+'ipt type="text/javascript" src="/tools/pageview.js?id=<?=$page->id?>"></sc'+'ript>'); </script> Then your template running /tools/pageview.js: <?php if(($id = (int) $input->get->id) > 0) { $p = $pages->get($id); if($p->id && $p->fields->has('pageviews')) { // page was found and it has a 'pageviews' field $key = "pageview" . $page->id; if($session->$key) { // pageview already recorded for this page, so skip it } else { // pageview not yet recorded for this page for this user session $p->pageviews++; $p->save('pageviews'); $session->$key = 1; } } } echo "// this JS file intentionally blank"; I assume you meant thousands not hundreds. But regardless of the number (or even if it has a couple extra zeros), it should not be a problem. You won't notice a difference in performance. And given that you are just saving one field 'pageviews', rather than the entire page, it'll be especially fast (at least in 2.1).

Diogo, thanks for highlighting this option. This is good to know about the API that tumblr is providing. I think this would be especially useful if you already had something running in Tumblr or had a client that wanted to use it, but have the rest of their site powered by PW. Not to mention, I think they provide some tools for simple posting from mobile devices (?) so there may be benefits in multiple areas to doing this. As far as building a basic blog functionality, I still think using PW is going to be a simpler task then trying to pull the data from their API, but this is an excellent addition to this thread and a good solution for people that prefer to use Tumblr with their blog.

Thanks for following up about this – glad that you were able to find a solution that works well. Definitely just let me know anytime you need any help getting PW's TinyMCE module to support any of those other values.

That's awesome, I missed that before – you are a step ahead of me. I'm very excited about this module.

Abu, PW doesn't expose the settings you mentioned just because I think they are primarily in TinyMCE for backwards compatibility with pre-semantic-markup. Years ago, rich text editors didn't deal with semantic elements. Instead, they used BR tags (not to mention inline styles) to make the editor "feel" like MS Word. But HTML markup is fundamentally different from something like MS Word and it usually does the user, and their output, a disservice to hide that fact. TinyMCE and other editors are now built more in recognition of that, but it wasn't like that just a few years ago. So this is why hitting enter (for instance) creates a new paragraph, and hitting shift-enter creates a break. Usually we don't want our client creating non-semantic breaks unless they really mean it. That's just background info on why PW doesn't expose these settings, but they aren't applicable to your particular need which seems to be unique. I think what you are suggesting makes sense for your need and your client. While I wouldn't usually suggest editing files in a core module (because they can be overwritten in an upgrade) I think that's going to be the best way to achieve what you want. You'll have to remember to keep a copy of these files if you upgrade, so that you can apply the same change later on if the need arises. Here's how to do it: First edit this file: /wire/modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.module Add the elements you want to configure to the $defaults array at the top. They should now be configurable with your TinyMCE fields in PW. The only thing I'm worried about is that PW currently just configures string-based values, so something like "false" or "true" will still be a string when sent to TinyMCE (rather than a boolean). It may not matter, and TinyMCE may already be looking for this, but if it doesn't work we'll have to do a little more editing, which I can walk you through--just let me know.

Welcome to the forums Diogo! Thank you for your post and offer to help with Portuguese translation. I think we will be able to take you up on your offer this summer, so hope to talk to you more about this soon. That's a good point about European vs Brazilian Portuguese. It sounds like we will eventually need both as separate translations, so we will keep an eye out for this. My impression is that the majority of PW users are in Europe at present. If that's true, European-based languages will no doubt get covered before others.

As Apeisa mentioned, PW doesn't currently have anything built-in as far as forums go. That may change in the future, but hasn't been a priority previously just because forums are something that is so well covered by other products. If you want forums, I would suggest using one of those products (I'm pretty happy with SMF, for the most part, but I know others that really like PHPBB, MyBB, vBulletin). Even if you are using a CMS that has the option of built-in forum functions (like EE, Joomla, Drupal) you are still better off with a dedicated forum software if you want the best tool for the job. (Though they can be overkill for simpler needs, so native forums still have a valuable place.) If you want integration between PW and a forum software, there are lots of possibilities here if you don't mind coding a little glue. And I'm always here to assist with any questions you have along the way. PW does have a built-in comments module. While very functional at present, I plan to take it a lot further in the near future. Beyond that, built-in social features have not been a major focus of PW's core primarily because it's designed as a tool for implementing your site and it's features rather than a turn-key solution for specific types of sites. Providing a great foundation (for social features or other features) IS a major drive behind PW. And as time progresses, I imagine people will come up with modules for integration with all kinds of social features. But so many social features these days are also built around 3rd party services (and that seems to be increasing), and this is a very natural fit for PW.

Wow this is really looking great! I tested on the feeds you indicated, and was able to perform the field mappings no problem. It looks to me like everything you've implemented so far works. Great work! Keep doing what you are doing. Here are a couple notes: In your table structure, you may want to use ID's (integers) rather than strings for 'template' (in the main table) and 'to_field' (in the mappings table). This is in case either of these things get renamed -- the ID is permanent, but the name is not. One thought occurred to me on the load screen, and that was that it would be handy to see an example of the data for each field (like the data from the first record) when associating the field, just to clarify what it is. Though I could just as easily load the feed in my browser and do that, so that's only a luxury feature (probably not something for v1).

Arkster: the on-site documentation for modules is minimal at present, but the code-documentation is pretty good (in the actual module files). I will be putting together strong documentation/guide for module development with 2.1/2.2 but these are good files to look at: https://github.com/ryancramerdesign/P21/blob/master/wire/core/Module.php https://github.com/ryancramerdesign/P21/blob/master/wire/core/Process.php Those files outline every detail (especially Module.php). Your module doesn't even have to extend one of PW's classes if you don't want it to. The only thing it has to do is provide two functions: getModuleInfo() and init(). The rest are optional -- you'll see examples of them in Module.php, but they are all commented out since they are optional. As a result, that Module.php file is primarily documentation. The Process.php is just a type of module -- I included it above since you mentioned this may be the type of module you want to create. If you create this type of module, you do have to extend the Process class (unlike a regular module where you don't necessary have to extend anything). Also, any time you want to build a module, just post as many details about what you are trying to do in the Modules board, and I'll be happy to get the skeleton started for you to build from too. If you need to hook into something, I can tell you what to do (or if a hook doesn't yet exist, I can add it in the core).

Great! glad that fixed it. I'm guessing that 3G must place you on rotating IPs, so we can't tie the session down to a single IP (which is one of the things the sessionFingerprint option does). I didn't realize this before, so it's good to know. It might be that I should disable the sessionFingerprint by default.

Updated the original example for @apeisa's suggestions. Also note it deletes all the photos from the current page after it's created all the other pages, so there isn't any risk of those pages being created more than once.

Almonk, thanks for the updates. If I make any changes to the module, I'll be sure to fork. Regarding modules, it looks to me like you've got a pretty good handle on it. But once I get through the 2.1/2.2 updates I'm going to write a full module guide, as this is currently not well covered in the online documentation (other than lots of examples in the forums). Thanks, Ryan

Looks good! Thanks for putting this together and sharing it here. I have two minor suggestions: Make is so that setting the page URL is optional, and it defaults to the current page if you don't set it. Have your render() function return the value rather than echoing it directly. One of the concepts with PW is that nothing sends any output, except your template. This is just for practical reasons, since PW templates can be used as controllers to populate other templates/views/includes, etc. That way your template can decide whether to echo or store the result for later output. public function ___render() { if(!$this->url) $this->url = $this->page->url; return '<iframe src="http://www.facebook.com/plugins/like.php?href='.$this->url.'&layout='.$this->layout.'&show_faces='.$this->showFaces.'&width='.$this->width.'&action=like&font='.$this->font.'&colorscheme=light&height='.$this->height.'" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:'.$this->width.'px; height:'.$this->height.'px;" allowtransparency="true"></iframe>'; } With the above change, you could decide to skip the URL setting part, and you'd have to echo or store the output: echo $modules->get('FacebookLike')->render(); What's funny is that I just had a client ask for a like button, so your new module arrived at the perfect time and I will definitely use it. Thanks!

Adam, I can't seem to duplicate that here. I've tested InputfieldCodeMirror on a field here and am only getting the 'changed' messages when I've changed something. Are there any other factors? I don't think that the content of the field would matter unless something is appending some whitespace to the value (like the javascript perhaps), or converting one type of whitespace to another (like tabs to spaces or spaces to tabs, etc.). First we need to determine where it's changing, so this might be a good place to start... add this to your setAttribute() function in your module file: if($key == 'value') $this->message(md5($value)); That will display a message at the top of the screen when editing a page with the field. When you edit and save the page, and edit again, is the MD5 value always the same? If it's not, then something is changing, so try this: if($key == 'value') $this->message(md5(preg_replace('/[\s\r\n]*/', '', $value))); If the MD5 hashes are now the same, then it means something is messing with the whitespace in the value (likely javascript related). If they still aren't the same, then you may just want to stuff the entire $value into that message() function and copy them out to run a diff. If all of these return the same MD5 hashes, then tell me how to duplicate exactly, including your field settings and the content of the field, and I can do more testing here.

Creating a new Process module would be the way to go if you want to create something that's easily reusable. But if this is a one time need, then you may find it quicker to do the other thing you describe... if I understood correctly, that is: create a page where you upload a bunch of images to (perhaps in a ZIP file) and it creates all the individual image pages for you when you view it. I think this seems like a reasonably simple approach because you could just build the functionality in a template file. Something like this (written in the browser, so may not be 100%): <?php $numImages = count($page->images); // images is a field on this page that can have multiple images if($numImages && $input->get->go) { // there are images and the user has indicated they want to create the pages // determine where you want the pages created, for example: $parent = $pages->get("/image-gallery/"); // image-item is a template where you have a single image field called 'image' $template = $templates->get("image-item"); // iterate through the current page's images, and create one new page for each of them foreach($page->images as $name => $image) { $p = new Page(); $p->template = $template; $p->parent = $parent; $p->name = $name; $p->image = $image->filename; if($image->description) $p->title = $image->description; else $p->title = $name; $p->save(); echo "<p>Created: {$p->url}</p>"; } // once images are processed, remove them $page->images->deleteAll(); $page->save(); } else if($numImages) { // there are images -- check if the user wants to create pages echo "<h2>Found $numImages images</h2>"; echo "<p><a href='{$page->url}?go=1'>Click here to create pages for them</a></p>"; } else { // there are no images here, so render the gallery page instead echo $pages->get('/image-gallery/')->render(); }

Just in case anyone is interested, I posted an update to the 2.1 source that can be handy when working in the API with Page fieldtypes. With Page references that hold a single page, you used to have to check if the field had a value before you accessed it (at least, if you wanted to avoid a PHP warning). For instance, this code would produce a warning if your $page->category didn't contain a value: echo "<h2>Category: {$page->category->title}</h2>"; If you hadn't selected a value for $page->category, then the above snippet would result in a PHP warning (at least in debug mode). So to code it properly you would have wanted to do this: if($page->category) echo "<h2>Category: {$page->category->title}</h2>"; In the latest update, you can now configure the Page fieldtype to define what it's non-selected value is. You have a choice of either boolean false (the existing behavior), or a blank Page (NullPage). The advantage of having your undefined Page reference resolve to a blank page is that you no longer have to check if the field has a value before you access it. So you can now do this... echo "<h2>Category: {$page->category->title}</h2>"; ...and it won't produce a warning when the $page->category value is not set. Of course, you'd still get blank output of "<h2>Category: </h2>", but I'm just using this as an example. If you use a lot of single-page references, you'll find this can simplify your code in some instances. So as to be backwards compatible, this behavior is optional, and you can choose the behavior when you define your field (see screenshot below). When using a Page fieldtype to hold multiple pages, there is no difference, as those always resolved to a PageArray regardless of how many pages it contained.

Thanks... I've been wanting to build it for awhile, as the need has come up a few times in some of my projects too. Our messages from the other thread motivated me to go ahead and build it. Let me know how it works for you if you use it at some point in the future. For anything that requires significant time to process, regular cron is still the way to go, but this LazyCron should be good for the majority of smaller automated tasks.

I'm thinking there is a good chance this might be it, but please let me know what you find. Edit your /site/config.php file and change the sessionFingerprint config option to false: <?php /** * sessionFingerprint: should login sessions be tied to IP and user agent? * * More secure, but will conflict with dynamic IPs. * */ $config->sessionFingerprint = false; // default is true