Leaderboard

Thanks for submitting your sites! We're now up to 106 sites in the sites directory. Keep them coming! I added the FieldtypeLikes module so that you can now click "like this site" for any of them (this is also used in the modules directory for the recommendations feature). I figure this will be useful for sorting and ensuring that some of the best examples of PW sites rise to the top, down the road. Perhaps we'll display the top 3 on the homepage or something. Currently "most liked" is a sort option, but default sort is by date modified. Anyway, if there are any sites you think are especially good examples in the directory, please go there and like them. The other addition is that the sites directory now uses Philipp's excellent ProcessImageMinimize module for all the screenshots.

I agree, that looks great. I'd say it's brilliant even. It's a "P" both in positive and negative space, and the whole thing is constructed from a wire. I'm wondering if the Bitnami folks would mind if we used that elsewhere.

I've posted the first iteration of the directory here: http://processwire.com/about/sites/ – I plan on doing a lot more with it (including a landing page for each site), but just wanted to get something posted quickly since we may be getting more traffic coming in soon with the Bitnami release. Thanks to those that have submitted their sites so far. Thanks especially to Marty (stillmovingdesign), one of the most prolific ProcessWire users, for taking the time to submit all of his ProcessWire sites in there. We went from having about 5 sites to having 30 after he submitted his. Now we've got about 64 sites in there. Please keep submitting posting your ProcessWire sites. We want to show a comprehensive diversity of work in the directory, and it's already coming along really well! I've added a few of your sites for testing purposes. If you already see your site there and want to change something about it, just re-submit it and I'll overwrite the existing one.

Have you guys noticed ProcessWire logo on Bitnami? See attached screenshot or click here http://bitnami.com/stacks

Please add your ProcessWire sites to our directory, immediately before or after posting to this board. We want to make sure that everything posted here is also posted in our official directory.

Hi Mike and welcome! The thing about PW is that it really does not have any fixed structure - it is up to you how you want to work. There is one fixed rule, however - for a file to be available as a template file is must have a php ending and it must be directly in the templates folder. And that is it. After that is is up to you. For instance, I tend to have my main templates like home, basic-page, gallery - whatever I think I need. But things like my header and footer I put in an includes folder within templates and the just include them into the file. Likewise, I split out much of my logic into functions in one or more functions.inc files and stick those in the includes folder. It doesn't make any difference to PW itself, but it help me think my way through it. PW is a lot less restrictive than drupal!

MikeB, welcome to PW and the forums! Thanks for your input. I can understand why things seem to be confusing regarding structure of the file system/layout. I'll give you a straight answer. When it comes to profiles (e.g. the blog profile) and templating, there are no standard or recommended structures of the file system/layout . That is all down to the developer's preference! So, in the blog profile, that is Ryan's preference for structuring the file system/layout. The blog profile is not part of the core. Have a look at the other profiles as well to see the differences in approaches. If you look in the default profile (the default install) that ships with ProcessWire, it is also different (although that is necessarily so to align to a common structuring approach that would be familiar to those coming in to PW with some PHP background). Have a look at the followings thread for discussions about the different templating approaches people use. Some even mix approaches depending on need. http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/ So, in a nutshell, some of us prefer .tpl, .inc, others don't, others prefer to have a /views/ directory inside /site/templates/, others don't, etc., etc. Having said that, when it comes to naming modules, there is a recommended approach: http://processwire.com/talk/topic/741-a-guideline-for-module-naming/ http://processwire.com/talk/topic/2394-how-to-present-your-module/ Edit: Members' attempts at MVC http://processwire.com/talk/topic/4892-an-almost-mvc-approach-to-using-templates/ http://processwire.com/talk/topic/3587-templates-mvc-recursion-etc/ http://processwire.com/talk/topic/4947-the-pw-mvc-project/ http://processwire.com/talk/topic/4507-pw-best-practices-application-structure-form-handling/ http://processwire.com/talk/topic/4507-pw-best-practices-application-structure-form-handling/?p=44338

Hey Pete, I'm short on time, I think this is what you are after. $templates->get("template_name")->fieldgroup->getField($field, true)->label; *written in browser off the top of my head.

@MikeB, How you structure your projects is up-to-you. The blog profile is just one way to do it. but there's no best way. The beauty of processwire is that you as developer are totally free how to handle those structures.

