Leaderboard

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.

We can take criticism here, it's always helpful. It's true that 30 minutes really isn't enough to understand or evaluate ProcessWire, but I do like hearing the 30 minute perspective because I can see that is something we need to work on. While I think our audience is currently a bit different than WordPress, WP is the largest CMS platform by far and so we always have to pay attention as to how we're perceived by the WordPress community. I would like that perception to be one where people that enjoy WordPress would consider ProcessWire when they have needs to develop something beyond what WordPress specializes in. Not that WordPress couldn't handle it (it's powering some quite large and comprehensive sites) but that ProcessWire can accommodate more custom, complex and larger sites quite a bit more easily and efficiently, at least once you know ProcessWire. WP and PW are both useful tools for any developer to keep in their pocket. While you can develop quite a nice blog in PW, you may save yourself time to do it in WP. Likewise, you can develop quite large and complex sites in WP, but you would save your save quite a bit of time to do it in PW instead. That's an oversimplification of differences, but just saying that these tools aren't mutually exclusive. We're both on the LAMP and GNU teams too. As a side note, ProcessWire is here in part because of WordPress, or at least the founder. I didn't even know about WordPress at the time (beyond hearing it was something like Moveable Type), but was really inspired by Matt Mullenweg's speech at SXSW (I think it was 2006, it's been a few years), and that led me into open source. The way he spoke about open source struck a chord. We exchanged a couple of emails afterwards and I thanked him and told him I was going to develop ProcessWire as an open source project because his speech was such an inspiration. Prior to that it had been in development, but as a closed source project. It took more than 4 years and 2-rewrites before it was released, but that's where PW started as an open source project.

I strongly agree with apeisa here and, to be honest, I really don't understand this discussion about WP and PW. How could one compare this two systems? Imho PW targets a completely different group of users. Trying to move significant market share from WP to PW would mean to give up what makes PW unique. PW is a high precision instrument meant for experienced surgeons while WP is part of the medicine chest found in an average household. The have very few in common. I'm glad that it is like this and that PW can't be evaluated in 30 minutes (wait: it can. If you are experienced with web development you will discover its potential within 30 minutes while it takes some time to understand how to make use of it).

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.

Hi Jeff The first thing is about the young bit. Ryan first developed PW as a commercial system quite some years ago (he can give you the history if you are interested). He then made it open source in more recent years. Consequently, the core of ProcessWire (the Wire bit, if you like) is very stable and very developed. However, quite a few of the users on this forum are very experienced developers and coders, and this has helped speed up the development. I should point out, though, that this has not been at a break neck speed; Ryan is very much in control here and development is carefully undertaken. There are many differences between systems like PW and others like WP. The main difference between PW and WP is about the design philosophy. ProcessWire does not have any templating engine or system, it simply has a templates directory where you do most of your playing. The default install does have files in there, but to be honest, you could chuck most of them away (with the exception of admin.php) if you wanted to. Most of us do. So, if I want to design a site using, for instance, the Bootstrap CSS Framework, I simply shove it into the Templates directory as I would if it were going to be a static site. I can now create my file structure as I would normally. Perhaps a header and footer file, for instance. Maybe call these into a main template that I am using for a bunch of pages as I would do any other PHP structured website by using includes. Once I have done that, I just need to add the PW API to retrieve the information. Okay, so there is a little more to it than that, but the point is that anyone who has used Bootstrap would look at the templates and recognise just about everything that is going on there. That is incredibly powerful - it makes it accessible to many different levels of designers and developers very quickly. And that is important too - to a greater extent these are people trying to make a living; they need a system that works for them and does not force them down a particular route. More structured CMSs like WordPress need you to work in their way with their methods. That is great if that is what you want, but if you need to break out of that, you either have to get very imaginative or hope someone has done "a plugin for that." There is no doubt that you can get a fully featured WP site up faster than a PW site - but the PW site will be a lot more specific and tailored to the brief, and for most of us, that is far more important.

