Leaderboard

In case anyone is interested in trying out some of the things I was talking about in previous posts here, the latest dev branch has a field import/export function. You'll see it in the lower right corner of Setup > Fields. It enables you to copy and paste any fields across any PW installations. Locally, I also have this working for templates (with fieldgroups), though that part needs a little more work so it's not yet committed. I also have fields, templates and fieldgroups mirroring every change to JSON files, as an option that can be enabled for those that want to version these things with Git and what not. That part also isn't yet committed to dev, but will be soon. However, I figured the copy/paste function probably had the largest use potential. It makes migrating field changes (or creation of new fields) quite a simple task. Next up on the commits will be the same thing for templates (with fieldgroups). (note I didn't take these screenshots together, so they aren't referencing the same fields).

Hi guys, As some of you know I'm part of the Milktop team, but strategically we decided to go back to the format we had one year ago and recover ED Design, my collaboration with Erika. Today we are launching our website. http://ed-works.com/ This is a soft launch only for the PW community because I trust that this is the best place possible to have a site tested I hope soon I can write a case study. Hope you guys like it! (still some work to be done concerning SEO and accessibility)

@valan: I very much enjoyed reading your comments and many of them are familiar, in one form or another. Thank you for your input! One thing I do not fully agree, though, is the notion of "adding stuff to core". I get that the core has to evolve, but that doesn't necessarily mean it has to grow -- and in this single post, you're (in a way) suggesting three new additions: payment tools, some sort of MVC setup and Bootstrap (well, this is not so much an addition as it would be replacement for jQuery UI used right now). My opinion is that the core package has to remain as small and lean as possible. Any single addition to it has to be something that very high percentage of PW sites require -- and even then, if it can be sensibly built as a separate module/feature, in many cases I'd go with that. One of ProcessWire's key strengths is that it's modular and very flexible. We don't need features like payment modules, Form Builder, MVC template structure, site profiles (themeable or not), just to name a few, in the core, as those can all be built separately and plugged in when needed. This reduces the bloat that some other systems suffer from. Just my five cents.

Hi forum, I got a new one online last week: www.ecotec.de A fully responsive website for a German consulting firm specialized in cost-cutting strategies for industries with high energy consumption. Again based on my - evolved - Unsemantic Site Profile which allows for responsive sites compatible down to IE7. The site incorporates a former stand-alone WP blog which has been integrated into the new site. For this I used the new Migrator and Wordpess Migrator modules and got grandiose personal support from adrian and nico. Thank you guys, you were extremely helpful and patient. Other modules used: Admin Save Actions AIOM+ Email Obfuscator Markup Simple Navigation and Superfish flyout navigation (not a PW module) However, though I learned a lot from this project and improved my coding skills, I didn't fall in love with the site. In particular I'm unhappy with the purple/gray color scheme. Originally the project scope included a - soft - redesign of the brand appearance. But while the process was ongoing, my client somehow realized that he was still in love with his logo, his Futura font (buh!) and his purple primary color (buh, buh!). We had some very tough discussions about this in the middle of the project, but what can you do? At the end, here we are: in a purple dream. I hope I made the best out of it. One last thing (no, not what you think): The front page doesn't validate. The validator claims open elements in the blog posts section of the front page. For heaven's sake, I can't find an error in my code. So, if someone finds out why, please let me know. Cheers

From my point of view - the critical points of PW in that article are the best for me Some day i've read a very interesting article about "Are you a tooler?" (i think it was AListApart - not shure) So for me i was until now in the world of "toolers" - using this addon, snippet, module to make the system i choose to do what i want - because in lack of skills to bending this system complet to fit my/customers needs. Always willing to learn and helped some real devs out with testing and translating - to get some help on the different things. And now with ProcessWire i feel like i'm a "thinker"!! I've ONE tool to use in different kind of models/usecases/options to get what i want. Ok as usual and first i've tested all the modules and addons in the rack - but i feel they are all just needed for a special propose and not to get a website work great like this is the fact for the drulapress CMS world!! Every week i'm reading this forum i'll get new ideas how to use PW from this really great community (Like to set up a "onliner" with a hidden pagetree to get a complete tagsystem running or other usefull stuff) Themes are for me no problem - get a HTML Theme from ever you want and setup is done in about let's say "30 minutes" So are you a tooler or a thinker? Are we talking about a software that helps you working without a limit - or a tool that complete works for you but always have it's limitations you have to take? Thankyou Ryan for this one great tool - thank all others here as far as i read this forum - here is a meetup with great people! 2 cents from a guy that love PW after 30 minutes testing

