Leaderboard

This little module allows you to store a month and day value in a single field. I originally needed it to specify how long a service runs for on a website - the type of service that runs from the same day and month every year (so datepicker wouldn't be useful there). It was more of a test to see how easy it is to build my own fieldtype - following ryan's map marker module and Soma's rangeslider module really helped and I have a few really good ideas for fieldtypes now It's not a particularly useful module as the same can be achieved with individual fields in a fieldset (well, with Month names stored as pages - something I didn't want to do) but I expanded on it a bit and made it multilingual-friendly with month names etc. On the admin side, you select a month and day from the two drop-downs, and on the front-end you can call them indovidually as numbers like this: echo $fieldname->day; echo $fieldname->month; or formatted as per the option under the field's "details" tab like this: echo $fieldname->formatted; which will display something like "April 20" which is USA-friendly (I think), but you can change the default formatting as per details here: http://php.net/strftime All in all, but of a niche field that probably won't get used much as you could even achieve the same with a text field and type it in, but I wanted the actual numerical day and month to perform date range calculations against a calendar so it needed to be more foolproof. FieldtypeDayMonth.zip

A way to handle this ( how i think could be managed, many options here). Extend the user template with the fields you need. Upon subscription, check is a user exists with email address and check its role. If user exists, update the data.

For storing data like the subscriptions i wouldn't use repeaters. I would use pages or else a custom table in db. Even if the max number of subscibers wil be 20 or so. The next time you will need the script, you've probably to rewrite the whole script cause that that low amount of subscribers is rare i think. Handling data from repeaters is more tricky and need more custom code then when you use pages as storage. My need for repeaters are rare, maybe for an image slider or populate tables.

I believe these types of articles only serve as a distraction. They are popular and get a lot of press. Even if Wordpress had 99% of the webpages it doesn't make it a better product than ProcessWire. I have used Wordpress and Joomla for customer sites, in the past. They were a tool that got the job done, then, because I wasn't aware/knowledgeable of better tools. Since, I have discovered ProcessWire, I now know that those tools aren't appropriate for seriously developing websites or web applications. They have great strengths but also many technical weaknesses. Anyone who seriously compares Wordpress, Joomla or Drupal to ProcessWire and then states that technically those 3 are better, is not dealing with reality. I could spend the next year learning about all the remarkable things you can do with ProcessWire. I now believe the only limitation is your imagination.

Thank you, Ryan, for your welcome an your detailed reply to my question. Meanwhile I have continued searching and reading the forum, and combined with your remarks I now have moved from "close to beeing convinced" to "beeing absolutely convinced" of processwire as my future tool! I will work out all of your suggestions and try to find and realize my user management concept in the front end. Beeing absolutely new to processwire I just wanted to avoid running into a dead end right at the start of my project. Now I know that there will be a solution within the scope of processwire, maybe with some additional code and customizing.

Welcome to the forums Steve! In ProcessWire "superuser" is a special role that can do everything, regardless of any access/permission settings. Managing fields templates and users is typically the job of superuser. If you've got a non-superuser with "user-admin" permission, then they won't be able to edit or add superusers. But they'll be able to edit/add anyone else. Templates and fields are only accessible to superuser. Actually you could add a template-admin or field-admin permission to a user to give them access to these things, but the need is very rare. That's why these permissions are not included by default with PW. This is only the case if the user-admin is creating new roles and assigning them to templates. It doesn't sound like your user-admins would need that ability. Your admin user would have a role with page-edit permission, and you'd assign that role to any templates used by pages you want them to edit. Beyond knowing that "superuser" is allowed to do anything, ProcessWire doesn't necessarily know that one role is beneath another, and I'm not sure that it could unless you had some of your own logic to it. So you'd probably want to create your own front-end user tool for this, use hooks, or modify the behavior of the existing ProcessUser module. You can do this relatively easily by copying the existing /wire/modules/Process/ProcessUser.module to /site/modules/ProcessUserCustom.module, modify it to work the way you want it, and edit the page /admin/access/users/ and change the "Process" field on that page to your custom version of it. Though if the intention is simply to have the ability to add or delete users easily, I think a front-end tool (or your own admin tool) would be simplest. That's because you could take out the role considerations (less for your editors to think or know about), handling that automatically based on your needs. All of your access control scenarios seem within the scope of the system, except for the one that needs to know about one user defined role being considered above another one. But there are numerous ways to handle that, like mentioned.

That's essentially what the multi-language support solutions are doing. PW 2.4 doesn't change or add anything in this regard. Careful with use of the term "module" in this context, just because that means something different in ProcessWire (a plugin). And things like blog and search are not modules in ProcessWire, but things that you build with pages. However, you can restrict a search to any branch in the tree just by calling find() on the page that represents that branch, rather than $pages. For example: $pages->find("your selector"); // searches entire site $pages->get('/products/2013/')->find("your selector"); // searches everything below /products/2013/ $pages->get('/products/2013/')->children("your selector"); // searches only immediate children of /products/2013/ There are forum and shop modules (by @apeisa). But these are both labeled as "proof of concept" modules, meaning they are not necessary turn-key solutions so much as solutions for you to examine, learn from, build from, adapt to your needs. I also don't think that these modules are deigned for multiple-installations on the same site, but not positive. I'm not sure you need to let the needs of user accounts dictate the approach. I personally would be more inclined to isolate the user accounts from the sites for this particular need, perhaps running a separate PW installation that is dedicated to just managing the user accounts for all the domains. But I'm not really sure what the best route is without giving it more time. There are already forum solutions out there that people have spent years developing and making them the best. IPBoard is one of them. We couldn't duplicate that unless we also spent years doing the same. Regardless of how many forum solutions get built as ProcessWire modules, I don't see us moving away from a dedicated platform like IPBoard for this.

Hi Everyone! I'm glad to show you guys my first Processwire project: http://www.ihera.com.br/ It's a simple yet tailor made website I did for a clinic specialized in women health in Brazil. We've designed/coded several templates for the backend, used the Skeleton CSS Framework (http://www.getskeleton.com/) to help making it responsive adn some some minor javascript to some pages - and of course, made it very SEO friendly with custom titles and meta description for each page. I'd like to thank Ryan again for this amazing tool! I've never done such a tailor made CMS (Wordpress, Joomla, Drupal, CMS - I've been there) that's so easy to use that my client didn't need more than 10 minutes of "training" and is super happy about the outcome and the ease of maintaining it. Simple, amazing and beautiful. Best of all: the code is clean and since you code the templates from scratch, you know exactly what is what and speed and great clean markup is an obvious result of it... Let me know what you think! Tks a lot! jw

Any decent web developer knowing php will be able to step into advanced PW building without problems. Not true to other system I know of.

Hi Debbylevinson, A quick one. The most important thing to do before you try to recover the site is to backup the /site/ folder and the database if you haven't done that already. Make sure you do that before taking any action. I'm pressed for time ATM but you have several alternatives...Before that... check in /wire/config.php There you will see the ID of the superuser and the role ID of the superuser. In PW 2.3 these are 41 and 38 respectively. You can also see this in phMyAdmin if you look under field_roles and pages. So, under the table "pages", find the name of the page with ID 41 (see "name" column). If you are still unsure about what to do, I'd be happy to chat via PM.

Hi guys, I've been spending the past couple days trying to get myself acquainted with PW... and I find myself swaying between excitement and discouragement. I'm excited because I'm really loving the way PW works but discouraged because I can't help but feel that I'm in way over my head. I'm not sure if this is in part because I still haven't reached the "AHA!" moment, but I'm also just very frustrated with my own lack of PHP knowledge (it's even less than I originally thought - at this moment, I think I'm completely PHP illiterate). Now, I really don't want to give up on PW, so I come here in hopes that someone can help point me towards the best way to approach "learning beyond the basics". I've gone through the various tutorials in the wiki and followed the Basic Website Tutorial as well, felt like I have a decent general grasp of things. Then I decided to upload and take a look at the blog profile. It had a lot of features I'm looking to implement, so I thought it would be good to see how things are done and make changes where necessary... except I think I ended up getting overwhelmed by it. Simply put, I can't make heads or tails out of a lot (most) of the PHP coding I see in the template files - never mind adapt it to the site I want to build! So, I've got a few questions. For someone who isn't a developer, would you say that jumping in and trying to take the Blog Profile apart is a bad idea? Is that considered advanced territory? Should I have just tried to build everything from scratch and add in the extra features step by step? Though, I'm not even sure how I would go about doing that, to be honest. I'm just lost. The basic stuff, I can grasp... like if I were to build a "static" site with various sections and some content, I can do that with PW at this point. The problem is, I think, the more advanced parts - as in, where and how to grow from the basics. I don't know where to even begin to tackle things, especially when it comes to specific customization. For example, I could probably copy and paste code for implementing comments... but then because I can't even understand what I'm copying or how to code PHP, I don't know how to make little changes, like say if I want to make it so that admin comments are styled differently, or if I want to load up Gravatar if one exists and if not then a default avatar, etc. Stuff like that. I'm sorry if this sounds like I'm just rambling randomly... it's just that I think I'm stuck at that point between being able to do the basic stuff but not having a single idea as to how to grow beyond that - short of going off to take some intensive PHP courses or something. So I guess my bottom line question is, how doable is PW for someone who doesn't know any PHP (and isn't just going to build a basic site with some content)? Am I better off not jumping into the deep end without at least knowing some PHP first? I've mostly built sites on ExpressionEngine and a bit of Textpattern in the past, so landing in pages of PHP code makes me feel like a foreigner in a strange country. And while I'm here, may I just quickly ask what the difference between $page and $pages is? The Basic Website Tutorial mentioned it a bit, but I'm not sure I truly understand when to use which... and what it means when pulling content from the page or another page? I sincerely apologize for my newbie whining...