Hello there, I'm the author of the article on WPTavern, the infamous 30 minute trial article! I figured it would be nice to go to where the conversation is versus the other way around. So if you have any questions for me regarding my experience or anything else for that matter, I'm registered to the forum, but wouldn't want to derail the purpose of this thread. Also, thank you to those who have responded to the article in a respectful manner. I'm sure some of you think my article is like someone taking a crap on the project which is not what I did. The article is a simple documentation of my efforts to use and learn about the platform in 30 minutes in which case, that's all it took for me to decide it wasn't for me. The question is, how many people find ProcessWire, install it, and don't even give it 30 minutes before reaching the same conclusion? Is that even a concern or are those the people you don't want as part of your userbase anyways? Anyways, I'm happy to start a new thread specifically about my article or if someone else wants to do it. *** Moderator *** This topic was splitted from here. the original article that is discussed here can be found from here. -apeisa

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.

Great link Diogo. Thanks to you guys that replied to the article. It would really be quite an upset if a WordPress cheerleading site named WP Tavern came out with article saying they were switching their publishing platform to ProcessWire, wouldn't it?

I have just put a long post up to answer some of his points - in a gentle way. At the end of the day, ProcessWire IS a system for website development - that is its strength and what makes it better for serious business websites than WordPress. In itself it is not, and probably should not be, a drumlapress clone. I would not want it to be as that is why I have moved away from those kinds of CMS. Of course, it is perfectly possible to build a Drumlapress type CMS using PW as the backend, and maybe that ought to be done, but that is a different thing and would be addressing a different market. The interesting point is, of course, that though PW is a development package, rather than an plug-and-play, instantly themable, push-button, solution, it is amazingly easy to learn! Even for complete non-developers. But you really have to want to. If you don't then probably PW is not for you.

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).

@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

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.

On other news, I've just updated Swift Mailer bundled with the module from 5.0.3 to 5.2.1. This version includes a security fix, so anyone using this module should update. Note that the vulnerability doesn't affect this module; it's related to Reply-To, and this module doesn't, at the moment, use that in any way, but in case that someone is using the Swift Mailer library directly from this module's directory, that could still be a problem. Other updates added just today include minor fixes and vastly improved tools for testing mailing capabilities (including a tool for sending test messages directly from module's configuration screen).

I won't tell to much but I'm currently working on a theme module anyway. Website is already kind of ready: http://processthemes.com/ But I think we all should agree on at least one thing: ProcessWire should never integrate a real theme engine in it's core. never.

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?"

@reems: if there are all images already created, the imagesizer get not involved. I bet there are not all imagevariations created now. But 30 seconds is far to long for only 80 images. Maybe there is one corrupted image in or what ever. To get rid on it you may debug on which imagefiles it is called. This way you can track down the issue, I hope. If you have this on your local host you simply can add a line into the imagesizer file here, at the start of the resize function: $logentry = $this->filename; wire('log')->save( "debug_resizes", $logentry); This way you get a list in site/assets/logs/debug_resizes.txt with all filenames on which the imagesizer is called. (site/assets/logs/ must be writeable, what it should be by default) Just empty or delete the logfile if it contains previous entries and call your admin page that causes the issue only once and inspect the logfile afterwards. If you need further assistance come back please.

It's a good thing that ProcessWire has the flexibility of an Olympic gymnast. We can already extend it to so many different ways without having to somehow compromise the core package. Whether it's new site profiles, theming systems or whatever we can dream up, that's already doable. Doesn't mean that everyone has to love and use them, though. What I'm trying to say here is essentially that it's not away from you if someone builds a themable site profile. You don't have to use that, you are free to keep on doing what you're already doing. Relax. As an example of this from slightly different angle, I personally have a very strong dislike of so-called templating systems. From my point of view they complicate things unnecessarily and only result in worse quality. I'm still happy every time I hear that someone has built a cool templating system module for ProcessWire or a cool site using Twig / Smarty / whatever. That's good for them -- and what's good for them is usually good for the community. This is one comment here that really stuck with me, but not necessarily for the most obvious reason. I've seen many (nowadays) very competent developers emerging from the muddy waters of less flexible CMS'. I guess I mean that this works the other way around too; low barrier of entry brings in developers who might not be that experienced yet, but once they get the feel of it they can become very productive members of the community. Seen that happen here too. On the other hand, it's kind of sad seeing how some folks grow (professionally) in an environment that forces them to bad practices, and once they've reached a level at which they could do something really awesome, they keep trying to force that inflexible system to do something it was never intended to do, because it's the only thing they really know and jumping into another environment entirely is a scary thing to do.