Valan, I think PW's great independent success owes a lot to it not being like other CMS. It is a strong tool for building websites. It is not trying to be a new Wordpress, there is little to be gained (as far as I see it) from trying to bridge the gap between the two. Rather to keep working on what makes it special and flexible ( a great example of this are the new pro tools) Give us more power but not more bloat

Wow - works really great. I like both things - will definitely start putting field&template changes under version control, but also love how this will simplify even the simplest scenarios: exporting & importing some features from one site to another (or from dev environment to live).

Fun fact: This is the pub

My 2 cents, and sorry if I'm repeating things that have already been said – didn't have the time to read everything already posted here. Wordpress has become vastly popular as a blog system. It is being used by a gazillion of people worldwide, most of them not very tech-savvy, which is why there is a huge market for prefabricated themes and plugins. It started out as a small open source project, but is now – at least partially – being developed by a company with about 250 employees plus a very active community of freelance developers. Due to its huge popularity, it has morphed into a system which can also be used as a CMS. This exponential growth into the most popular content publishing system worldwide has taken it's toll. It's bloated, there are unmaintained plugins, it has security issues and if you look closely, the sheer number of themes and plugins does not necessarily say much about their quality. (Did I just hear someone say “Windows”? Nevermind.) ProcessWire is a content management framework/system which was originally developed by a single developer. The community is picking up lately with more people developing plugins as well as contributing to the core while the system also gains traction with a small, but loyal user community. It's clearly not a system for everyone, mostly based on the design of the system. It might never become a system for end users, but obviously it has become rather popular among developers looking for certain features in a CMF/CMS. Why anyone would seriously want to compare both systems is beyond me.

1. Closer than you believe: https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes/?p=68899 2. I have something coming for these, although probably on much simpler scale than Omnipay. 3. I don't understand what you are saying here. First you are talking about bootstrap at admin, but then go into FormBuilder (which is for front end). PW has great form class (Inputfields), that you are free to use on front- and backend. Can you explain a bit so I can follow? 4. New Tutorials section is pretty much for it: http://processwire.com/docs/tutorials/ also extended cheatsheet is coming (it's like php manual).

I still think that if a complex profile were to be created that had theming, widgets, other expected fair, then it should be on its own site with its own support. It would be "built" on ProcessWire, but it would no longer be the core PW. Likewise, if a full blown e-commerce system was built on PW (now, that would make far more sense as a project), then that too should be on its own site with its own support structure. There is a bit of me that says that to create a themable version of PW seems more to be fulfilling the idea of attracting WP type users, than does it achieve anything huge. I am part way writing a tutorial to help WP and Joomla designers and developers to make the transition to PW. It is not a technical "how to" but more about how you need to change you way of planning and working and thinking. In the process, it strikes me that there are already lots of perfectly good "out-of-the-box" pop-up type CMS solutions out there. As I write the tutorial and explain the strengths, they tend to be more about the fact that is hasn't got a theme or template engine, that it does not rely on bespoke plugins to create functionality and so on. Its core strength is that unlike WordPress which is really an AMS (Article Management System), ProcessWire is a true Content management System - you create content with it and then you manage it. Separately you work out how to display it. Importantly, if you discard the current default profile and, instead, install it with a blank profile, its strengths are much more obvious, The default profile with sample pages and some images, misleads you into thinking it is something like the rest of the AMSs out there. When you have nothing except a title field, an admin.php and a home.php (no html of course, just a single $page->title call on its own), then its nature as a true CMS is clear. To paraphrase old MS marketing: "Welcome to PW. What content would you like to manage today?"