Dear all, I started with PW a few weeks ago, and found myself in the same situation as the OP of this thread. The forum contains many useful information and advices, however it's just not easy to search for everything, especially when I don't have the big picture yet. There are simply too much information and one doesn't know where to start. I wonder if it makes sense to have a huge wiki page containing questions, divided into logical sessions. The answer for each question would be either a very brief sentence as a hint, or an URL to a relevant post in the forum or wiki. I can imagine myself finding this "map" useful, just like when I enter a huge mall for the first time and need some orientation before I start exploring. It could help the communication between new comers like me and the experts who are willing to help but are tired by the same trivial questions repeated all the time. For example, one question/answer could be: Q. I installed PQ and played a bit with the basic profile, now how I can make the next steps? A. Read thread http://processwire.com/talk/topic/3215-newbie-overwhelmed/, especially the answer by Ryan. Regards, Tony

For a number of decades, there was over 50% vehicle ownership of Ford automobiles. Were they the best? Nope, heck no, not by a long shot. Things changed at some point, and Chevy, Chrysler, AMG, and many others sprouted greater/better ideas. Muscle cars were born. Economy cars took reign. I'm not impressed with which sales are the highest, which has a higher user base, or which is wanted more *cough*iApple*cough*WordPress*cough* I am impressed when the underdog brings to the light the customization, the ingenuity, the talent, the speed ... that's impressive.