Really interesting discussion here! Many very important aspects are already mentioned, many good points are made. But: reading the WPTavern / "30 minutes" article, I stumbled over one particular sentence: Wouldn't that be a nice idea? At your first login, right after the installation process (where such a thing would be misplaced). This welcome screen could contain: If you are a designer, then (intro, links, resources). If you are a developer then (intro, links to official tutorials, resources) and look at the beauty and effectiveness of this: $echo $pages->get("/products/2010/")->find("template=faq, body*=Tobiko")->first()->url; Such a screen could at least give a tease to the experienced developer to find out more. Therefore, the choice of links would be crucial. But, fortunately, an official set of tutorials is on the rise. And maybe, with such a screen, PW could increase the possibility to stand the "trial of 30 minutes." And for people like me, who start with a blank profile anyway you could offer an option to disable: $config->showWelcomeScreen = false, or so.

@Jeffro: Great to have you here! Thanks for joining the community, and thanks for writing about ProcessWire. @Joss: Just read your comment posted there and that is epic, you always have a way with words. I wish I had your gifts with words... composition... voiceovers... humor.... plants... and who knows what else you've mastered, but just glad you are here!

No one likes change or a honest appraisal. The big three (Wordpress, Joomla and Drupal) will not fair well against ProcessWire whenever a true comparison is done based on strictly technical requirements/capabilities for building actual websites, not blogs. We are all here because we have already dealt with those platforms, worked within their systems to improve their capabilities and unfortunately found them lacking for various reasons. Those platforms will improve over time, however so will ProcessWire. We need to just press ahead and keep doing what we are doing.

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

Fun fact: This is the pub

I splitted three pages of posts from here to https://processwire.com/talk/topic/7166-wp-tavern-article-and-processwire-themes/

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.

I've done it this way. I started my experience with some clan/guild cms's, learned some php with copy&paste, moved to joomla, learned more php, build my first templates, moved to wordpress, build a more sofisticated template, moved to processwire and felt free. No education other than learning by doing. With some free themes everyone could get in easily. Maybe someday they want to move some box to another place and learn about the api behind the theme. If they get interested they'll continue digging around and maybe some day develope their own themes.

@Macrura: sorry for the slow reply, but.. no. This is loosely related to a discussion at GitHub, here: https://github.com/ryancramerdesign/ProcessWire/issues/566. I'd like to hear what Ryan has to say about CC, BCC and attachments before going and putting together custom solution for that. My opinion is that all of these should be implemented in the base class (WireMail) so that WireMail module authors (at the moment meaning mostly me and Horst) don't have to cook up case-by-case solutions. Even if the modules still required some customisation and couldn't use WireMail features out of the box, at least we'd have compatible implementations.

The point which I miss in the discussion is quite simple. As a non-developer user wordpress is very much a blogpost-and-pages management system, not a content management system. Everyone which has the knowledge to turn wordpress into something more, also has enough knowledge to use processwire efficiently. The author of the article seems not to be one of those and even named what he wants to get a "Publishing System" in the headline. So the comparison was flawed from the beginning. He wants something, that processwire doesn't want or claim to be. The added discussion about themes, in my opinion, is also not correct. A theme is a readymade frontend-design for a specific purpose. The only difference to, what everyone here is doing only for his client, is that a theme is purchaseable/downloadable by the masses. Maybe some added simple customisation options from the backend. Just like some wordpress themes come with special extra functionality over the blogpost-and-pages base, a processwire theme does deliver only the functionality needed for the chosen purpose. In both cases, if more functionality is needed, than provided, you need someone to code the rest on top.

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

I've tried 30 years to understand MS Word and didn't succeed ...

