Leaderboard

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.

Cool now I can finally use outlook to build websites.

Just thought of a module I might want to build - just wanted to share the idea and see if anybody else would be interested. The Page List tree-view is great for most things - but it's not necessarily the ideal interface for things that aren't structured. For things that are just flat lists, I'd like to have a tabular admin interface - a grid view with columns, and eventually with sorting and filtering functions, though not necessarily in the first version. I'd like to have an admin interface from which you can create table views as needed - e.g. give it a title, select the Template, select the parent Page, and optionally enter a custom selector. Tabular views would be accessible from the "Pages" menu. Thoughts?

ProcessWire Email Obfuscation (EMO) Download | GitHub Email Obfuscation module for email addresses with 64 base crypting. This module finds all plaintext emails and email links from the document and replaces them with span elements including configurable replace text. All the addresses are encoded to 64 base strings and stored in spans data attributes. Then on client side we decode these strings back to their original state. Install Create new 'EmailObfuscation' folder into /site/modules/ and place the content of this repository into the directory. Login to processwire and go to Modules page and click 'Check for new modules'. Find 'EmailObfuscation' and click install. You can make optional configuration changes in the module admin page. Thanks This is a ProcessWire module fork from MODX Evolution plugin emo E-Mail Obfuscation. http://modx.com/extras/package/emoemailobfuscation EDITED ON: 2013-03-03 - Added description. 2020-04-16 - Fixed GitHub links and updated description. Hello all. Just found PW few days ago and it's already looking awesome! Here comes first contribute and some questions for developing it further. There was one existing email obfuscator on reposity that didn't use any crypting for addresses so I decided to do a little test run and port the one that we currenly use with MODX Evo to ProcessWire module. I'd like to make PageAutocomplete like gonfigure option to admin so that one could select and set templates to exclude module action. It looks like autocomplete is tied to pages and since templates are not set to system as pages this is option is no go, am I right?

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.

Darned, i could have fitted that in <140 characters But still, i managed to lure someone to the forums

Good morning little app builder ninjas, As promised yesterday I will point you to the important forum posts on how you could build your own app in Processwire. Are we all seated? First we assume that our app is separated into two main parts. The Frontend with custom login and the Backend for App Administration and User Dashboard. Before we beginn follow this link: http://processwire.com/api/cheatsheet/ Say hello to the Processwire API Cheatsheet made by Soma, whenever you meet Soma just give him a hug for this outstanding work. Well the Cheatsheet would be definitely your best and maybe your most intimate friend during developing process. Make yourself familiar with the Cheatsheet and make sure you activated the advanced view. Ok, lets beginn. Right before coding any line in our editor we have to think about our App. What should the App do? Which functionality do we need? Maybe you mockup your first design, but do not start to code! Think about your App, think about structuring your data, fields, templates,folder structure and ,believe me (really important), think about name conventions. A little example from one of my projects. The app handles three use cases, Frontend, Backend Administration and Client Dashboard, maybe a normal setting. I started to think about naming template files and folders. So I came up to the decision to name folders like this: includes-backend --admin --views --scripts --client --views --scripts includes-frontend --views --scripts Template files are named like this: backendHome.php backendMyData.php home.php homeNormalContent.php homeLogin.php Think about naming your page tree, this is maybe the first step in data structure you do. Sure you could start this way, but do you know how large your app possibly could grow before really thought about? So, do yourself a favour and write down your thoughts. I´m working currently on a App which contains round about 300 Files of Script Logic and Output forms, editing without any logic in naming would definitely be a mess. Ok, we thought a lot of our App in theory, what now? We need a custom login! You find some usefull snippets and logic about login from frontend in this posts: http://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/#entry15919 http://processwire.com/talk/topic/107-custom-login/ (I really could recommend Renobirds login thoughts and his script) Read carefully through this posts, they contain almost everything you have to consider on frontend user management. You are now on a point of using processwire where you definitely receive input from users, so think about security and make yourself familiar with $sanitizer. Never ever work with user generated data without sanitizing them! There are two main headlines you always have to remember: 1st DO NOT SAVE PASSWORDS IN PLAIN TEXT IN YOUR APP 2nd DO NOT TRUST INPUT YOU RECEIVE FROM USERS Calm down little Ninja. Ryan just gave you a strong and powerful tool. He gave you Excalibur and named it just API. Follow this links: http://processwire.com/talk/topic/352-creating-pages-via-api/ (creating content via api) http://processwire.com/talk/topic/296-programmed-page-creation-import-image-from-url/ (image handling) Thats it.

