Leaderboard

Just want to share this with you guys, To commemorate the launching of our new website https://processwire.com/talk/topic/7170-ed-design/ we decided to share a title font that we used on one of our projects under the SIL Open Font License (OFL). The font is available for download as otf and as webfont package on our site here and open for collaboration on Github and Open Font Library (you can also embed it from there). If you like it, use it and enjoy

You should read up about what localhost means. MAMP (which i haven't used, because i'm on Windows) is just a convenience package for having PHP, MySQL and Apache run on your computer, in essence a webserver with PHP and MySQL available. This (Apache) webserver serves pages on http://localhost/ , most of the time on port 80, so that would be http://localhost:80/ . Localhost is basically a shortcut to the IP-adress that represents your own system, IP 127.0.0.1 So MAMP also makes http://localhost available. This will have a set document root. http://localhost[=docroot]/myproject[=subfolder]/ Sometimes this will cause problems with the rewritebase settings in the .htaccess file that comes with PW. So you need to change settings, and probably rechange when you put the stuff on a live domain, such as myproject.com. This is maybe not a real big deal but there can be other disadvantages of developing locally with sub-folders of localhost. One that comes to mind is links that you insert via a Rich Text Editor. Like the others have said, vhosts allow you to basically map a directory anywhere on your file-system to be the documentroot for a domain of your choosing. For example: http://myproject.development could be address that you could access in your browser while your project files could be anywhere. Of course, MAMP, also allows for these kinds of setups. MAMP PRO seems to have built-in options. For regular MAMP there are enough guides on Google, for example: http://sawmac.com/mamp/virtual/ http://foundationphp.com/tutorials/vhosts_mamp.php

my favourite 2 ways are by no specific order: 1. Add a "featured" checkbox to each page and show the last 3: $pages->find('featured=1, sort=-date, limit=3'); 2. Add a page field in the homepage where your client can add pages, and show the top 3 from that field.

Say you have a local 'domain' called 'mydomain.dev' then you can reach it in your browser at http://mydomain.dev, and the manager at http://mydomain.dev/processwire/. This way your local environment have the same url structure as the live situation. etc.

Manlio, I may not be able to give you specifics but here's a couple of things... Registration You say this but then add this I am a bit confused. To clarify, you mean that you will not be registering NEW users because you already have users, right? Users What format is your table in? CSV, SQL? Importing is not difficult but we need to know the format they are in. Yes, extending the users template is easy and is normally the way to go. There's various examples on the forums. If you need more help here just ask. Importing passwords can be tricky though. No need to create users again. Just use PW inbuilt users (which, behind the scenes, are actually pages themselves! ; Don't let this confuse you. Think of pages as data storage containers [of course the data is in the fields themselves]) Courses One thing you need to clarify is how you want the site to function. I guess here you are really talking about categorising your content. Have you seen this tutorial I did about categorising content? If not, have a look and see where your use case fits in. Then, you can come back and structure your site in the most suitable fashion. We appreciate all the help we can get. Yes, tutorials are not that many but as you have probably noticed, we are working on it. My advice for your task at hand. Divide up the task and tackle one issue at a time (but of course, you need to have a clear picture of where you are going first, otherwise you might be going round in circles). Try things and ask specific questions (once you've searched and not found an answer is preferable ) but feel free to ask please.

You can always simulate the production site domain situation, so you won't have to do fixes (Rewrite Base, etc.) for localhost/ProcessWire/project when you live domain is just yourwebsite.com. You can take that even further and simulate server capabilities, for example Apache module versions and so on with Vagrant

Thanks for posting Faisal. I've done it like this: Create a checkbox called "rtl" and add it to the language template. elect which languages are rtl and check the checkbox and save them. Using code like $user->language->rtl keeps your logic clean, especially when having multiple rtl languages. In my _init.php I create a boolean variable called $rtl which checks if the $user->language->rtl so I have access to it in my template files. Following this structure saves you time when adding a new rtl language since you don't have to alter any code and/or have to deploy to your live website.

This tiny module is intended as a helper for Ryan's Hanna Code module by providing a way to select existing Hanna Code tags within the editor. This is something I felt our clients needed in order to start properly using Hanna Code tags. See attached screenshot for details -- there's really not that much to it at the moment. Each editor requires it's own plugin and currently I've only cooked one up for CKEditor, where the plugin presents itself as a context menu item (visible on right click). I'm planning to expand the feature set of that one slightly and then probably convert the CKEditor plugin to TinyMCE, but that's just about it. Ideas are welcome, though. Some of the code is pretty much duplicated from Ryan's original module. I hope he doesn't mind -- though for the record I've also tried to make it very clear in the source what part that is and where it's from.. GitHub: https://github.com/teppokoivula/HannaCodeHelper Modules directory: http://modules.processwire.com/modules/hanna-code-helper/