@Nick: I'd like to point out that the approach you're taking is not what I'd advice on doing. It's very important to understand that ProcessWire is, first and foremost, a CMF. What this means is that it's very good at dealing with various content items (which it calls "pages"), describing the schema of those items, allowing you to manage them via API calls, define relations between them etc. Without going into too much detail about this, I'll just say that by using ProcessWire's own tools you are not just getting more benefit out of the system, but also more likely to build a solution that's manageable in the long run, easy to extend and update via built-in tools.. and, perhaps most importantly, as safe as possible (as long as you prefer API calls over SQL there's literally no way for SQL injection issues to creep into your code). What you are doing here sounds essentially like taking ProcessWire as a starting point but then coding an application that does effectively the same thing over and around it. This approach fits better one of the more bare-bones application frameworks (Zend Framework, Laravel etc.) It may seem like the obvious choice before you get to know ProcessWire's capacity and set of features (and there are valid use cases for it even then), but I hope you see why I don't think it's the best option in this case Anyway, since ultimately you should do what you see as the best option here: With ProcessWire you don't typically add columns to database tables or new tables to the database, so there's no UI for this (apart from PHPMyAdmin, of course, if you prefer something like that). You can communicate with the database using API variable $database, which is just a fancy way to use PDO style queries directly from your own code. You can see some examples of that in the source of my Version Control module. It's a bit old topic (there's probably newer material available too if you try searching the forum), but here's some discussion about custom login forms. Personally I tend to avoid custom login forms and rather allow users to login via native login page. This is connected to the fact that I don't like creating new custom Admin tools for them either and would much rather either let them use built-in tools or create a new Process module for them to use (method no. 3 in my earlier post). Hope this helps a bit.

Hey Everyone! right I'm nearing the end of development on this photography agencies site and I was wondering if anyone could have a quick look for bugs etc. http://nicegrp.co.uk/dev/hs/ It's not quite finished so there may be obvious stuff, also there's ALOT, going on in the front end, for example: - pages are cached client side (to prevent unnecessary ajax requests for seen pages) - Ajax page requests & pushstate - pdf module for gallery pages - slideshow animations - add image to your custom gallery - alot of menu logic - responsive - lazy loading images on gallery pages Let me know what you think. Thanks

I'm starting this topic for a problem I see with the German translations of relative times. But other languages may be affected as well. You can see the problem when the Lister module shows a column with a past date. In English it says "3 years ago" and in German it's translated to "3 Jahre vor". But it really should be "vor 3 Jahren". The phrase is constructed with the single translations of "years" and "ago" in the same order as it is in English. So the problem is about grammar and word order in the German translation. Maybe it could be solved by a list of translatable phrases with placeholders, so that it looks like "%d years ago" or in German "vor %d Jahren". That is just a quick thought and it probably should be discussed here before it is posted as an issue on github.

I think that pwired and horst have made some good points regarding the possible impact on the forum. Regarding online communities I have to say that the Processwire forum is the best I have seen and very valuable. I was just thinking today this place is better than the pub.

My reason to work with PW (formerly with MODX) is exactly because it gives me all the freedom to build my own site. I know HTML, CSS, semantics etc. Therefore I absolutely have no need for such click and play systems like Droomlapress. So I hope, PW will stay on the same route like nowadays. BTW: this discussion now has nothing to do with the topic "ProcessWire on the web"? Better moving this posts in an new thread, maybe under "Wishlist"?

I'm going to agree with Nico here; a properly built theming system, separate from core package, would be a godsend. I'm assuming that nobody really means that, but I can't help noticing that every time a discussion about having more site profiles, easier installation for site profiles, some sort of theming etc. raises it's head, there's a sudden and mutual urge to kill it with fire. The way I see it ... Site profiles are not away from core development. Ryan doesn't have to spend his time working on these. Easy method of picking the profile you like during installation would be cool, but not necessary. Theming isn't evil per se. We don't need theming support in core, we can build it using modules (as Nico said) or simply using template level code. I've done both.. without losing my sanity. If someone feels that having easy-to-use site profiles and plug-in modules is away from hardcore developers and flexibility of the core itself, think again. These are not mutually exclusive things. Just my five cents. Take it with a grain of salt, please -- I'm in the middle of coding streak and just needed to vent my brain for a sec. Keep on keeping on.

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.