That's pretty much how I approach new projects now I have ProcessWire as my development tool I also wonder as to how one can accurately work out a percentage of any tool's use on the web? Is there any way of working this out for every website everywhere in the world, or are the statistics coming from a small subset, like those that show up in Alexa rankings? It's an impressive statistic if it's even remotely accurate, but it's not going to lure me in by any means

The PageArray part is called "type hinting" in PHP. It is the developers way of telling PHP that it should throw an error if it's given something other than a PageArray. That way the developer doesn't have to write extra code in the function to make sure it's been dealing with the right type of info passed to it before attempting to use it. For the consumers of the function (you and me), it's also useful just purely for readability and knowing what it expects you to give it. It's also nice to know that you'll get a consistent error immediately if you give a function the wrong info. Like if you passed in a Page rather than PageArray, you'd know right away, rather than trying to figure out for some time why the function isn't working. If we had a function that we wanted to accept multiple types, like say arrays, strings and ints, then of course we would not want to type hint like that. We would probably just have myfunction($something) instead.

Hi Formmailer, very useful module. I just want to mention that some of us have problem with it under PW 2.3.1 DEV. See this thread: http://processwire.com/talk/topic/3768-processwire-231-dev-branch/page-2 What happend to me: Out of the blue the module was unpublishing every single page on my system which had a template with your scheduer fields. Also Ryan found an issue, see his comment #36 in the mentioned thread.

Looks like this was the KEY HINT to solving all our mistery bugs for find() and get(). (The most scary bugs are features which work only sometimes, with no reproducible pattern.) THIS TIP SHOULD BE THE #1 HINT IN CASE OF TROUBLE. I know were it came from: We built one language tree first with all its many sub-pages. Then we duplicated the tree to make that the basis for language translations. So the clone module might have an issue - or it should just be common practice to refresh indexes manually this way after an excessive cloning. Thank you again for your time and valuable support!