Well basically when you follow the RESTful approach when creating systems, you use resources rather than actions. you can know more here http://restcookbook.com/ http://restpatterns.org/ http://www.restapitutorial.com/ and this books https://leanpub.com/build-apis-you-wont-hate http://www.soa-in-practice.com/ Example if you want to make an admin for the users resource. you can have this URL http://api.example.com/users In the traditional CRUD aproach, the verb is inside the URL like http://api.example.com/users/create but in REST you must use only HTTP Verbs to interact, so the same endpoint url makes different actions depending on the verb used to call it. In our system that could be http://api.example.com/users GET - result in a list of users POST - creates a new user ------------------------------------- http://api.example.com/users/clsource GET - result in the user data PUT - updates the all the data of a specific user PATCH - updates a specific data field of a specific user DELETE - deletes the user Using the HTTP response codes and mime types you can notify the result of an operation, usually with a JSON or XML body for information. The Web services Approach, specially REST web services, enables us to separate complex systems in smaller ones, easier to mantain and test. Basically you can have multiple backend systems that just are APIs and one frontend system that glue them all. this add a layer of security and robustness, because you can separate your systems in different servers. A possible attack can not affect all the system, just small parts of it.

Hello, I created a simple REST helper in order to create REST APIs with Processwire, without depending on external routers Here you go!. https://gist.github.com/clsource/dc7be74afcbfc5fe752c

1) Introduction A great ProcessWire site is useless without visitors. If the site lacks of direct traffic, the webmaster has to rely on search engine users clicking on the right result. The goal is a good position on the result pages of special keywords. Optimizing sites for search engines, mostly Google, is called Search Engine Optimization (SEO). You will find many of techniques, methods and ideas on the internet. The topic is widely discussed and new ways of SEO arrive every day. This tutorial covers the technical aspect for SEO with the ProcessWire CMS and should give you a general overview on the topic. 2) Why ProcessWire fits perfectly to your SEO strategy With ProcessWire, nearly all practices for SEO can be used. It might be one of the best CMS in this field. Let us explain these bold claims. Every SEO aspect is related to the content on your page. It can be some meta tags in the HTML-Head or how you structure your headings. Even microformats are just another way of how markup is presented to the visitor (or the search engine bot). After all, it's the logic on how we generate the HTML that we try to optimize. Where to put the content, how to define a site description or how URLs are made up. Most SEO modules for common CMS like WordPress or Drupal are generating the right markup. ProcessWire is a little bit different. As you might know, there is no pre-defined markup. Every line of front-end HTML code can be written by the programmer. As a result, there is no limit on how we can structure the HTML. You want those new fancy HEAD Attributes? No problem. Grab the first image of a gallery and define it as the meta og:image? Easy job, even if you need a special resolution for Facebook and a smaller one for Twitter. So, what do we have to do? We can't just simply install a one-click "SEO module". We have to define, which fields will represent which HTML attribute or how we wrap the content into microformat schemas. Ask yourself the following questions: Which values(keywords,descriptions,information) do I need for my SEO strategy? Are those values stored per page, for a section of your site or can they be defined for the whole site? Should the user/administrator enter those values or can they be combined/calculated based on other fields? What happens if there is no value defined for a field? How does the fallback look like? Beside that, some good practices for SEO are already implemented by ProcessWire. The URL structure representing the page tree is clean and you can even customize it to fit to your requirements. Unique URLs are standard. With modules like ProCache, MinimizePW or AIOM you can optimize page speed quick. Everything else, expect the server performance is part of the undefined HTML markup. 3) Example on how to integrate meta tags (or anything you like) We want to have some keywords and a (short) description in our HTML Head. So we create two fields, calling them e.g. keywords and description and add them to a template. Create a page with that template and enter some keywords and a description. In your template file output the fields in the HTML head: <meta name="description" content="<? echo $page->description ;?>"/> That's all. We can now extend this to have fallback or choose the fields with a more advanced logic. Nico explains this for example in his blog post. Extra hint: If we want to fallback on the (mandatory) title field of a page, we can use the ->get Method. <meta name="description" content="<? echo $page->get('description|title');?>"/> This will use the title field in case the description field is empty. You could use this to provide the user an option to "override" the SEO logic by manually entering the values. Another example would be the alt-tag for images. To provide an alt-tag for an image, we use the description field of the image field. In this example, we take the first image from the field "images" on the page. <img src="<? echo $page->images->first()->url ;?>" alt="<? echo $page->images->first()->description;?>"/> The description attribute is part of every PageImage field. You could hide it from the backend but it's visible by default. 4) Modules for SEO 4.1) XML Sitemap This module will generate a sitemap.xml that can be crawled and used by search engines. The basic setup just generates a sitemap.xml with every page included. You can finetune the settings if you want. 4.2) Textformater Microformats This module sets microformats for content in TextAreas/WYSIWYG areas. It will wrap basic content into the right schema.org schema. The module page provides further information 4.3) Page path history Moving a page to another URL? With this module you don't have to worry about visitors getting an 404 error. It will try to track changes in the URL of pages and redirect visitors to the new location - as long as there isn't a new page with the URL. 4.4) Multisite Sometimes you want to have some entry-pages for special keywords. If you need a special domainname for those site, you can setup the Multisite module. 5) Further links and tutorials Categorize content and build the right URLs. Might be useful for SEO strategies. Rebuild the URL structure by using URL-segments Another forum entry on the topic of SEO 6) Conclusion Maybe this little tutorials helps starters to get an idea, on how to optimize their page for search engines. This might seem little bit more difficult then just to install a one-click solution. But if you put in an hour to just think about a clean and readable markup with all tags, you will get great results. Any additions or practices are welcome. I will try to answer any questions in this thread and make the tutorial better over time.