Ajax Search 1.1.0 There was a request for a ajax live search. So I went and created a simple module. Added in 1.1.0 * added key support for browsing results with arrow down and up. * added escape key to close results. * added close results on click outside http://modules.proce...es/ajax-search/ From the readme: This module progressively enhances the search form to an ajax live search. It will perform a search like you would use the form normally, and returns the output of the search page. So the search will still work without js enabled. There's some basic styling attached to this module in the "styling-example". You can use it to get started. See readme in there. Setup the search.php So it works almost out of the box with the basic install profile of ProcessWire, you only need make a minor change to the search.php template file to only return the content part (results) on a ajax request. To get the ajax search only return the content, open search.php and change the output on the bottom to this: ... if(!$config->ajax) include("./head.inc"); echo $out; if(!$config->ajax) include("./foot.inc"); Module Settings It comes with some module options to define various settings regarding the search form. Following a list with the defaults. Minium length = 3 min length for starting ajax request Close button text = 'close' close button text ID of searchform = #search_form if you have a different search form id,class ID of input = #search_query if you have a different search input id,class Query name = 'q' this is the default param name as_query_url = '' if left blank the script will take the action of the form Any help testing this module is appreciated. If you have any questions or problems setting this up feel free to ask here. Also feel free to use this as a starting point for your own, or take out the script to implement it differently. It's quite simple and can be adapted really quickly.

http://nicenicejpg.com/ A friend of mine built this. I thought it was pretty funny. I have used placekitten.com in the past, but with a '90s rapper things just got a lot more fun.

I'm not sure inside repeaters I think there's still some obscure things happening. Image field is always an array, it's just that page output formatting does change it so in template files you get an object if the image field is set to max 1 item. So if output formatting is off it's always treated as an array, disregarding the field settings. I think in case of a bootstrap there's no output formatting on I think. Since repeaters are pages attached to the page I think it may change something or not if you ad // short syntax of setOutputFormatting() $item->of(true); and this doesn't work? $item->my_mage->first()->url

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.

"Why did that weird image get posted to my web page???" "That must be your Outlook stationery background."

