ryan

I don't think that we are currently using the jQuery customized version of TinyMCE. It is possible to customize TinyMCE's init with ProcessWire hooks, though it's late in the day here and the exact methods escape me right now. I think that Soma or Diogo might have a better idea. But there should be some good info in the archives of these forums, as I know the topic has come up before. I just don't know what keywords to use to find it yet (tried a few). But if you can tell me more specifically what you are trying to hook into and what property you want to change, I think we can come up with a solution even if we can't track down the previous ones.

There are instances where it could feasibly reduce the potential data set that MySQL has to scan, but I think in most cases it probably doesn't make a difference to performance. But there are other good reasons to specify a template (or parent, or both). For one it clarifies what you are attempting to match, making it more "readable" to you and others that ever look at the code. It also ensures that the code is still matching the right things, should the field being searched for get added to more templates in the future.

I think that a module like this mainly provides value in sending a mobile photo to a web site. The reason for that is that many of these mobile phones have no file-upload capability (at least iOS doesn't). But they can send email. So this module actually solves a need and lets you do something you can't otherwise do. Phillip identified the need and solved it by using Tumblr as an intermediary (since their app will pass through photos), which was a great idea. This module solves the need by using email as the intermediary--the one common thing available to all smart phones (and all credit to Horst and Phillip for the ideas). When we get into specifying other types of data and fields, like what's been mentioned above, it definitely sounds cool and interesting. But the reality is, we don't need email for that… we could just login to ProcessWire. We need email only because mobile phones can't upload files. I don't personally have a need to populate text fields from emails, but it's feasible someone could (like some of the things MarcC mentioned, for example). For that need, I think the approach taken in this module would be a good way to go, and perhaps this module could serve as a good starting point to build that capability, for anyone interested.

Yes, you can definitely whitelist email addresses, and we highly recommend you do. The module configuration screen has a section where you can enter what email address are allowed to post. Keep in mind though that email addresses can be faked, so it's not a guarantee. Though I didn't specifically work with this part and Horst can provide better guidance on that.

We say "mobile" because that's the area where this module is most likely to be useful. However, the module doesn't care what device or computer you email photos from. Aren't you inheriting an iPhone 3g pretty soon?

Send photos from your mobile phone to ProcessWire, from anywhere, on-the-fly. ProcessWire maintains a chronological gallery that you can simply email photos to. Works with any e-mail capable device, whether mobile phone, tablet or desktop. Written by Horst Nogajski and Ryan Cramer Output inspired by the work of Philipp Reiner. Discussion leading to this module can be found here. Uses email libraries by Manuel Lemos Requires ProcessWire 2.2.13 or newer Here is example output from this module. Download from GitHub or Download ZIP file How to Install Setup a new email address at your provider. This address should be dedicated to the purpose of this module. Make the address private and cryptic enough so as not to be obvious or discoverable by others. Place the files included with this module in /site/modules/EmailImage/ In your admin, go to Modules > Check for new modules. Click Install for the EmailImage module. Complete all the settings it asks for, per the email you setup in step 1. Check the box to test your connection, and save. How to Use Email an image to the address you configured. You can include multiple images if you like. After waiting a minute or two, view the URL /email-images/ in your site. This is a page that was installed for you to display images. Repeat and enjoy. How to Customize While this module has everything working out-of-the-box, it is meant to be customized to your needs. For example: You may want to move or rename the /email-images/ page somewhere else. The EmailImage module keeps track of this page ID, so it is perfectly fine to remove or rename it if you want to. Take a look at the /site/templates/email-images.php template file. You may wish to replace it entirely with your own code, or you might build upon what's there, or use it as-is. But chances are you'll at least want to swap in your own header/footer to fit within your site's design. Take a look at /site/modules/EmailImage/EmailImageRender.php. That file contains an example function used to render an image gallery. This is the one called upon by the template file you just looked at. You might copy and paste this function somewhere else into your own site, and modify it to suite your own markup needs. Just remember to name it something different! Please post links to what you create in this thread. How to Uninstall You can uninstall this module in the same way as any other module, by checking the box to "uninstall" from the module settings screen. But please note the following warning: When you uninstall, your system is returned to the state that it was in before this module was installed. Meaning, the EmailImage pages and images will be deleted. So please backup your images somewhere else if you want to lose them during uninstall. After uninstalling, you can safely remove this dir: /site/modules/EmailImage/, and you can remove the template file: /site/templates/email-images.php.

An image has to be present before it'll import it. But it can include subject line text (which becomes the 'title' field) and body text. Because emails often contain a lot of extra junk (client specific stuff, signatures, etc.) you do have to clarify what is your intended body text by surrounding it with an opening and closing tag of your choice.

Great idea and module Pete! Regarding the backup directory, ProcessWire only prevents direct access to .php, .inc and .module files. As a result, it's still possible for some files to be accessible. But this is easy to get around. Just make your backups directory start with a period, like "/site/assets/.backups/" and then the directory will be completely blocked from web access.

I've always had good luck with ImageMagick, but didn't implement it in ProcessWire because it's not near as universal as GD2 and requires an exec(), which is something I didn't want the core to rely on. But would totally support inclusion of other libraries for resizing. Admittedly, I've been pretty happy with the quality of GD2's output (at least, after tweaking the quality settings), but if there are visible quality or size benefits to NETPBM or ImageMagick then it would seem to make sense. Attached is the ImageSizerInterface. If you make your NETPBM class implement this interface, then I can convert ImageSizer to be an injected dependency, enabling the image sizer library to be configurable per installation. The crop options are a relatively recent addition, and I don't think that many people are using them or know about them, so if difficult to implement, they aren't crucial to have at this point. ImageSizerInterface.php

That's funny you mention that because while posting my photos I emailed Horst to see if it was possible. He said that it is. I told him I thought it would be the first request we got, and sure enough -- the request came even sooner than I expected. I've updated the module to support it, and just need to wait for his update before we can test it out. Once we've got that, we will go ahead and release the module.

Horst, your file had comments speculating about what to do with the reasontext. Here's how I added it. Let me know if this makes sense: /** * Send to a URL using HEAD and return the status code (@horst) * * @param string $url URL to request (including http:// or https://) * @param array $data Array of data to send (if not already set before) * @param bool $textMode When true function will return a string rather than integer, see the statusText() method. * @return bool|integer|string False on failure or integer of status code (200|404|etc) on success. * */ public function status($url, array $data = array(), $textMode = false) { $responseHeader = $this->send($url, $data, 'HEAD'); if(!is_array($responseHeader)) return false; $statusCode = (preg_match("=^(HTTP/\d+\.\d+) (\d{3}) (.*)=", $responseHeader[0], $matches) === 1) ? intval($matches[2]) : false; if($textMode) $statusCode = isset($matches[3]) ? "$statusCode $matches[3]" : "$statusCode"; return $statusCode; } /** * Send to a URL using HEAD and return the status code and text like "200 OK" * * @param string $url URL to request (including http:// or https://) * @param array $data Array of data to send (if not already set before) * @return bool|string False on failure or string of status code + text on success. * Example: "200 OK', "302 Found", "404 Not Found" * */ public function statusText($url, array $data = array()) { return $this->status($url, $data, true); }

Sounds good, I think this makes sense for the installer. Thanks also for your additions to this class, I am putting them in today and should have them committed to the 2.3 source before release. One thing I would be worried about is just those cases where there is some firewall that blocks the server from accessing itself. I've run into this issue with a couple of people that were trying to verify their FormBuilder or ProCache license keys, and none of the WireHttp methods worked, despite falling back to sockets. So it seems like for one reason or another, there are servers out there that just don't accept outbound http requests (or have some firewall for local requests). I can't say for certain how common or rare this is, but am hoping it's rare. Can you think of any other fallbacks we should add to WireHttp, or do you think we've already got everything we need? I was toying with the idea of adding a CURL fallback option.

Like Joss said, you can create your own date field(s) and have them automatically format however you want. This is configured from your date field settings. But 'created' and 'modified' are built-in date fields that have no default formatting options. However, they are still very easy to output in the manner you asked about using PHP's date() function. For instance, if you wanted to output 'created' in the DD.MM.YYYY format, you would do this: echo date('d.m.Y', $page->created);

Out of the box, you can't do this with the comments fieldtype included with ProcessWire. Though you could modify it fairly easily to support what you are asking for. It would just be a matter of adding those 3 additional fields to the schema in FieldtypeComments.module, and updating the other files that accompany it to reflect what you need. Before you do this, it may be a good idea to make copies of all the files you need to modify, and keep it as a separate module in /site/modules/FieldtypeCommentsRating/ or something like that. By doing that, you don't risk overwriting your files during upgrades. Let me know if I can provide more direction in getting you started.

We've got this module just about ready for release. Here's an example of the module up and running and the [largely unstyled] output: http://processwire.com/email-images/

Favicon added to modules.processwire.com

Really happy to see this out and in the modules directory! Thanks for your great work with this module!

Thanks for testing. The behavior you indicated is correct. A user (with a password ) is required to complete the install.

If you are version controlling your entire /site/ dir then you'd definitely want to exclude cache and sessions. My opinion is that if you version control this stuff, just do it on /site/templates/, and let each module be under its own version control (or use Modules Manager). I don't think it's worth versioning /site/assets/files/ for instance, because any change of versions would disconnect it with your database, which is something you wouldn't want.

The WireHttp class is a fairly recent addition to the ProcessWire core, and as you saw it's very minimal at present. I had thought we'd keep adding to it. I like what you've added, and would definitely like to include your additions if that's alright with you? I think the problem here is that very often the .htaccess is not writable, so I don't really like building around something that we may or may not be able to do. I have never personally come across a situation that could be fixed by setting the RewriteBase, though I know others have. What may be a good approach for us is to just have a Troubleshooting section in the readme file, pointing people where to look in the .htaccess file if things aren't working. It does seem like more often than not, the problem isn't the .htaccess file but rather than server not reading it… something that beyond our ability to affect. Still, I like anything that makes it easier for users to install or troubleshoot, but I think this also represents a very small portion of installations. We'll have to keep looking at this though.

There is no performance benefit to count($a) vs. $a->count(). They both end up going through the same route. The reason that you can do count($a) on any WireArray derived types is that they implement PHP/SPL's Countable interface. I kind of like the count($a) syntax because it's consistent with array counting syntax.

It's easier to read. But my opinion is that it's also difficult to understand where it could lead. With GPL you know you are protected from some big corporation coming in and taking over. It keeps others from exploiting ProcessWire's core in ways we can't predict. Profit motives are limited to what you create with or for ProcessWire, rather than what you do to it. ProcessWire's core remains protected. I'm not saying I'm against MIT, and always think that going "more open" is good and worth considering. I'd love to talk to the Concrete5 folks to gain insight on their choice. But we should never be motivated to change the license because someone misunderstands ProcessWire. We should only be motivated by what's ultimately best for the project and users. Currently I think GPL is a great and safe fit for us. Though I also understand the GPL always opens questions wherever you take it. So it's important for project leadership to answer those questions and be clear so that there is no grey area. I think that's what we've done. Though I always invite more questions.

I would setup separate templates for your Parish Council and Cricket Club pages. If they are identical, then avoid repeating code and just have the template file from one include the template file from the other. Setup access control only on these templates. You don't need to setup access control on any other templates that are used for pages further in the structure, as they will inherit from the root parent. Meaning, you don't need to maintain multiple templates for the access control, except for the actual root parent pages (Parish Council and Cricket Club). Even if those two templates have identical needs now (except for access), you'll be better prepared down the road when Parish Council needs something that Cricket Club doesn't, or more.

If you have a robots.txt, I would use it to specify what directories you want to exclude, not include. In a default ProcessWire installation, you do not need to have a robots.txt at all. It doesn't open up anything to crawlers that isn't public. You don't need to exclude your admin URL because the admin templates already have a robots meta tag telling them to go away. In fact, you usually wouldn't want to have your admin URL in a robots file because that would be revealing something about your site that you may not want people to know. The information in robots.txt IS public and accessible to all. So use a robots.txt only if you have specific things you need to exclude for one reason or another. And consider whether your security might benefit more from a robots <meta> tag in those places instead. As for telling crawlers what to include: just use a good link structure. So long as crawlers can traverse it, you are good. A sitemap.xml might help things along too in some cases, but it's not technically necessary. In most cases, I don't think it matters to the big picture. I don't use a sitemap.xml unless a client specifically asks for it. It's never made any difference one way or the other. Though others may have a different experience.

Just want to mention that this: $theseones = $pages->get( "/" )->find( "has_parent=/, tag_seasons=/tags/seasons/spring" ); is identical to this: $theseones = $pages->find( "tag_seasons=/tags/seasons/spring" ); So there isn't any reason to have a $pages->get('/'); or a "has_parent=/" in your case. But lets say that you were targeting a branch in the structure like "/products/". In that, you would only need $pages->get('/products/')->find('tag_seasons=/tags/seasons/spring'); OR $pages->find("has_parent=/, tag_seasons=/tags/seasons/spring"); You wouldn't need both, as they are synonymous with each other.