I think the reason why most of us want to see PW as business CMS is, that we want to do the cool projects with a tool that is more flexible, capable, reliable as for example Typo 3 is. Right? So, why is Typo 3 regarded as "enterprise cms" (at least in Germany) and PW is not (yet)? Imho simply because it was the first tool on the market that gave agencies (the cool ones, with big clients) a tool to work on elaborated websites. It was simply one of the first movers - and I personally believe, this is still its strongest asset. Very much more important than platinum support and all this kind of stuff. Decision makers buy it, because they know it - please correct me if I'm wrong. So, what is the learning from this for marketing PW? I think it could be helpful to: Highlight solutions over features. Enterprise level sites already exist (ok, more or less) and we should look for a way to promote this solutions more Improve awareness in major agencies. They are the key multipliers for "selling" PW for big projects. Stay patient. PW has gained much attention in just some one or two years. It is on a good route. Very soon more and more bigger agencies will discover, what it can to for them ... Finally, I can only second that.

You didn't even scratch on the surface yet... It's possible, just if it makes sense or there's isn't any drawbacks is a different question. If you want you can overwrite and change almost everything. And if not, there's maybe just a hook needed to add to core. There's many different approaches as always in PW. Fo example you could set all templates to have "main" as alternative template foreach($this->templates as $tpl){ if($tpl->name != "admin") $tpl->altFilename = "main"; } Depends really where you put this code. Most sense would make inside a autoload module like the HelloWorld.module. But then you have ALL templates always use main.php. You can't change it unless you add more logic to this script. After all I've come away from the "delegate" approach I've posted here, and use the one Ryan proposed. Including the main.php at the end of a template file makes things easier when you want to add stuff per template. Some more flexibility after all.

Hi Sparrow, First go here: https://processwire.com/talk/topic/4917-the-admin-cannot-be-reached-in-new-installation/#entry47998 Running on a Mac ? Martijn did a great post here about this: https://processwire.com/talk/topic/5797-setup-a-processwire-environment-on-a-fresh-macos-x-install/ If that did not help then continue here: Can you open other pages on your local website ? Have you links on them and do they at least work ? Used sub-dir under your root when installing PW ? There is a line in the .htaccess file that refers to "RewriteBase". Uncomment this line and type your dir into it. Check if your .htaccess is really working. Type some random chars into the .htaccess to see if a 500 (?) page comes up Try to revert back the .htaccess to its default with the changes in the VirtualHost only Check your default Apache configuration. Has it turned off "AllowOverride" setting for e.g. /var/www, ? Check your VirtualHost declaration in httpd-vhosts.conf: change names and paths in example to your local ones, <VirtualHost *:80> DocumentRoot "/Users/username/Test Site" ServerName testsite.loc <Directory "/Users/username/Test Site"> AllowOverride All </Directory> </VirtualHost> ================================= Let us know what you have found.