I know I have said this before, but actually I find the default profile misleading. It hints towards AMS (article management systems) like Joomla and WP with a title field and large content area, whereas the true strength of ProcessWire is in the fact that you can start with no fields and then go which ever direction you like. This is why, for me personally, I would love the default to actually be a clean, blank install and then have a "Demo profile" as an optional download, which would replace the current default profile. When choosing which to download (or install, however it is finally managed) a little more emphasis could be placed on the fact there are other profiles available which may give you different starting points, like the one you are talking about here. This also may reduce the artificial comparisons between PW and Drumlapress and help PW to stand out more on its own.

I think you would probably want to take it further than just themes, so that it is closer to the functionality of Joomla or WP out of the box. But I have to say that this would hold no interest for me - it is not what I came to ProcessWire looking for.

I hope this can help you: http://yogeshchaugule.com/blog/2013/how-point-primary-domain-sub-folder-cpanel

Processwire: used by people who were looking for something better and used by talented coders who recognized pw´s internal core. Processwire is chosen and not followed. For some hard to swallow.

I came from another CMS that really really works very easy for the "enduser", lot of templates, lot of stuff (at these days more and more older crap/stuff) addons, snippets and so on. Great to get some small and middle Websites run - but there was no development now so i've to jump from the dead horse.... I never ever did not compare these two systems (my well known cms with PW) - since i searched with the approach to find a new system with a new workflow that give's me more power with less effort. I'm feeling like at home now - i'm kinda excited to push my first PW project and working on some private pages to test and getting more experience. For me 30 min was enought to see that there are so much options to get the system you like and control all the content you/user produce. I'm not a PHP dev - but i can sort things - read&learn a lot ->but the phrase "OneLiner" get a new dimension here with PW In my former CMS there was erverything - flamewars between other cms and userdiscussions on forks and so on....this leads to nothing. The bad thing of such articles is that they rarely objective. So there is no real reason to discuss. One opinion against the other. Best Regards mr-fan (sorry for the nonnative en)

I completely agree with these 3 comments. From a graphic designer point of view, it's like comparing inDesign and MS Word, you can, but for that you really have to focus on the audience. Might be a big temptation to try to please everyone, but PW would start suffering from the same problems that others do. I'm glad Ryan doesn't think like that, and we can be sure that PW will only get better. edit: try to spend 30 minutes working with inDesign without knowing anything about professional publishing systems and see how frustrated you will get.

Apeisa and Totoff are quite right - it is a different audience. Though I would put in the rider that the ProcessWire API does so much heavy lifting with such short phrases that it makes it amazingly simple to learn, even for novices (or old has-beens like me!) While it also leaves enough in the PHP realm and html realm not to force markup and construction on you that you then spend half the night trying to override. (A big Joomla sin, that one) A good, well balanced, tool box.

Greetings, Wow, 30 minutes! I think the author will spend more time reading the comments than he did with ProcessWire. Up next: after one hour with PHP, he decides it's not as good as Python. Unfortunately, I have spent way more than 30 minutes using Joomla, Drupal, and WordPress, so I could not help but weigh in on this one. Thanks, Matthew

As I told you before, you did wrong but well, whatever... it's an empty discussion and I doubt it will get richer than this. Maybe others will have the patience to listen to what you say, and I hope they will. I don't.

Jeff, first of all, welcome to the forum. I'm the one that commented in a less respectful way from your point of view. I give you credit for actually trying PW before commenting, I've seen others that didn't even do that before emitting an opinion, but I just don't think that's enough. Just think of how you assumed that one didn't even read the post to the end only because one didn't write an extensive and paternal comment (no pun intended Joss, your comment is great), or that one thinks you're taking crap on the project only because one didn't agree with you. The truth is that you didn't only document your 30 minute journey, but you had an ostensively negative tone against PW and against Mike's article that was 1000 times more careful, more scientific and more neutral than your own. edit: I also give credit to the fact that you're here. Don't take the above as an offence or something similar.

It''s great when you have a platform you don't have to make excuses for.

30 minutes with PW and he has an opinion!...Anyway, horses for courses

Table Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. Multipliers This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. Repeaters These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). PageTable This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.