Soma, thanks for testing it out. I'm guessing there are a few Fieldtypes it's not going to work with yet (I've tested most, but not yet all). This whole system should be considered alpha at this stage, so the usual disclaimer applies: use it for play rather than production. In the case of the error message you got there, it looks like FIeldtypeCache has a bug where its attempting to access its DB table before the field exists. I think this is something that has to be fixed in FieldtyepCache rather than import/export. But I would like the export/import to capture those kinds of exceptions, so this'll be a good one to test with while I fix it.

It's ok, bu there's a official cheatsheet thread from back then https://processwire.com/talk/topic/681-processwire-cheatsheet/ I'm not sure why fieldgroups isn't in the docs. Ryan had some reasons I guess, I just converted his PW docs to a cheatsheet back then. fieldgroups are basicly templates and are hidden as it's only needed for more advanced development and don't play a big role on the "front-end" usage of the API. * The existance of Fieldgroups is hidden at the ProcessWire web admin level * as it appears that fields are attached directly to Templates. However, they * are separated in the API in case want want to have fieldgroups used by * multiple templates in the future (like ProcessWire 1.x). After all I'm not against adding it if Ryan thinks also it should be there. Thanks for bringing this up.

I was working on a new fieldtype the last couple days and seen the export method and was wondering "what the hell is that?" Looks awesome!

This subject is already been discussed so many times before and still has repeat = on. Don´t try to bring pw to the level where you want to use it. Instead bring your self to the level of pw and do what you want. Processwire is designed that way and maybe Ryan should put that somewhere clear during a pw install to set repeat = off.

Create new role, let's call it "editor" Add editor role these permissions: page-edit page-delete page-move page-sort page-template Hint: don't give "user-admin" role. Publish role and then go into templates => home => access (tab) => check edit, create and add children checboxes for editor role. That should be it.

Markup Simple Navigation Module While there was a lot of people asking how to make navigation, and there were many examples around already (apeisa, ryan...) I took the chance to sit down 2-3 hours to make a simple navigation module. It has even some options you can control some aspects of the output. Installation: 1. Put this module's folder "MarkupSimpleNavigation" into your /site/modules folder. 2. Go to your module Install page and click "Check for new modules". It will appear under the section Markup. Click "install" button. Done. Technically you don't even need to install it, after the first load call ( $modules->get("MarkupSimpleNavigation") ) it will install automaticly on first request if it isn't already. But it feels better. However, it will not be "autoloaded" by Processwire unless you load it in one of your php templates. Documentation: https://github.com/somatonic/MarkupSimpleNavigation/blob/master/README.md Modules Repository processwire.com mods.pw/u Download on github https://github.com/somatonic/MarkupSimpleNavigation Advanced example with hooks creating a Bootstrap 2.3.2 Multilevel Navbar https://gist.github.com/somatonic/6258081 I use hooks to manipulate certain attributes and classes to li's and anchors. If you understand the concept you can do a lot with this Module.

Thanks for those tips guys but the problem ist still present. I did a fresh install of PW 2.4. Made a copy of the whole installed PW. Did a fresh install of the latest dev version. I replaced the .htaccess with the one from the 2.4 install. Server error. I followed the steps in the troubleshooting guide by commenting out the lines one by one. Nothing. The strange thing is that everything works. Even the Multilanguage mod installation. The server error instantly appears when I click on the "Languages Support - Fields" install button. Hm, well I think I have to wait for the stable 2.5 release then. Hope this error will not come up with the final version. Thanks guys

Very sleek, very cool, very wonderful. However, some comments on the German version: I'm on chrome (latest) and win 8.1. the font looks very washed out, fuzzy (see screenshot). Generally speaking, the copy-writing could be a bit more let's say "laid back" or "inspired". Some examples: "Unser Service umfasst, aber beschränkt sich nicht auf:" -> very complicated sentence. why not make two sentences out of it? "Nach einigen Wochen intensiver Arbeit ist unsere neue Webseite endlich geschaltet!" -> "Nach einigen Wochen intensiver Arbeit ist unsere neue Webseite endlich online!" Yes, online is an English word - but wtf, it sounds better. And - advise from an advertising guy - no one cares if it was weeks of hard work. It's online, that's the news that matters). "diesen ganau zu befolgen" -> "diesen genau zu befolgen" - but apart from that, that's kind of officialese, somehow not the perfect fit for a portfolio website. Just a few examples. If possible for you, I would suggest to get in touch with a German friend who is experienced with copy-writing. I'm sure she/he could contribute to your website. But, apart from that, great design, great functionality. Cool.