Wow first time I see it! Looks great there!

Nice one Reno. I just tested and it works! My quick mash - I am sure it could be improved. $template = $templates->get("your-details"); foreach ($template->fields as $field) { $fieldlabel = $template->fieldgroup->getField($field, true)->label; echo "<label for='$field->name'>".$fieldlabel."</label>"; $inputfield = $field->getInputfield($page); echo $inputfield->render(); }

Okay, three four of us posted at once! There is a good reason for that, however. The reason we all love working in PW is it is a little like wandering off to do some nice happy HTML with a powerful database and API attached. For instance, I use Bootstrap and sometimes Foundation and lots of JQuery plugins - but none of them have to be changed to suit PW, you can use them out of the box, just as you would in a static site. This makes it incredibly powerful - nothing is off limits or requires someone to produce the "PW" version of something as you would in Drumlapress. So, just write your templates, or bits and pieces to be included into templates, as you would any other html page - but do it with the PW API supplying the content.

Mike, The great thing about PW is that you can structure and name files however you want and put them in whatever subfolders you want. The only real restriction is that your main template files (the ones that relate to the templates you set up in the PW admin) must be in the site/templates directory. The only other restriction is that if you want to call any scripts directly, they need to be above the sitefolder. Other than that, you can do whatever you want. Feel free to add as many include folders and name files however best suits your workflow. I haven't used Drupal so I may not be the best person to comment, and maybe you can do this is Drupal too. It's on the roadmap: http://processwire.com/about/roadmap/

if you assign level1 = 1 and then try to print an array i doubt it will work since you assigned an int or even a bool (Since 1 could also be true) and you try to print an array If you wish to print it should work with $level1 = array(1); That and i dont really understand your question, try and formulate your question instead of just stating a line and another line.

Take a tip from the PW tutorial I am currently writing: Make a coffee, get a huge piece of paper, a pencil and an eraser, lie on the floor and get planning. You will get your approach worked out ten times as fast as you will on some new-fangled computer gizmo!