Greetings, Most of you know this but there are some who need to know how or what are the options available! and what ProcessWire can do to help making it easier. And before we start if your website is "LTR" Left to Right only then you don't need to read this, and if your website is "RTL" Right to Left only I will assume that you also don't need to continue reading! because you know what to do. If you don't here are the basics: As you always do in "RTL" you add to your main style file html, body { direction: rtl; } And you may want to change <html> to <html dir="rtl"> Depends if you need it or not, maybe for JS alerts or something. And the rest is up to you. OK let get started with multi directionality: If you are going do this or if you need this that's mean you have more than one language, let's say English/LTR and Arabic/RTL So go to PW admin area -> modules -> Core and install Languages Support, Languages Support - Fields and Languages Support - Page Names and add new language (name=arabic) From this point there is more than one way to get the job done, and here are some basic exsamples: lets say that you have English is default language and your main style name is main.css and with simple content example: body { background: #e4ebee url(images/bg.gif) repeat-x; } .something { width: 179px; height: 25px; float: left; text-align: left; } Create new style file to hold the Right to left code let's name it main-rtl.css and with simple above the content for RTL will be: body { direction: rtl; } .something { float: right; text-align: right; } Now in your original head.inc you have something like this: <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title><?php echo $page->get("headline|title"); ?></title> <meta name="description" content="<?php echo $page->summary; ?>" /> <meta name="generator" content="ProcessWire <?php echo $config->version; ?>" /> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/main.css" /> <!--[if IE]> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/ie.css" /> <![endif]--> <script type="text/javascript" src="<?php echo $config->urls->templates?>scripts/jquery-1.4.2.min.js"></script> <script type="text/javascript" src="<?php echo $config->urls->templates?>scripts/main.js"></script> <!-- This website is powered by ProcessWire CMF/CMS. ProcessWire is a free open source content management framework licensed under the GNU GPL. ProcessWire is Copyright 2012 by Ryan Cramer / Ryan Cramer Design, LLC. Learn more about ProcessWire at: http://processwire.com --> </head> What you need to do is after the main.css line add this: <?php if ($user->language->name === "arabic") { echo '<link rel="stylesheet" type="text/css" href="'.$config->urls->templates.'styles/main-rtl.css" />'; } ?> So the final code will be <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title><?php echo $page->get("headline|title"); ?></title> <meta name="description" content="<?php echo $page->summary; ?>" /> <meta name="generator" content="ProcessWire <?php echo $config->version; ?>" /> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/main.css" /> <?php if ($user->language->name === "arabic") { echo '<link rel="stylesheet" type="text/css" href="'.$config->urls->templates.'styles/main-rtl.css" />'; } ?> <!--[if IE]> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/ie.css" /> <![endif]--> <script type="text/javascript" src="<?php echo $config->urls->templates?>scripts/jquery-1.4.2.min.js"></script> <script type="text/javascript" src="<?php echo $config->urls->templates?>scripts/main.js"></script> <!-- This website is powered by ProcessWire CMF/CMS. ProcessWire is a free open source content management framework licensed under the GNU GPL. ProcessWire is Copyright 2012 by Ryan Cramer / Ryan Cramer Design, LLC. Learn more about ProcessWire at: http://processwire.com --> </head> Another way is using translations For example: <!DOCTYPE html> <html dir="<?php echo __("ltr"); ?>"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title><?php echo $page->get("headline|title"); ?></title> <meta name="description" content="<?php echo $page->summary; ?>" /> <meta name="generator" content="ProcessWire <?php echo $config->version; ?>" /> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/main.css" /> <style> body { direction: <?php echo __("ltr"); ?>; } </style> <!--[if IE]> <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/ie.css" /> <![endif]--> <script type="text/javascript" src="<?php echo $config->urls->templates?>scripts/jquery-1.4.2.min.js"></script> <script type="text/javascript" src="<?php echo $config->urls->templates?>scripts/main.js"></script> <!-- This website is powered by ProcessWire CMF/CMS. ProcessWire is a free open source content management framework licensed under the GNU GPL. ProcessWire is Copyright 2012 by Ryan Cramer / Ryan Cramer Design, LLC. Learn more about ProcessWire at: http://processwire.com --> </head> Now go to PW admin area -> Languages -> arabic -> Translate New File -> select your head.inc Translate ltr to be rtl And of course you can also do something like <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/main-<?php echo __("ltr"); ?>.css" /> But rename your main style name is main-ltr.css And so on.. Please know that it is always depends on how your design is made and what it's need! One small problem in PW2.4 with TinyMCE read about it here And One small problem in PW2.5 "dev" with CKEditor read about it here I hope this is useful to you.

Yes, that's nice If you are having a long list of "RTL" languages you will need more effective solution, so it's fair having one new field in database. I don't want to go advance because it's not just rtl for multi languages, some languages need special font-family, font-size and so on.... I am working in website at this time that have global field "custom_css" so evrey page can have additional css file for some special effects if needed so I don't have to load all css in a page that don't use it. This can also be used for multi languages if needed. Thank you for sharing your idea, and I hope others do so if they have any ideas with some code samples because there are people are not code writers who do not know some of the technical terms, but they can do will just from an example or a source code

Just for the record (I can see that other arguments have already kicked in), I'd like to point out that this would also require ProcessWire (and thus your Apache user) to be able to create and modify files within /site/templates/. This, in my humble opinion, is not a good idea; even with proper safeguards in place, web-writable executable files open all sorts of possibilities for abuse. You don't want to go that route unless you absolutely need to -- and I can't imagine any situation where I'd actually want to do that.