I don't know, but would guess that it would just throw error when you save archived page in admin. You don't have to remove it though, you might check the parent also (if page is already in archive, don't move and save).

Thanks man. Gonna try the module today. BTW what happens if the page field is required, and we remove the 1234 selected ID?

It gives you the page that is being saved. wire('page') would give you the admin page (page edit -page). That event stuff feels little mysterious when you're starting with autoload modules, and it you will grok it soon. Lots of information here on forums about it.

Thats kinda wrong it doesnt highlight current page but the root parent of the current page here used for subpages under a root parent. Like a trail highlighting. It does also work for the root parents itself but could be missunderstand. $child === $page would be for subpages too in case the code also goes further. === is to compare objects that are the same in memory. So its not the id but the object.

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.

Oh, very clever! (I cant test it because my mobile does not take photos and cant email either!)

In fact, this may streamline it further: <?php echo '<ul class="blocklist">'; // Start the list here as I don't want to loop through things twice foreach($pages->find("template=report") as $location) { foreach($location->mountains->sort('-stats_maxElev') as $peak){ // we prefix the field name with a minus sign to sort descending rather than ascending if ($peak->stats_mtnName){ // pages create 4 blank repeater "value sets" by default, this is a test to grab only populated ones $maxElevft = number_format(round($peak->stats_maxElev * 3.28084)); // to convert a field value in metres to feet; using number_format() to add thousands separators (ie. 3200 -> 3,200) echo '<li><p class="tabular"><a href="'.$peak->url.'">'.$peak->stats_mtnName.' '.number_format($peak->stats_maxElev).'m / '.$maxElevft.' ft.</a></p></li>'; } } } echo '</ul>'; ?> But without a copy of the structure and data I suspect it might fall foul of repeater issues

One additional note is that "usort" seems to have some issues with decimal values. One of my lists is distance related and allows a single decimal place for values such as "10.7". The output I was getting was about 95% correct with perplexing errors that seemed to have no particular pattern. After a bunch of experiments I found that using a simple multiplication to eliminate the decimal value for the comparison function resolved the problem. usort($dest, function($a, $b) { $a = $a->distanceKm * 10; // example: 10.7 becomes 107 $b = $b->distanceKm * 10; return $b - $a; });

If it helps reassure you more there is at least one project I have in the works that will be scaling to many thousands of pages, but ProcessWire has already been stress-tested beyond what I'll probably achieve any time soon It is a reasonable question you've asked though as I remember asking it a year or two ago and, aside from code improvements in the core since then, I remember ryan saying hosting is the key with larger sites. Hopefully you're more excited now knowing you can build it in a system that you can easily tailor to your needs rather than bending other platforms to your will, which is never quite as fun for me! Elegant coding over forcing things to fit any day.

Hi Aaron, You can use ProcessWires built in User / Roles Management for the Users, so assign either a "Buyer" or "Artist" Role. After the frontend-login, you just display different stuff based on the users Role. As Pete says, 10'000 Users is not a problem – Users are in fact pages too. I'm developping a custom "shop" that currently has about 2000 registered Users and 90'000 Products – everything modeled with pages. It's not finished yet but so far I haven't encountered any problems. Cheers

You can definitely do this in ProcessWire. 10,000 isn't actually that big a number really, but one of the main things to consider with larger sites is web hosting as presumably you could end up with lots of images on the site, thousands of visits per day and bandwidth could get quite high. You'll be fine with a smaller hosting package to begin with, but just bear in mind you probably want to select one that can scale as the site grows rather than move sites around from provider to provider. I've read elsewhere on the forums that ProcessWire is happy up to hundreds of thousands of pages and beyond, but low server specs would limit you before ProcessWire does Also, if you are thinking there will be a lot of pages that don't change much then look into caching options, and if you will have many pages like galleries that don't change at all then definitely consider ryan's excellent ProCache module.

Wow, I don't know how I managed to overlook that. Apologies.

Nope, I always forget to think big enough with my folder structures Plus I still have yet to do anything like a client dashboard in PW so those links are useful.

It's all running perfectly. Thanks to all of you. Date, Headline, Teaser, everything. Now I'm doing the archive. With my newly earned mad processwire skillz, this shouldn't be a problem.

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.

Ah, I see. It is easier to learn new things than to unlearn old things. This system is so elegant!

I appreciate your concern, and I'll try my best to clarify. I'm the copyright owner of all code used in these modules (FormBuilder, ProCache). I'm also the copyright owner of the module interfaces and the ProcessWire core. I make a point not to rely on any code I've not written personally or that other people have contributed to. But I think you are looking for clarification on a bigger picture, so I'll instead focus on others that might want to create stuff in ProcessWire. We do not require that all websites and modules produced on top of ProcessWire's framework be free, and I don't know of any tool like PW that does. What I don't want people to be able to do is turn ProcessWire itself into a commercial product or be able to change ProcessWire's license. But I do want them to be able to use ProcessWire in the manner it was intended. ProcessWire is intended and built as a platform to manage and execute modules. I do not support extending ProcessWire itself with anything but GPL v2, but I do support ProcessWire being used as the tool it was meant for, without restriction. Years ago, in talking with other CMS developers for projects much bigger than ProcessWire, they'd suggested to use GPL v2 but make clear that the project encourages and supports an ecosystem that is not against commercial modules (which I've done on several occasions), so that there is no grey area. In fact, ProcessWire's API and architecture reflects this intention. When you build a site or module on top of ProcessWire, you are not extending ProcessWire--you are using it as a tool for exactly what it was designed for. For the sake of our users, I want to be clear that I consider a module running on ProcessWire no different than a website running on ProcessWire–they use the same API and in the same way. This architecture is intentional. And I certainly don't want people to think that their own websites, content, images, assets, etc. are GPL as a result of running on or being delivered by ProcessWire. For others making commercial modules, I am also okay with fees charged for 3rd party modules to be support/service/distribution fees rather than license fees (which is the route I like, though wouldn't require it). I don't support any kind of obfuscation though, and wouldn't list obfuscated modules in our directory. I need to be able to confirm that something is coded with attention towards security before I'd list it in our directory.

EllisLab have recently changed the pricing structure of their flagship product, ExpressionEngine. Just to some up the changes, they've basically discontinued their freelancer and non-commercial licences, got rid of volume discounts and changed their support structure. So, the only available option now is to buy the fully commercial licence, which currently costs $299. This has seemed to anger a good chunk of their customer base, who have raised their concern for the future of ExpressionEngine in a number of places. See here for some examples: http://bit.ly/R2yFLf http://bit.ly/U8qrBV Now, I think this is an excellent opportunity for ProcessWire. I believe that a good number of ExpressionEngine customers now looking for alternatives would greatly appreciate the flexibility and power that ProcessWire has to offer, and would find the transition from EE to PW relatively smooth. I'm not suggesting that PW and EE are totally interchangeable, but I do believe they share enough in common to appeal to those EE users currently looking for an alternative CMS. So, what do you guys think? How could we take advantage of the 'EE exodus'? Claudio

The HGTV Dream Home Giveaway sweepstakes has not officially ended yet, as construction is still ongoing at the property. According to the floor plan, the winners will enjoy nearly 4,000 sprawling square feet of living space. The architecture and design is inspired by a traditional cattleman’s ranch, placing one lucky family in the center of the surrounding rivers and mountains. The HGTV architect responsible is none other than Corey Sulum. There are a total of 14 rooms just on the first floor, including four bedrooms, four and a half bathrooms, five roofed decks, an open-air living room plus a laundry room featuring lockers, which are perfect for fishing rods, skis and waders. In addition, there will also be a game room, completely clad in crib framing, and a gourmet kitchen complete with top of the line appliances, ideal for entertaining and accommodating guests. The guest suite offers a perfect view of the surrounding river and mountains, including its own walk out door to the back deck so your guests can enjoy the same captivating sights.

ProcessWire is a content management framework, which is still a "framework", but more focused on a particular thing. Whereas the framework scope of CakePHP, Laraval, CodeIgniter, etc., is more broad and cover more territory. ProcessWire isn't meant as a replacement for one of those frameworks, but I think there are probably many instances where its focus might make it preferable. And an equal number of instances where the opposite is true as well. There's also something to be said for bringing the two together in some instances. Another big area of difference is that traditional frameworks enforce a particular approach to build on top of, whereas ProcessWire aims to be a lot more transparent, like jQuery. Frameworks set you up with a place to put your models, views and controllers, whereas ProcessWire puts in you in a plain PHP file (template file) that is given a location context ($page) and lets you take over from there. We think MVC is a good approach to take with ProcessWire template files, but don't enforce anything, as it's up to the developer. For better or worse, the possibilities are wide open in the same way they are with a PHP file on its own… though with a full CMF API at your disposal.

ProcessWire core is a framework. And on top of that built a CMS I think it goes this far /wire/core - is the framework /wire/modules /wire/admin-templates - is the admin/cms built on top of the core /site/ - your site with possibilities to extend admin and cms functionality You could start now and build your own CMS basing on core.

If someone wants to write an article about how to make the move from EE to PW, I will gladly edit it and give it some spin. It can go on the Wiki as a useful article and then you can all put it on your blogs everywhere! I am not talking about how to move an actual site, but rather if you do this on EE, this is how to achieve the same thing in PW .... that sort of thing. Joss

I stopped using EE about a year ago. I didn't see all these EL changes coming but the multiple pages of ongoing bugs and having to install a multitude of add-ons to do simple stuff just got tedious. That and the painful upgrade process/add-on compatibility made maintaining a site excruciating. It made selling it to clients a no go. EE is generally a good product and the developer community have created a wealth of good add-ons. But that has inadvertently stifled any EE development. I can't think of a new feature they've brought out in the last two years whilst the bug list keeps growing. I think it's become a platform for developers to make a few bucks - and not that much from what I've read. The EE community can be really one-eyed too and the loudest are those that have hinged their business on using EE and don't/won't consider using anything else. While it's not a particularly healthy thing, they're generous and helpful as well. I don't miss using EE one bit and I'm honestly impressed beyond belief that I can do 99% of the work I used to do in EE (and add-ons) now with PW. Cheers Marty