Don't understand it completely but you display images descriptions of an image field with multiple images like this: <?php // get the images (if your image field is called "images") $images = $page->images; // do a foreach loop to display each image foreach($images as $image) { // now you can use all of the image's attributes like description echo $image->description; // or the url echo $image->url; }

I really like where this is heading! I'd like to see it handle all Modules as well... It could really improve our workflow.

Added it as an issue: Thanks Nico.

The configuration as it applies to Fieldtype or Inputfield modules is exported/imported. If you are talking about other modules (like the configuration that's in Admin > Modules > Site or Core), then it's certainly feasible to do it the same way. Something to consider for the future.

There is a roadmap which is open for additions.

@horst good to hear. I have another patch which will more more awesome then . Don't forget to add `private static $mysql_gone = false;` in the `wire/core/DatabaseQuery.php`. And the execute changes to public function execute() { try { $database = $this->wire('database'); $query = $database->prepare($this->getQuery()); $result = $query->execute(); if (self::$mysql_gone) { self::$mysql_gone = false; } } catch (Exception $e) { if (self::$mysql_gone) { throw new Exception("It is better to exit than throwing error " . $e->getMessage()); } else { // try once again $msg = $e->getMessage(); if (strstr($msg, 'MySQL server has gone away')) { self::$mysql_gone = true; $database->closePdo(); sleep(20); $this->execute(); } else { throw new Exception($e->getMessage()); } } } return $query; } Discussion on github https://github.com/ryancramerdesign/ProcessWire/pull/563#issuecomment-50871518

Error 500 is normally a .htaccess error. Take a look at this troubleshooting guide: http://processwire.com/docs/tutorials/troubleshooting-guide . If it shouldn't work please come back here

Great Site! I have chosen the german language on the desktop (win7 FF31) and mobile (iOS). Everything looks very good. My only thought: maybe the navigation arrows under the sliders should also be visible on the desktop? Have found 2 or 3 typos: not sure about a typo: "unter der Verwendung eines der fexibelsten Content Management Systems." => should it be "... Content Management Systeme." ? sure a typo at page signature: "komminiziert" => "kommuniziert", "Merzedes" => "Mercedes" typo (or not?) at http://ed-works.com/de/projects/small-mobile-big-hands/ : "wurden mehrerer Notizbücher" => "wurden mehrere n Notizbüchern" ? "Radaktion" => "Redaktion" I wish much success and good customer!

Looks really really helpful!

Great looking site! Some observations from a 5 inch (xperia z) smartphone, android 4.4.2 and chrome and firefox: - The top language menu is quite hard to operate due to it's small height. When i tap precisely i can operate it in FF, in chrome however, when i do get the language menu to open up i at the same time seem to be hitting a home link, making it impossible to switch languages. - When i open and then close the main menu the background color remains grey. Not sure if this is intended because in the initial closed state the menu background is just white, in line with the rest of the page. - The project images that rotate on the homepage have different heights, causing the funny effect (at least to me) that the content that comes beneath it keeps getting nudged up and down. That concludes my quick points, written while hunting for bloodthirsty mosquitos that are keeping me from sleeping

Amazing!

That looks awesome Ryan!

OK The error could be somewhere in the .htaccess file. Have you got the new and original (pre-upgrade) versions of this file? If so, you could try swapping them over to see if one works.

@LostKobrakai: You are right, but only to, maybe 80 - 90%. I also can understand pwired a bit. Just imagine the client from your example chooses PW one day because it supports 1-click theme-switching for those who are willing to use it. Additionally to that he can import a whole WP-blogsite content by using the WP-migrator with only clicking two or three buttons. What do you think does this do to him if he later on want to extend his site with a cool shopping cart, a newsletter system and some other shiny things he has read from here? I bet he think that this can be done with just clicking some buttons, because he has changed to PW because he has heard this is better than XY before. Also his first steps really only needed some simple clicks. So why should he think that this cannot be done that easy? Also the community is so friendly and helpful. - If he has only little or no HTML/CSS skills and no PHP/JS skills, (and maybe he also has no interest in learning this), I only can say: good luck and a lot of patience with such new users. So, it will be different with those who are able and willing to understand the differences of application modules. We should do it in a relaxed manner. One of the best goods here (besides PW itself) is the helpful and kind community. And it takes time to "assimilate" new users from that spectrum. Also I think it only could be a small amount at a time. - The worst case would be if they try to assimilate us

Nothing would change as people, who are happy with a ready to install template, wouldn't even care if it's build on processwire or in wordpress or something other. Page-profiles already do install a shiny template, but they can be build more easily/powerful as the wordpress ones. The people, who try to alter it in a serious way, will be more than happy to face a great cms with talented people on the forums. Templates aren't more than a prepacked website like all the ones we build here, only that they'll be used by more than one client. The plug&play mentality of wordpress is another issue. I work with a client, who tried to install a members-only area + simple shop on their wordpress website with only little html/css knowledge. Didn't work out for him, but that's stuff that a client should not be able to even try.

Imagine what would happen if PW should change into an out of the box cms with shiny templates, plug and play, 1 click add-on's, etc. etc. Everything would start to degrade right away even the forum. The inner architecture of pw is one of the clear reasons why this forum is filled with talented coders, people who know what they are doing and people who want to learn. A great side effect of working with pw and being on this forum is that it pushes less talented coders to upgrade their coding skills. This is many times the preferred way. If people need shiny templates, banners, slideshows or other things then tutorials on how to do this with pw would be the best way I think.

Hello, If ProcessWire goes down the road of theming, I would be very vocally against it. Along with "themes" comes a set of assumptions and core approaches that many of us detest. One of the main reasons I fled from Joomla, Drupal, WordPress is specifically because of theming. Anyway, providing themes would be a temporary attraction to people accustomed to the way the "Big Three" CMSs work. The moment users of those other systems need something further, they again would have to understand core design/markup/interactive web technologies. Beyond superficial themes, the general fact that ProcessWire is different will become apparent again. In other words, the differences between ProcessWire and the Big Three goes far beyond profiles or themes. It's somewhat of a waste of energy for us to appeal to Big Three users with themes or profiles. I think we need to be clear that ProcessWire is a system that expects you to take some initiative to get up to speed on the core web technologies. It is not, and should not become, a system that "does it for you." It may be difficult to accept, but ProcessWire will never appeal to most WordPress/Drupal/Joomla users for that reason. Thanks, Matthew

I think most of us go little bit too hard on this article: it was mostly a well written response to a Mike's "PW vs. WP" article, responding some of the reasons that Mike underlined why they moved from WP to PW. It was honest about the scope regarding ProcessWire (30 minutes, looked for demo, visited forums etc, but mainly just first impression). It also has nice summary about why PW is not Jeff's next publishing system: PW audience seems to be developers (instead of "I just want cool looking website without any coding") It doesn't do out of the box things that Jeff excepts from publishing system PW doesn't have themes PW and WP are totally different tools and I think that both Mike's and Jeff's articles showed that it is pretty hard to have "head to head" comparisons between these two. I really enjoyed reading both articles, and I believe that most developers who end up reading those articles (and their comments!) probably will at least try ProcessWire. Now we should also try to get people from Laravel, Zend, Django, Drupal etc. crowds to try PW. I think that is much more interesting crowd than your regular "hi, I created WP site in 5 minutes" people. Developers using those frameworks are building the greatest stuff there is currently. Of course lot to learn from WP camp also, but I would really focus on developers and framework side of PW instead of "best website builder there is". It's not surprise that WordPress seems to be heading also to more "general cms / framework / platform" direction instead of "easy to use publishing". The latter is very competitive market, with all those website builders like squarespace, virb, weebly, wix, google sites.. even facebook etc. You need keep developers happy, to make sure cool things are coming in future too.

Greetings, Apeisa & Totoff: I agree that comparing WordPress and ProcessWire is a flawed approach. What can you do in 30 minutes? You can conclude that the systems are inherently different. But the review we are discussing here, after 30 minutes, still ends by comparing ProcessWire on WordPress terms. Any review that can't conclude that the systems have very different concepts, and are for very different audiences, has failed. My analogy from woodworking: WordPress, Drupal, and Joomla are like pre-made project kits. All the wood pieces are cut to the right sizes for you, numbered according to how they must be assembled, with pre-drilled holes. You even get a set of various sized screws, a little bottle of glue, three mini cans of paint (just enough for the project), and a set of instructions you need to follow. With ProcessWire, it’s more like you have a project idea, and you jot down the sizes of all the parts and make a list of all the hardware you need, choose your own paint colors and glue. Then you go to the store to buy it all. In the end, the project kit looks like everyone else who bought the same one. The one you made yourself takes longer, but it does more, and it’s unique. Thanks, Matthew

Well, I have spend under 30 minutes reviewing many systems. If it doesn't meet any of the expectations, then 30 minutes is more than enough. I find Jeff's article pretty good - I would assume that first impression is pretty much that, if you just wander around admin and look for buttons that do cool things for your site. If we want to go after big wp audience, then we would really need to focus on things like themes, plug and play modules etc. I would keep our audience where it is (people who are build websites, rookies and experienced). When developers are in, the rest will follow.

@Hari KT: In the whole time since your first patch (5 month until now), it occured max 2 or 3 times, not more, but also not zero. Thanks for sharing your code!

https://processwire.com/talk/topic/2505-templates-structure-functions-best-practices/ https://processwire.com/talk/topic/1139-some-generalbest-practices-questions/ https://processwire.com/talk/topic/4507-pw-best-practices-application-structure-form-handling/ https://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/

> We use a user interface here for exactly what a user interface is meant for. Agree - however... > I would consider myself very lazy and remiss in my responsibilities if I expected people to use text files (YAML or otherwise) as the primarily method of configuratio I don't think anyone has proposed or suggested that? We're proposing a supplement/alternative, not a replacement. At least I would never suggest that, and I don't think that's what rajo was trying to imply. Ryan, do you have any thoughts on what I mentioned a couple of times earlier - changing the API internally to use a command pattern for changes to the data model? If every change to the data-model had to be submitted to a command processor in the form of an object, and those objects could be serialized, and assuming the command processor was hookable, that would make it trivial to implement all kinds of synchronization / change management / logging / recording modules. The problem with manipulating schema directly, is you can't only tell whether something changed, not how it changed or why - you are already working around this fact by introducing things like change-tracking internally in the objects, which need to know what changes were made. For example, when a field gets renamed, there are methods to capture that change and work around it's side-effects. When dealing with schema, I find it safer to have a centralized facility through which detailed records of change pass through - rather than manipulating individual aspects of the schema independently here and there. Template changes and Field changes, for example, are closely related because they are components of the same schema model - yet these changes are completely unrelated at the API level. A command facility could provide a central API point where all schema-related changes would be exposed, even future (and even third-party) changes would pass through it, so for example a synchronization module could work with future/third-party extensions to the data-model...

I'm a .NET web application developer so I naturally like to host my sites with IIS. I also do some Wordpress on the side and host those sites on IIS as well. I was excited about trying out processwire because I'm attracted to the content-type-first approach. I tried a few Themeforest Wordpress templates and I felt like they didn't use Custom Types where I thought they should and if they did there were extraneous meta-boxes that confused me and my clients. It took me a while to find this post and the sample web.config. I searched the forums for web.config and came up with over 100 results. Then I tried to search for IIS but it's only 3 letters so it didn't work. Finally I tried "web.config" and found this post. I recommend putting instructions on the Download page (maybe just a short blurb and the web.config file) or on the Requirements page or FAQ or somewhere where new IIS users like myself can easily find it. I created my database, downloaded the zip, loaded the folder in WebMatrix, ran the site, ran through the installer, and everything worked like a charm until I clicked on "About" and got a 404 error. I purchased a HTML template from Themeforest and can't wait to cut it up for Processwire. I plan on creating types for FAQs, Testimonials, and gallery posts. I also purchased the Wordpress template of the same theme so this will provide me a great comparison. TL DR: It would be good if a sample up-to-date web.config file was on the Download or Requirements page. Thanks! Philip

what.i use this is good it does.work top {not buttock}, of htaccess u will.put it . enjoy <IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 1 seconds" ExpiresByType image/x-icon "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType image/png "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType text/javascript "access plus 1 month" ExpiresByType application/octet-stream "access plus 1 month" ExpiresByType application/x-javascript "access plus 1 month" </IfModule> <IfModule mod_headers.c> <FilesMatch "\\.(ico|jpe?g|png|gif|swf|woff)$"> Header set Cache-Control "max-age=31536000, public" </FilesMatch> <FilesMatch "\\.(css)$"> Header set Cache-Control "max-age=2692000, public" </FilesMatch> <FilesMatch "\\.(js)$"> Header set Cache-Control "max-age=2692000, private" </FilesMatch> <FilesMatch "\.(js|css|xml|gz)$"> Header append Vary: Accept-Encoding </FilesMatch> Header unset ETag Header append Cache-Control "public" </IfModule> <IfModule mod_deflate.c> AddOutputFilter DEFLATE js css AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html </IfModule>

Hi there! The following code grabs first three images from the field "images" $firstThree = $page->images->slice(0, 3); foreach ($firstThree as $i) { // Output goes here }