If "/processwire" is the root of where you extracted the following zip, then YES. It has an index.php file http://processwire.com/download/ Upon initial extraction, you'll have this structure: FOLDER site-default wire FILE .gitignore COPYRIGHT.txt htaccess.txt index.php install.php LICENSE.txt README.md The folder 'site-default' automagically gets renamed to 'site' after installation. After installation, you'll find your WORKING FILES here: ./site/templates/... By WORKING FILES, I mean these are the ones you'll be working with 99.99% of the time. During the installation, whatever name you give your "Admin Login URL" is how you would access your site back-end. I do the same. Live site = website.com Test site = website.dev Makes it SO much easier.

Two days ago, an idea about a new admin theme came to my mind. Some hours later, I've crafted a first concept in Adobe Fireworks.... The look and feel of the admin is important Two months ago, I've introduced some teachers into ProcessWire. They were none-technically people. At the end, they knew how to use the admin panel to create content or update a gallery on their new page. However at some points, they got confused with parts of the admin theme -beside the problems with our concept on how to use fields and templates for creating content. I think one factor why Wordpress became so large, was the great Adminpanel. It works well and easy (as long as you have a blog and not a twenty-plugins-for-text-pages-site). Editing content on a daily basis is the main task of my customer. I've to take this aspect serious. Problems I wanted to solve Have the page tree always visible. If I do not click the right link, it will be closed after I've finished editing my site More visuals like icons. Simplify some workflows. Creating 3 or 4 pages can result in multiple unnecessary clicks. More focus on important links like the tabs. Guide my customer through some action. Help them to repeat simple tasks. The concept First: Nothing is perfect and its not possible to find one single solution for everything. This was just done in a couple of hours and it's only the first iteration. Quick action button Next to the ProcessWire logo is the quick "Quick Actions" button. It should be possible, to configure it like: "Create a new Page with Template X with page Y as a parent". Use it for skyscrapers, news or galleries. (Yes i know, the arrow is pointing upwards. This is wrong) Two column layout The page tree is always visible (as long as we are in the pages view). It can be navigated as the normal page-tree. If you click "edit" it will become highlighted. Every action that would take you to a new page, would be displayed in the other half of the monitor. Speaking of a "half monitor" - I think that most people use a screen resolution of atleast 1300px. The sidebar should take up to 1/3 of this. On smaller screens, it will become hidden by default or we just simply step back to single pages for each view. If the content is to long, the sidebar becomes scrollable. Page tree I like the Template Decorator made by mindplay.dk. It fits the concept well with black outline icons for every type of template. The same icons could be used in the Quick action menu. I'm note sure what to do with the "move" action. To Do list Think more about the behavior of the elements. Design the modules view. Rework the search and the top menu. Options to "brand" the panel for agencies while keeping the ProcessWire logos. What happens if we are on mobile (small screen) devices? Listen to your feedback.