Hi Pete. thank you very much for this confirmation. This was the last big unsolved "mystery bug" from my list. Maybe it is time now to contact the author...

I can actually confirm it's SchedulePages that's causing at least the unpublish issue - I meant to post about that a few weeks back as one site's news that used that module had all the news unpublish itself at random - every time I'd re-publish it it would un-publish within 24 hours. I ended up uninstalling the module and everything was back to normal.

The first one is more reusable. If for some reason you would want to render the posts on another page, or simply use a different array then children, you wouldn't be able to do it with the second option. But, if you do this: function renderBlogPosts(PageArray $items = $page->children) { You can call the function with renderBlogPosts() on the original page, but be able to pass a parameter on any other page: renderBlogPosts($pages->find("template=post"))

I'm on vacation, but the yesterday it starts with rain. (little spare time & good excuse to continue this module). A lot of progress is made with this module, It's now to the point of testing / bug fixing & fine tuning. I've added it to the modules directory and it is in a pending state. If you have a little spare time, please test this module. Thank You, Martijn.

Nice catches. These same steps helped me. Thanks a bunchload @Soma! This really helped me. This + your Simple Site profile installed splendidly for me. Such a time-saver!

Check out the settings of your Page field under the "Input" tab: Custom selector to find selectable pages This means, you can also exclude things, e.g. template!=admin, id!=1897, parent!=id_of_parent_of_children_that_are_not_selectable

Yes, other roles can edit pages if you give them the permission...otherwise it will be meaningless to only have superuser edit pages, hehe...But, you also have to give them (the roles) permissions under Template -> Access When editing a user, you see this at the bottom of the page: Btw, remember to remove those extra permissions you gave the Guest in your tests Edit: Visibility of pages for custom users depends on the permissions you give them (not really on "hide page" settings you see when editing the page) Edit2: One other thing, be mindful of role inheritance... http://processwire.com/api/user-access/roles/