Cheers all! My code now looks like this and works perfectly: $template = $templates->get('your-details'); foreach ($template->fields as $field) { echo "<label for='$field->name'>" . $template->fieldgroup->getField($field, true)->label . "</label>"; ... EDIT: Which I see is the same as what Adrian posted above - it's nice when you come to the same conclusion separately sometimes though as you know it's definitely correct that way

Oh, one little tip if you like using JQuery plugins. The default PW installation comes with Styles and Scripts folders inside of templates. However, a lot of frameworks and JS plugins use css and js as folder names. When I start a new PW project, the first thing I do is change the names to css and js - I get less puzzling surprises that way!

Damn, you guys are quick. What Martijn said. Oh, and I use tpl-filename.php or inc-filename.php because Files then sort into type easily Notepad++ knows they are php

@Harmster: Yes, Hybridauth should handle most it. The processwire module should add social login / register functionality to a website or application (login using multiple providers such as Facebook, Google, Twitter and more). The module should have a configuration screen in the admin which allows admins to select the providers and enter their App ID and App Secret from the respective social network. apeisa has created a similar module only for Facebook login (Link - http://modules.processwire.com/modules/facebook-login/) I would like to develop a module that allows multiple social networks. @felix: glad you found the link helpful! Hopefully this module will be helpful to a lot of others as well!

I'm loving it!

PW's coding style is visible in any core file. But it's the same idea whether we're talking about code, graphic design, architecture or really anything someone would create: When it comes to code, that translates mostly to not adding extra unnecessary bytes: Avoid having an opening bracket "{" on its own line. Instead, just use a single space before an opening bracket. Only closing brackets "}" should be on their own line. Avoid use spaces for indentation, just tabs. This is what tabs were made for, not spaces. Use just one tab per indentation, of course. Avoid extra spaces around parenthesis unless you think it's really necessary. For example, it's preferable to use function(a, b) not function ( a, b ) Put a space after a comma, just so the comma doesn't visually melt into one of the adjacent letters. Don't put a closing PHP tag "?>" at the end of a file. Use camelCase for most variable and function names except for when the variable resolves to a database column or ProcessWire 'name', then use lowercase and underscores. Use camelCase for class names except always have the first character be uppercase, i.e 'CamelCase' (there may be a more specific term for this). Put a space before and after the concatenation operator, as it's small and disappears (or becomes a sentence period) too easily. For example use "a . b" and not "a.b". And of course, comment as much as possible. Comments are bytes that are always appreciated for communication. Outside of internal comments within the body of functions/methods, PHPdoc style is the standard we prefer. Honestly the biggest one for me is just the opening bracket thing. I can't follow code that contains opening brackets on their own line. It makes the opens and closes so visually similar that I can't can't easily tell them apart. It could be that my eyes aren't great, but at least for me that coding style creates legibility problems. I have to "fix" code before I can read it. With the style I'm using, when I see a bracket on a line (before I see the nuances of the serifs), at least I know it is always closing something.

Hi guys, I've been doing events sections for a few sites and for each I needed to make an iCal feed. I've wrapped up this functionality into a module now to make it a little easier for myself and anyone else that needs to make these feeds. The module is basically a simple wrapper around the iCalcreator library (a copy is included). It's modelled on the MarkupRSS module from Ryan, so anyone familiar with that should have a feed up and running in no time. Usage The module takes a PageArray and creates the feed from that. The [tt]->render[/tt] method will send the output to the browser with a generated filename and will automatically download. Because it will return HTTP headers, it has to be included before any html and is best in its own template or followed up by [tt]exit;[/tt] <?php $today = time(); $items = $pages->find("template=event, sort=start_date, start_date>$today"); $ics = $modules->get("MarkupiCalendar"); $ics->title = "Upcoming Events"; $ics->description = "Some upcoming events"; $ics->itemStartDateField = 'start_date'; $ics->itemEndDateField = 'end_date'; $ics->itemLocationField = 'location'; $ics->render($items); You can use the [tt]->renderFeed[/tt] method to return the output as a string instead, which is particularly useful if you want to debug or write the output to a file. <?php $today = time(); $items = $pages->find("template=event, sort=start_date, start_date>$today"); $ics = $modules->get("MarkupiCalendar"); $ics->title = "Upcoming Events"; $ics->description = "Some upcoming events"; $ics->itemStartDateField = 'start_date'; $ics->itemEndDateField = 'end_date'; $ics->itemLocationField = 'location'; $cal = $ics->renderFeed($items); echo $cal; I often put RSS and iCal feeds at the top of my listing pages so as not to clutter up the site tree with extra templates. This way /events/ may point to my events page, and /events/ical will point to it's feed. Here is an example: <?php // iCal feed if ($input->urlSegment1 == "ical") { $today = time(); $items = $page->children("sort=start_date, start_date>$today"); $ics = $modules->get("MarkupiCalendar"); $ics->title = "Upcoming Events"; $ics->description = "Upcoming events for my company"; $ics->itemStartDateField = 'start_date'; $ics->itemEndDateField = 'end_date'; $ics->itemLocationField = 'location'; $ics->url = $page->httpUrl; $ics->render($items); exit; } // Render the template as normal. include("./includes/head.inc"); Download and feedback You can download or fork the module here: https://github.com/f...MarkupiCalendar At the moment it only supports all day events (as these are all I have dealt with) but I hope to add time based events soon. Any feedback is warmly appreciated and feel free to report bugs or suggestions for improvement. Stephen

This is already old news to many of you here, but I finished writing up the full announcement today so figured I should post it (click the link below). Numerous upgrades and refinements make ProcessWire 2.4 our most friendly and powerful version yet! ProcessWire 2.4 is focused on listening to the feedback from of our users and answering with the best CMS experience for web designers/developers and their clients. Read the full announcement. For those upgrading from a previous version of ProcessWire, please read all of the upgrade instructions. Hope that you enjoy this new version! A huge thanks to Avoine for sponsoring the Field Dependencies feature new to ProcessWire 2.4!

ryan's inbox? Probably daily

Maybe this? (see Soma and Adrian's replies) - http://processwire.com/talk/topic/3338-echo-field-label/

It's stored in the fieldgroup. If you know the page, you can access it via the page.

At which point exactly does it simply explode?

Thanks for letting me know. Looks like there was a limit set in there, and I went ahead and removed that so hopefully it works now.

Oh, I told my text editor that .inc is the same as .php - it tried to go all logical and objectionable on me but I beat it into submission in the end.

Done

Okay (Sorry for double posting, but I think this is worthy of having its own post) https://github.com/hawiak/hybridauthforprocesswire I've started witht he devleopment, I haven't tested anything because I am running this on a local machine, as for now the module has a bunch of inputfields and generates an object hybridauth, this is then bound to a fuel in the init() method and hoepfully you will be able to use it in your project as $hybridauth. Are there people that could help me with this? Or atleast test it? EDIT: It does work for facebook: Ive put this on my index(It throws a redirect loop but thats because its on my index_ if (isset($_REQUEST['hauth_start'])){ Hybrid_Endpoint::process(); } $adapter = $hybridauth->authenticate("Facebook"); $user_profile = $adapter->getUserProfile(); print_r($user_profile);

Oh, really? Please, can you show me a example? (original | GD | and maybe one with imageMagick)

Alright, sounds really good, I'll take a look today I have a few days spare and I think the everyone here could find this enjoyable. I'll let you know

First I don't understand why you would send "unnecessary" pixels over the internet. I would say, don't send them and make the space you need with the HTML container element. Second, why do want to spoil server CPU for this. Third, if you want to make it your self difficult. here is the documentation.

@saml....thanks for your hard work...helping us to get there!

JFYI, the packaging is now ready, and ProcessWire is available as bitnami images: blog.bitnami.com/2014/02/processwire-added-to-bitnami-library.html So, now it's time to share share share!

Great work Ryan ! Marty the MACHINE !

Hi Radek, the Czech language pack isn't working just like the German one. Thanks for pointing to the environment, I will have a look at my setup. EDIT: I found the problem. It's the Windows environment and it's backslash pathes. PW uses the DIRECTORY_SEPARATOR constant in its php code that is a backslash character under Windows. Basically this is correct. But php isn't quite consistent in that matter. The translation function gets pathes with normal slashes although the code uses backslashes because of the DIRECTORY_SEPARATOR constant. The only function that seems to cause that problem is in "wire/modules/LanguageSupport/Languagetranslator.php": protected function textdomainString($textdomain) { if(is_string($textdomain) && strpos($textdomain, DIRECTORY_SEPARATOR) !== false) $textdomain = $this->filenameToTextdomain($textdomain); else if(is_object($textdomain)) $textdomain = $this->objectToTextdomain($textdomain); else $textdomain = strtolower($textdomain); // just in case there is an extension on it, remove it if(strpos($textdomain, '.')) $textdomain = basename($textdomain, '.json'); return $textdomain; } If you replace DIRECTORY_SEPARATOR with a simple '/', it works. (EDIT3: That change isn't enough, look at the posts below.) I don't know if there is a clean solution or if one should write it off as a Windows php quirk. A quick and dirty fix would be to check for a backslash and a normal slash as directory separator. EDIT2: In the subroutine "filenameToTextdomain" I found an existing directory separator fix: if(DIRECTORY_SEPARATOR != '/') $filename = str_replace(DIRECTORY_SEPARATOR, '/', $filename); But for the problem explained above it comes one subroutine to late. I think it's now on Ryan to decide where and how to fix that check for the DIRECTORY_SEPARATOR in the "textdomainString" function.

That line is too broad. If given the right ID, it could load anything in the site, including any user account. Narrow it down by supplying a template or parent or something to make sure you are getting what you expect. i.e. $theitem = $pages->get("template=item, id=$itm"); When comparing page objects (which is what users are) you'll want to compare the 'id' property: if($user->isSuperuser() || $theitem->createdUser->id == $user->id) { Also, you aren't checking that the page you retrieve actually exists. I'd suggest adding this: if(!$theitem->id) throw new WireException("That page doesn't exist"); That exception occurs when you try to delete a system page or a NullPage. When that exception occurs, it halts program execution immediately. If something still got deleted, it would have had to have happened before that exception occurred. It doesn't look like your code could generate that error, so I'd guess there's a hook into Pages::delete that is attempting to delete another page related to the first deletion. Also, before deleting the page, I suggest checking if it is deleteable from an access control perspective: if(!$theitem->deleteable()) throw new WireException("That page is not deleteable");

I've surely written some crappy replies earlier, but this was first one bad enough to be removed No need to restore anything, really. Main point of that reply was that this module had a bug that @dragan uncovered. When more than two languages were in use, values were getting stacked, i.e. version_control_for_text_fields__data contained property values such as "data10141015" instead of "data1015", "data101410151016" instead of "data1016" and so on. This is fixed in current version at GitHub so I strongly suggest everyone using this module to update to that. To fix existing data you have to replace those nonsensical values directly in your database: UPDATE version_control_for_text_fields__data SET property = 'data1015' where property = 'data10141015'; UPDATE version_control_for_text_fields__data SET property = 'data1016' where property = 'data101410151016'; # .. and so on, depending on actual language page IDs (broken values should be easy to spot)

Thanks Nico. After three weeks, we want to share our experience and some informations about the module and service. We think that an open and honest approach on this topic might help others to develop great commercial (and free) modules. minimize.pw started as an internal solution for a problem. Working with an agency with large PNGs, we searched for a way to compress them with PNGQuant. We thought that other developers would be interested in this kind of a service and that lead us to the decision to make it a commercial service. We have to pay for the servers and maintenance. The whole developement took around 3 days with some additional hours in writing backend jobs like backups and payment management. As today, 21 days after launch, we've only got a single "Free" signup and zero licences sold. We got some E-mails and questions but nothing more. Beside our internal usage on three client sites not much happened. We didn't expect much, but we thought there would at least be more free signups. So what went wrong? Well, we made some assumptions: There is no interest in this kind of service. The pricing is to high and the free plan isn't worth a look. Our website could't convince visitors to use the service To many open questions because there isn't a FAQ or something similar We just have to wait longer The module missed some important features We hope that the first point isn't true. With some feedback from twitter, we think that there is a market for some developers to use this service. The same applies to the last point - at least we should have some more signups. So we might have to improve the remaining 4 assumptions. In the next week, we will update our service/site: An improved and better free plan: You will get 1000 images per year and you don't have to renew after a month. More images on new paid plans (replacing the old monthly model):Standard with 30 000 images / year and up to three sites for 39€ Large with 100 000 images / year and ten sites, 99€ A new webpage with better examples and a FAQ. We will later add a case study with a larger site. Planned features for the module itself:Compression while uploading images Replace images instead of making variants (as an option) Usage with the Thumbnails module (CropImage) (An Async performance modus) But before doing this, we would be glad to hear what the community thinks about this. We would appreciate some feedback and/or your thoughts on the service and the module. P.S. Here is a special key with unlimited images and sites, valid for the next four weeks: zE1DptpPYN

If you guys are using 2.3 or 2.4 you might prefer: $this->wire('key', 'value'); rather than $this->setFuel('key', 'value'); and $this->wire('key'); rather than $this->fuel('key'). The "fuel" terminology is meant mainly for internal use rather than public API. It'll work, but I think it makes code more complex than it needs to be, versus just using that single wire() function for everything.

Kongondo, great video and module! I hope you'll add this one to the modules directory when ready. Also for those above, wanted to mention that Teppo's Changelog module is also a good way to look at what's been edited recently. In terms of having a list of "recent edits" display in the default admin theme, that kind of goes against the desire to keep the admin theme as minimal as possible. I don't disagree on the usefulness of it, just think it doesn't belong in the default admin theme. I'd rather leave that to other admin themes, or support such features in the future with theme-specific 3rd party installable modules or widgets (this could be fun).

Don't be afraid of PW and its modules, hooks etc. They're worth learning and not really complicated if you grasp the concept, really. Compared to other systems this is fairly simple. I showed you an example of a property hook in the RSS markup thread remember? Also there's some infos on the forum or other resources that would help you understand (I think teppo's write up here is also good). And of course the HelloWorld.module that comes with default install shows exactly those simple hooks. Play around with it and be in awe!

Create a field "counter" with type "integer" and set it as "hidden, not shown in the editor" or "always collapsed, requiring a click to open", as you prefer. Put this code on your template: $page->counter += 1; $page->of(false); $page->save('counter'); $page->of(true); echo $page->counter; voilá

I'm responding from phone so keeping it short: $image = $pages->get("template=page-headers, sort=random")->images->getRandom();