In tutorials section of the site we are encouraged to request tutorials. This topic is such a request. ProcessWire is advertised to be great in not only building unique frontend features, but also custom backends. I would be very much interested in tutorial on building a custom backend for a site. I put some questions that could be covered in such a tutorial in a list below: How to create custom backend pages How to change the default starting page for admin users How to serve different backends to different users depending on roles How to style the page tree (I have seen it styled in some Soma's video tutorials, so it is a request for a best practice or an advice) Anything else you think appropriate here))) If someone could generously provide a screencast of a custom backend workflow it would be great tutorial in itself.

After months of silence on the forum I've decided to speak out and introduce a brand new admin theme for ProcessWire 2.4.x I've made the theme initially for our internal business project and I've decided to share it with you all The theme itself is designed only for ProcessWire 2.4.x and up because it's wrapped as a module (new theming design approach introduced in ProcessWire 2.4) and it also has it's own options you can configure. It has all the bells and whistles as Default Admin Theme of PW 2.4 as well as some of my own You can download it from here: https://github.com/nvidoni/AdminThemeModesta and please let me know of any mistakes you find during your workflow... Changelog: v1.0.1 Added unpublished pages status icon next to username (fires modal window with unpublished pages list that you can edit) Improved PageList (children are more indented with arrows before them, hidden pages have more lighter color and icons have more darker color - by suggestion from Martijn Geerts) Other CSS improvements UPDATE: You can find version compatible with Processwire 2.4.4 and up on dev branch: https://github.com/nvidoni/AdminThemeModesta/tree/dev and also let me know about any mistakes that should be fixed. Dev version isn't updated to v1.0.1 yet because of strange problem with theme not switching right (doesn't activate) - it started to happen from 2.4.5 dev version of PW...) and it seems it happens only in Windows environments...), hopefully we'll fix this soon. To sum it up and let the images do the talking, here we go:

Hello, I always put some kind of prefix to fields like some user fields usrFirstName usrLastName but I would like to name them more like firstName lastName so when using a page like this $user = $pages->get('/users/clsource'); I can do this $user->firstName and not this (more ugly way) $user->usrFirstName Yes I know this is already possible, but when you handle a lot of fields, some fields collide with the same name but with different output and format. Is there a way to make a namespace or something, so using prefixes is no longer necessary? In PW you can organize fields inside categories, could be that I can have multiple fields with the same name, but whitin different categories. and see them sorted inside the template field selector by categories? Thanks!.

[Maybe a somewhat off-topic reply] I would not call PW an Enterprise or Business CMS in this stage. I would not even call it an allround or general CMS at this stage. In my opinion it's purely a developers' CMS. I understand enough about the PW concept to understand why developers are psyched about it. It's a very promising concept indeed. I see it as a concept system, and not a real-world CMS yet. I know, I know, you can create real-world sites with it, but you have to be a developer. A real one, who can code, and can think very abstract. Someone who actually likes things to be abstract. Fired by my initial enthousiasm some time ago, when I discovered PW, I spent quite time trying to get my head around this system. I failed. I read all relevant forum posts, and support info. But still I failed. I was able to create a simple semi-static site after a while. But I would not need PW for that. I can use Wordpress or WebsiteBaker or Joomla or whatever. I got very frustrated trying to build a basic blog-site, even with the help of the semi-ready blog module I got frustrated about the complexity of it all. I also got frustrated about everything being called a page. I know the reasoning behind it, yet I think it's a user unfriendly concept that is already enough to stop PW in its tracks when it comes to widespread use. There are many usability shortcomings in PW that make it unsuitable for general use, let alone Enterprise use. It's an infant system, when it comes to allround features, plugins, and usability.It will not appeal to many people except coders and devs. That's not enough to make more than a dent in the current CMS landscape. I am not a developer. I am an experienced website builder, and I think PW is way too abstract and too cumbersome for people like me. My clients would even fail to understand 90% of the low level PW stuff I know now. I simply could not offer this system to clients, even if I would understand it completely myself. I keep an eye on PW, and I hope many of it's usability issues will be fixed in the coming years. Right now I use Joomla/K2 if I need a CMS with easy custom fields option. For a semi-static site I use WebsiteBaker, and for a typical straightforward blog either Joomla or (heaven forbid) Wordpress. PW an Enterprise CMS? Only if all people who work with it are coders. And those chances are very low. Sorry for the negativism, I'm still excited about PW, but it's not a suitable general or business CMS in the real world right now. I hope it will be someday.

Thanks anyway. Got there like this in the end.. think it works:) <table class="table table-striped"> <thead> <tr> <th>Visit Date</th> <th>User Roles</th> <th>User Name</th> <th>Page ID </th> <th>DMC Page</th> <th>Country</th> </tr> </thead> <tbody> <?php $durole = "du"; // this is the role that I want highlighted in the rows $agentrole = "agent"; foreach($page->visit_log as $visit_log_item) { $username = $users->get($visit_log_item->user_id) ; $pagename = $pages->get($visit_log_item->page_id); if ($username->hasRole($durole)) { $row = "info"; } elseif ($username->hasRole($agentrole)) { $row = "danger" ;} // if the user has the durole which is called du the the table row should be success else info echo "<tr class='$row'>"; echo "<td>$visit_log_item->date</td>"; echo "<td>{$username->roles}</td>"; echo "<td>{$username->name}</td>"; echo "<td>$visit_log_item->page_id</td>"; echo "<td>{$pagename->name}</td>"; echo "<td>{$pagename->DMC_country_represented->name}</td>"; echo "</tr>"; $row = "active"; } ?> </tbody> </table>

Not sure but might this work?: EDIT (still looking, first thought was wrong :0 )

There's an issue on the latest dev where if you switch the built-in Images field to user CropImage, it says it's not configured correctly until you set the new minimum image size parameters. As a workaround I set them to zero, but the interface suggests you can leave them blank. Not sure if this is an issue with this module or the dev branch?

I've been running an early version of this module for a while, and just haven't kept up with development — but WOW! Nice work all, this is really great! Just wanted to mention that there are still issues with the module if used on the user profile page. Running the latest PW dev and the latest version of Thumbnails.

SiNNuT, glad you are liking this tool. I just committed an update that should fix this (I had an array_merge() with the wrong order of arguments). Actually, I was getting required as always empty (even if it was required) so the behavior I saw was a little different than what you mentioned. Can you confirm it fixes the issue?

mon dieu! - wherever i click it looks pro - - -

Too bad no Cyrillic letters .

Just take a look in the troubleshooting guide: http://processwire.com/docs/tutorials/troubleshooting-guide/ http://processwire.com/docs/tutorials/troubleshooting-guide/page3

Adrian - you may want to remove all the downloads of versions from the previous page and instead direct users to the modules page. I was about to download the first one without reading any further

It is great! I want to propose an enhancement though. Do not know if it could be easily done, because I did not try Hanna codes yet (but definately will do in the future). Those tags look really scary for the user. It would be great to be able to name those codes, so they will show without the square brackets in the list. But this is probably unwise to do in this modulу, but rather in the Hanna code module itself. Anyway, this is surely usefull as it is. Thanks, Teppo!

Just pinning this CKEditor Addon here that fits for some of the mentioned usecases: http://ckeditor.com/addon/strinsert https://github.com/57u/custom-dropdown-ckeditor4/blob/master/README.md you could define your own list of strings for insert in CKE - so you could setup the predefined HannaCodes for the customer to just only select the right one.... regards mr-fan

Praise the mutant saviour

I have added additional links

Mac installs: https://processwire.com/talk/topic/5797-setup-a-processwire-environment-on-a-fresh-macos-x-install/ https://processwire.com/talk/topic/4917-the-admin-cannot-be-reached-in-new-installation/ https://processwire.com/talk/topic/98-installing-on-mac-localhost-going-all-sorts-of-wrong/ https://processwire.com/talk/topic/6803-help-needed-for-local-setup-on-a-mac/

A bit OT. I always set up virtual hosts for every project or test install i do. This way the default .htaccess has never failed me and it saves headaches when deploying to live domains. Installing into (sub)folders of localhost is not optimal to my taste.

Are you developing on Windows? What LAMP server are you using? I do all my development locally. I have at least five separate ProcessWire installations on my Windows 7 desktop.

Don't go renaming the wire folder. As cstevensjr says, the admin URL is not at all related to the name of that folder. The admin page in PW is just a page in the system and the URL is defined by that entry in the database that I pointed you to which is controlled by some .htaccess mod_rewrite rules. That is now a very different error to what you first received. Take a look here for help with this: http://processwire.com/docs/tutorials/troubleshooting-guide/page3

Yeah, that is a great tutorial. I can't make my brain work with Ryan's delayed output method, and he hasn't finished the "More Strategies" section yet. I have one site where I used Apeisa's method (found on page 2 of this thread), but it seems like overkill for what I typically need to accomplish. Soma's way seems to be a good balance between the good old "header/footer" method and Apeisa's way.

You're right of course I was forgetting the scenario we were talking about here. I guess I just don't like having lots of template specific conditions in the main.php file which is why I use that method along with Ryan's approach. Too many options with PW

I think you are mixing things up. The PW directories are /site and /wire. The /processwire url in the setup script is for admin access purposes. They are not the same thing.

For those reading this great thread, if you haven't seen it, Ryan has neatly summarised various approaches in the Tutorials section How to structure your template files: http://processwire.com/docs/tutorials/how-to-structure-your-template-files/

I think it's because the non default languages aren't set active on the admin/shop/orders/ parent page.

Ryan, I've been playing around with the field export/import tool (dev branch, d.d. 11-8-2014 14:16:16 (UTC+0000). I've only used it for exporting and importing new fields from one install to another, on a set of about 25 fields. Types used: float, text, textarea, integer and datetime. It is already a huge time-saver! Recreating more than a couple fields fields manually is really time consuming and error-prone, and i also don't want to be doing this on the database level. So as far as i'm concerned a major improvement in (development) workflow. One thing i noticed: The created JSON always seems to be putting "required": 1 , even when the exported field is not required.

http://processwire.com/download/ ProcessWire 2.4 at GitHub View, clone, fork or download the latest ProcessWire version and/or source code at GitHub. See also the dev branch which always contains the latest updates not yet migrated to the stable version.

But I suppose we'll keep you and your profile around for giggles

I couldn't agree more with Apeisa here. It comes down to a choice: if you want ProcessWire to become popular outside of that group of traditional developer types then you have to appeal to those with 30 minutes to spare and low technical experience. If on the other hand people here are happy to let ProcessWire grow slowly, organically, continually appealing to more technical mindsets then it is doing a great job already and should simply continue on that path. There is nothing wrong with either route and it all comes down to the expectations of the community here. One word of warning about expectations though. I watched the Drupal community grow from version 5, 6, 7 onwards and the bitterness that resulted within the community when WordPress started to dominate the market (around Drupal 6) was palpable. The Drupal community believed that they had a far better system with more flexibility and inherent security, but they were very scathing of the fact that WordPress (sometimes described as 'HerdPress' within the Drupal community) became so popular and Drupal didn't. My point (eventually) is that until very recently (with the advent of Drupal 8) the Drupal community missed the reason as to WHY WordPress was dominating so. They thought it was marketing, but really, it wasn't. The simple reason was that Drupal was engineered for developers and encouraged very little involvement from the design community. I couldn't count the amount of times designers would attempt to engage in the forums and request a simpler theming system only to be sounded out by the developers there - sometimes very aggressively. WordPress on the other hand encouraged the design community and became easy enough for designers with traditional design mindsets to pick up. WordPress actively engaged that audience and a theming system was built that partially catered towards them. Combine the WordPress theming system and an admin interface which is one of the nicer ones to look at and use and you have a package that appeals very strongly to a lesser technical mindset. The whole concept of growth and whether to cater towards the less technical mindset then comes down to choice and expectations. If ProcessWire continues down its current path, it will build a very strong following of developers (and some slightly more technically minded designers). However, it will never grow beyond a certain scale and will always be less popular than many other choices already out there. Again, that's okay if the intention is there to focus on that audience to the exclusion of others. However, the market out there for the designer / CMS administrator type of profile is vast and much larger than that of a development centric audience. It's a simple truth and one which would need to be catered for with better turnkey solutions if ProcessWire wanted to better engage the non technical mindset. The community would also need to welcome them (which I don't think will be a problem from my experience). If ProcessWire wanted to engage and grow its audience to compete with the 'bigger' and more popular systems it's already (in my opinion) in a much better place than Drupal to capture a less technical market. It's API is streets ahead in terms of simplicity for frontend development and it's community is less hardcore. However, some things need to be more readily available to cater towards the designer type who isn't a frontend specialist. A theming system is central to that need (again, in my opinion). The traditional designer mentality is one that is only very slowly moving in a more technical direction (in a typical sense). The Photoshop GUI and knowledge of CSS being as technical as it gets for that type of user. Therefore, having pre-built examples and tools that are easy for a designer to iterate on are essential. Having a packageable theming system would not only help others coming from other systems with ProcessWire, but would enable designers to have less complex starting point to suite different needs. I work with a number of designers coming out of university who still have poor technical skills, they barely know Photoshop to the level that is needed. ProcessWire is unfortunately too great a step for them. Whereas WordPress is easy for them to pick up. In WP they can install a theming base and then iterate from that quickly, they also have plenty of how-to guides catering towards their mindset. Most of the time, they will use a theme base as a starting point for their PHP and XHTML markup and CSS, completely altering the CSS and some of the XHTML, but barely touching the PHP 'voodoo'. However, after a few months they start to become more comfortable with PHP and will then iterate on that layer as well. Then, a frontend developer starts to emerge! They are now very comfortable with WordPress because they have had success with it. Nico's solution I think is perfect for the ProcessWire community. Simple, elegant, potentially very powerful and more importantly optional. When this reaches maturity, you could combine this with a series of tutorials and profiles engineered towards a designer mindset and you have a very simple way to better engage that type of audience and attract them to the ProcessWire project. As a by product of catering for that designer mindset, you then also have the potential turnkey solutions that an even larger audience profile thirst for...

Funny thing, I usually associate “Enterprise CMS” with something expensive and closed-source that consists of a weird combination of Java, Perl, XSLT and other outdated technologies which should not be used to build modern web sites or apps any longer. As for “Business CMS”, that's a term that I (just my 2 cents) find rather confusing. A lot of us make a living building more or less complex web sites and apps using ProcessWire. Judging from the Showcase forum, a lot of those web sites are for businesses. Besides, what would be a “non-business” CMS? Something for hobbyists? (Did I just hear someone say “Joomla”? ) In all seriousness, I don't think it's necessary to market PW for Enterprise/Business use. It (currently) is a CMS for developers. Devlopers who make/made an educated, informed decision to use this particular CMS. Developers who will (individually) market this wonderful CMS to their clients. I really liked the way Marc put it in the original thread – focus on building a smart, yet simple CMS that developers like. The rest will follow organically. No need to hurry it.

I want to like this post multiple times but the forum software doesn't allow me to do that. So: Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Like. Honestly: It's comparing apples to oranges. PW is strong. It is the most intuitive, the best designed (in terms of API and UI) CMS out there with the smallest footprint possible. I recently used again the multi language support. I mean, look at the API. Look at the solution for a problem each CMS has. It is just beautiful. You have several ways to solve that problem (as always with PW). But it is there, written in the core, well documented on one(!) API page, because it just works intuitively, it is just simple. Every addition to the core is an addition which solves general problems and the way Ryan solves them is just genius. There is no addition you have to scratch your head when reading the new API. You always think: "wow, clever". And this is the way to go with the core. Make it simple, make it smart, make it beautiful! Regarding themes, profiles and such: It is already possible. It is out there. Provide a custom profile for a real estate agent: Give him a set of modules, fields and templates to handle his offers. This is no problem! This is even easier and more flexible than it ever will be in WordPress, because it goes way beyond a custom theme and can be installed with one click. But: Nobody will care at the moment, because ProcessWire has no own category in theme/template websites, because ProcessWire has not the attention of other plug&play systems. And this is totally okay! Think of TYPO3, a widely spread system, mostly used in enterprise environments and even on small sites (dunno why), but the point is: Everyone (at least in Europe) knows it, it is one of the most used systems in the business sector (not on private children soccer club websites). But: this is the goal! Be the system developers use. Don't be the system every idiot wants to use. Concentrate on performance, flexibility and most of all: beauty of the API! The rest will follow.

Bienvenu au forum icietla There are probably many workarounds for that scenario. You could create a checkbox inputfield, and check the value in your head or init.php template. If that checkbox is checked, you could do a redirect to the other language. if($page->redirectLang == 1) { $user->language = "en"; $session->redirect($page->url); } (untested)

I brought this up a long time ago, in this thread - in a nutshell, the thing that I've been working on (on and off) is a generic model of a model ~ hence the term "meta-model", which I'm not even sure if that's the real or correct term, or whether that's even a common thing. Meta-models have lots of potential applications, but probably it's primary appeal is code-generation. There is of course no reason you can't consume a meta-model at run-time, which is what PW does. In PW, your meta-model is basically the Templates and Fields. The problem is, you make changes to the meta-model directly, which means you do not have a useful history of how the meta-model evolved. To use a practical example, in my generic meta-model, I have types like "class", "property" and "annotation" - just very generic constructs that are applicable to (or can be made useful in) just about any programming language. Let's say I have an object that represents a "property" in the model, for example - let's say that $property->name is currently "first_name". In my meta-model, the $name property is read-only - you can't change it directly. No values can be changed directly. Instead, if you want to change the name, you have to create and submit a command, so for example: $metamodel->add(new PropertyNameChange($property, 'last_name')); PropertyNameChange is a command object capable of actually changing the name of a property. To reiterate, there is no other way to change the name of a property in the meta-model. When that command-object is added to the meta-model, it is automatically executed, so the change actually gets applied - but the command-object itself also gets serialized and appended to the model's history. This enables me to repeat any change made to the meta-model, in sequence. This is very similar to how database schema migrations work - except you're not limited to migrating changes to the database schema, which really is an implementation artifact. You can now migrate changes to the entire model, and the entire history of the model becomes repeatable. Another important difference, is that the meta-model (and command history) gets written to flat files, rather than to the database. This enables me to make changes to a model, and check those changes into source-control, then repeat the commands on another system to continuously integrate the changes. Applying the same idea to ProcessWire, that would mean blocking Templates and Fields from direct modifications, writing serialized copies of Templates and Fields, and serialized command history of changes made to both, into flat files. This would be event-driven, so that you could hook into commands being added or executed... It has always been my philosophy that writing data and meta-data into the same back-end (e.g. database) isn't right... I think the problem with most CMS is that nobody bothers to make the distinction between data and meta-data - we tend to think, "oh, it's all just data", and then shove it all into the database. But meta-data is actually closer in nature to code, than it is to data - because it drives decision-making in the code. Things like "title" and "body" do not directly drive decisions, but things like "field type" and "template filename" directly drives decision-making, and therefore does not belong in databases, anymore than your source-code does. Some CMS take this misunderstanding to an extreme, and actually write PHP code into the database, iiiirk!...