$items is a parameter of the function. When you use the function like this: renderNav($page->children), the array $page->children will be attributed to the variable $items inside the function. exactly the same as if you would do: $items = $page->children. that function could have been written also like this: function renderNav($items, $options) { instead of: function renderNav(PageArray $items, array $options = array()) { The difference is that, in the second example (the real one), the function is forcing us to use a PageArray for $items, and a regular array for $options. Plus, in the second parameter, the function also defines a default value to $options (in this case, an empty array), so you don't have to define a second parameter when using the function.

@Gabi: this sounded like an interesting idea, so I mocked up a proof-of-concept module (Page Render Relocate Assets) that dynamically alters asset requests to point to another location. This isn't, however, something you should yet consider production-ready. Idea is quite simple: the module just hooks after page render and alters generated markup, converting any requests to /site/assets/ to another URL specified via module settings. Just to be on the safe side this (at the moment) only alters requests that start with a double quote and /site/assets, ie. "... src="/site/assets/..." would get replaced, while "Look at my /site/assets/!" or "... src="http://example.com/site/assets/..." wouldn't. To test this I created a new subdomain and pointed it to my own sites /site/assets/. According to this blog post this should be enough, and so far things seem to work just fine. You can see it in action here: http://www.flamingruby.com/about/. Note that one of the images on that page is (for some CKEditor-related reason) embedded with full URL and thus doesn't get "relocated", but other one (the bike) should point to static.flamingruby.com instead. .. so to answer to your question here: changing assets location would require a lot of work at the moment, but this way you can serve them without useless cookies etc. as long as that's what you're after. If you're looking to share the load between multiple servers or something like that, this alone won't do the trick (though if combined with some kind of server-side replication that would be quite possible too.) I might have to take this module a bit further at some point, I'm kind of starting to like where this is going

40k! We are massages pros!

Thanks for that! Loved the name 'Dictator' !

Welcome to the forums. Those problems with XP computer seems to be network problems. Does all other sites work ok from that computer? Also one possible solution (probably not in this case but might be worth trying) is to modify /site/config.php and set $config->sessionFingerprint = false; This will keep you logged in even if you have dynamic IP address.

Just to make sure: you're running Windows? Which PHP version? Based on some quick Googling, this sounds like a Win + PHP issue, reported in various places and affecting (at least some revisions of) PHP 5.3 and even 5.4. Edit: only place where PW uses mcrypt_create_iv() is Password.php, to generate random base64 strings for salts. If you're in a hurry, you could try commenting out that whole block (lines 160..163), but after that you really should make sure that this method still provides sensible output. I'm not too familiar with what's happening there, so I'd still suggest that you either try to fix this somehow else or at least wait for someone who knows better to step in and help with this.

Updated code to v1.0.3 - this is an upgrade to the core Minify package (not my module or ProcessWire's code) to address a serious security issue. This update is SERIOUSLY recomended for anyone using this module! Thanks arjen for the heads-up! EDIT: Also worth noting that it was the main developer behind this forum software who noticed the flaw and suggested a fix to the Minify developers - I've also updated the Minify code in these forums. If you use Minify as a standalone package (ie. not this module, but the code available from the above link) elsewhere it would be worthwhile updating it wherever you have installed it. The issue is likely to be present in other JS/CSS minify modules/plugins in other CMS' that use the code from the above link too - I've spotted at least two WordPress modules for example that use the same codebase and there may well be others, so please bear that in mind if you use other systems.

Thanks for all the support, Ryan, Diogo, Soma and all the other forum members. I just finished my first pWire site. Although I still have to add the iOS icons and Soma´s great module for navigation markup doesn't seem to have the ability to limit the children <li> on my main menu, I will get that solved later. After a few weeks I'm very happy with process wire and every time I ask something here I feel a bit dumb. Process Wire simplicity to get things done is amazing! Thanks to kongondo too for the modx to pWire transition post: http://bit.ly/1dYgAnW You can check this simple and a bit text bloated pWire site here: http://artecassistencia.com

Heh, now we got 3 mailchimp modules separately that do work differently. I'm holding mine back as it is a lot more complicated to create a good mailchimp module with remote managing lists and campaigns. Lists can't be created via API, reason being that you should work with segments and groups for a list instead of creating a list for every group. This is to avoid creating too many lists. But this get's a little more expensive in "recreating" the functionality Mailchimp already has done very very well. One thing that is different from your module for example is I don't use PW user but pages. I create campaigns for lists and submit them from a newsletter created from a special page the user can edit and select for submission. So far I haven't got the time to invest and list management is still missing, kinda what you got here but as said not for PW users. But it has a nice admin interface to create campaings and see part of statistics after sending. Thing is that to make it really efficient (as the requests are limited) it would need to have caching built in so it doesn't need to request all those informations everytime, kinda what they suggest in their API docs. We maybe should work all together I'm on holiday currently in Turkey this week, but maybe I can find some time to share module.

Like Arjen said, $pages->get("gallery") will not get you anything; you will get an unknown selector operator since PW doesn't know what gallery is Lots of "get" examples here: http://processwire.com/api/variables/pages/ http://processwire.com/api/variables/page/

Thank you all, I'm glad the interview is as interesting and informative for you as it was for me, and thanks to Ryan, couldn't have done it without him

Greetings, Excellent interview! Ryan comes across as brilliant and extremely likeable -- which we all know is a true portrait. Thanks, Matthew

Very interesting. It's nice to know more about the behind the scenes of PW.

Yup, great interview as always Mary. That's how I remember you when I was once digging your articles, tuto's and posts about modx evo. Only this time it's about a never seen before cms that truly adapts to a user / client / designer and coder. Also liked it to read about how pw came to be together with the history of the man behind of it. Besides another good summary of the open potential of pw, the whole interview also inspires a newbie to try to make more out of projects with the help of pw.

Thanks for the interview Mary!

It's possible that your index tree needs a refresh. Try dragging the entire /en/ page (tree) below a new parent. Drop it there and let it sit for 5 seconds. Then drag it back to have home as the parent. Now try your query again and see if it's showing up when using has_parent.

Hi Grays, welcome to the forum. Even though I have been playing with PW for a couple months now, I too am still very green and new to it. I was in the same boat as you and still am trying to grasp the basics, but take the advice of everyone else above. The people here on the forums are very helpful and friendly. Don't be afraid to ask questions. There are a lot of smart peeps here and I find this is one of the most friendliest, most responsive CMS forums of them all. Make friends with other newbies (such as myself) and follow the questions they ask. Seach the forums for the ones asking basic questions and those will more likely be the newbies. I think for me, the best thing I could do was to take it slow and lower my expectations. I fell in love with PW right off the bat and wanted to be a a pro in it. But, even though I had read a few PHP books and took some courses beforehand, in reality I was lost and dissapointed. It's more a mental/confidence thing with me, but once I accepted the fact that it was going to take some time, and I wasn't going to be an immediate whiz, things got easier. So. I started off (still am) doing the basics, one thing at a time. Break up your site into smaller parts and work on each one by one. When you get something simple working, your pride will fuel the next challenge and before you know it, you'll be at the top. Analyze the code here in the forums and don't just copy/paste. Try to really understand it by cross checking with how PHP works. A great thread started not long ago on learning PHP is here. You may not understand it in one try, I know I didn't. Sometimes it takes days or weeks for something to "click" in your head. Read, re-read, read again. Things DO get easier but it takes time, and time is the secret. Practice helps. It's inspiring what you can do with PW and what keeps me going is knowing this is the best CMS out there. I have researched and tried almost all of them over the years, but nothing compares to PW. I am inspired every day to continue learning and not giving up because it's absolutely worth it. MY breakdown to how I am learning: Take it slow. Break code examples down line by line. Moving on to the next line only after knowing what each before it does. You'll get it! Don't attempt something expecting results the first time. Take pride in humiliation. You can only learn after making mistakes. Read this PW wiki Study Codecademy PHP course along with a couple PHP books. Try to go through every forum completly. Go through each page one by one, bookmarking where you left off. I do this before I go to bed. Before you know it, you'll have read all the forum topics and can know be updated when new threads post. ask questions. I know this can be kinda hard because you don't want to look like an "insert insult", but the truth of the matter is if everyone is afraid to ask then it's hard for newbies like you and I to find answers to basic questions. It's a win win for everyone and the CMS itself. breaking down basic elements of a site one section at a time and searching the forums for how to do it (navigation, multi-level navigation, photo gallery, forms, etc..) You may have to read multiple threads but it's all there. Good luck and don't give up! I can never look back at any other CMS, even during times when I'm frustrated or lost! I only get frustrated with PW because I do not know YET how to proficient. I was frustrated USING other CMS's because of how they were built and I knew their code. Says a lot right there.

I would say that the blog profile is not the best place to start. It uses more advanced techniques and was designed to be a demonstration of them– These are techniques I don't even use in my own site development, but felt like we needed a profile that would appeal to those looking for a dedicated MVC strategy. The best place to start really is the basic profile that comes with ProcessWire. When you understand that, you really can build anything. If you are wanting to go further, you might like to look at the skyscrapers profile. But the important thing to remember is that there is no "right" way to build your site in PW. This is why even tutorials can be a mixed blessing when you are learning, because they reflect one approach that may not necessary be the right one for you. Beyond the basic profile, you just need to read $page, $pages, PageArray and about Template files. Ignore everything else, because you may never need it. Don't feel like you need to remember or understand everything on those pages. But read through them and make note of what's there. These pages cover 99% of what you will do in ProcessWire from the code side… and probably a lot you won't ever use too. Once you get going and developing stuff, you'll want to keep the Cheatsheet open, which has sections that cover what's on those links above more succinctly. In ProcessWire, you should be comfortable with HTML markup and CSS. But it's less important that you know PHP. You only need to learn a few basics. You really don't need to know any more than you need to know EE tags. Know how to get in and out of PHP from HTML markup. i.e. <?php ... ?> Know what a $variable is – just a place to store a value. Most ProcessWire API functions return a value. Know how to use an if() statement. In PW, you'd use an if() to test if something had a value you wanted to output. Know how to use a foreach(). In PW, you'd use a foreach() to cycle through a page's children, or the results of a $pages->find(...). Know how to output a value, whether: <?php echo $value; ?> or <?=$value?> …both do the same thing. Know how to use include() to include another file, i.e. "<?php include("./header.inc"); ?> I think that covers all you would have to know to do most things from the PHP side in ProcessWire. Can anyone think of anything major I'm missing? Lastly, when you are developing, enable debug mode in /site/config.php: $config->debug = true; This will ensure that you get helpful error messages rather than ambiguous ones.

I like your idea of adding a "wire" template language! We can just stop referring to it as PHP and then all of the sudden people will see: wow this is a really easy template language.

Very well said Ryan, couldn't agree more. While I know I wouldn't use template language, I think that might well make PW a little bit more beginner friendly. Not sure if it is worth the trouble (vs. writing more tutorials, getting started materials etc..). Also maybe we could cheat a little here, and tell that PW uses templating language called "Wire", which looks like this: Output a variable: <?= $page->title ?> Loop for children: <? foreach ($page->children as $p): ?> <h2><?= $p->title ?> <? endforeach; ?>

I've always thought that the "template engines make it easy for non-programmers" was a myth, as it really just comes down to semantics and what characters you think are easier to type. But the reality is that template engines give you something like a jailed environment, and that increases the comfort level of some people. The prospect of limitation becomes an asset in that context. It means it's going to be harder to break things, and there is going to be a ceiling on what can be learned. I don't ever want to be in a "jailed" environment with a low ceiling, but also kind of understand the appeal to someone that may have never stepped beyond the likes of EE (which has come crossover with our audience). As we work to broaden the audience for ProcessWire, an alternate template engine for those that desire limitation here may help us to capture new audiences. There is also just the word "PHP", which scares off some, regardless of what is real or what we do. ProcessWire is always going to be an PHP API-driven environment at it's core, but I'm not opposed to adding on template engine(s) as an option for those that want them, in the future. It's something that's not at the top of the list on priorities, but it is something we'd like to eventually offer. They are a little more tricky to implement in PW vs. a system that is built purely for tags. The reason for this is that ProcessWire templates are executed directly by PHP rather than by ProcessWire itself. ProcessWire just hands off some API variables to the templates and lets PHP and the template execute natively. It's nice, fast and efficient. (Other systems like EE actually execute PHP code in templates using eval(); which is slow and inefficient… they hope you won't be using much PHP). The way we'd have to implement a template engine in ProcessWire, while still retaining the speed, is with compiled templates. The template using template-tags would have to be compiled to a native PHP template before it could be executed. Lots of these new template engines are designed to work that way anyway, so not a big deal, but just outlining how it would be done.

Hm, I don't really think it's extreme. When someone decided to install the software on a server, had to mess around with permissions and so... he has to be ready to learn the hard things of life

I really don't see that much difference between {% for item in navigation %} <li><a href="{{ item.url }}">{{ item.title }}</a></li> {% endfor %} and <?php foreach($navigation as $item): ?> <li><a href="<?= $item->url ?>"><?= $item->title ?></a></li> <?php endforeach; ?> If you write it like this, you can forget the }} as much as the ?> Of course the Twig code looks a little more friendly at the first sight, but the advantages of getting used to writting PHP are worth it.

Happened to have a PW site open, so I did some grepping (is that a word? should be..) and seems to me that you're absolutely right. No short tags found from core files. @Natetronn, I'm trying to avoid getting all evangelical here, so I'm keeping this as short as possible: IMHO learning enough PHP to write templates effectively is much easier task than learning enough of most templating languages out there to do the same. PHP has very good documentation (php.net), wide user base (try googling pretty much any problem you're having and add "stackoverflow" to your query, it's rare to find a question someone hasn't already answered there) and there are many fantastic tutorials floating around. "It's easier than you think." That said, I don't have that much experience with templating languages -- mostly I've used Twig and several in-company solutions, so I'm not much of an expert on this subject. All I can say is that after years of learning, fighting and cursing various templating languages and their shortcomings, being able to write templates in pure PHP is a bliss for me

Not evangelical at all, as I'm not even an experienced programmer. I only learned PHP in the past few months, and I can say it was mostly because of the way PW is thought out. As a Designer I never thought I would be writing some rather advanced PHP so soon, but because PW uses PHP instead of a templating engine, and because it's designed to make it so easy for anyone to achieve basic tasks, you just feel encouraged to go further and further without any constraints. Really, just start building a website with PW without thinking of external tools, you don't even need to install any of the excellent custom modules that are already available, and you will see how easy it is and how powerful it can get

Hi. and welcome to the forum! There's not really a point on implement something like this in Processwire. PW use of PHP is very well thought to make it easy to anyone with no PHP skills to learn and use. Have a look at this page where Ryan explains this design decision http://processwire.com/api/why-php-syntax/. The context of this quote is a blog ready-to-use PW install. Ryan meant that this profile should be as easy for non-programmers to start using immediately.