Leaderboard

Hi all, My first post. I’m Kongondo. I am coming in from MODX hence “recognise” a few faces here. After many, many months of contemplation and searching for a MODX replacement, I came across ProcessWire for the second time. First time I heard about ProcessWire was maybe a year or so ago. Back then, I checked it out but quickly moved on since it seemed like a “one-man-project”. I was also thrown off by the simple interface; I judged a book by its cover and thought no way this CMS is powerful…so I moved on. My search for a CMS continued....About a month and a half ago, I came across this post by Mademyday so I checked out ProcessWire once again, this time digging deeper into its guts and boy was I impressed! For the last one month I have read every Forum post, bookmarked key threads, watched the videos, dug into the demo site, Googled, etc. and installed and played with ProcessWire locally. Honestly, I have been blown away! Finding a replacement for MODX was tough; but now, I have found it. Ryan, congratulations; this is an amazing framework you’ve created and thanks for releasing it as open source. I am a “tutorials-kinda-guy” so I am already working on ProcessWire lessons which I hope to post on my website soon. I know there’s the Wiki work going on but I think the more lessons we have out there the better for ProcessWire. Then again, I’m not a fan of Wiki markup . Cheers /k

I wish everyone some nice days and would thank this great community for all the efforts. For the non-krauts Guten Rutsch ins neue Jahr = have a Good Start in the New Year.

Welcome aboard, For your safety, please take a moment to listen to this important message about safety on board. In preparation for departure, fasten your seat belt by placing the metal fitting into the buckle. For your comfort and safety, adjust the strap so it fits low and tight around your hips. To release your seat belt just lift the face plate of the buckle. As you know, turbulence is sometimes unexpected so we advise you to take a look at Somas Cheatsheet, you will find a copy under your seat (http://processwire.com/api/cheatsheet/) On behalf of all of us, we wish you a very pleasant flight. Thank you, for choosing ProcessWire.

Hello kongondo & welcome to the PW forum. Whilst I agree that Ryan's produced an amazing product in ProcessWire I think it goes beyond just the software. Of the CMS devs I've been involved with Ryan's the one project lead who has been the most open, from first contact, to meaningful contributions towards the site, docs, forum and code. Some others have been open, most friendly, but none to the same degree. Consequently he's attracted a welcoming, talented & professional group of people to the project and I've learned a lot from being involved here.

¡Feliz Navidad y próspero año nuevo para todos! (Merry Christmas and a happy new year everyone!) I hope we all have a new year full of interesting web projects! With the help of ProcessWire, there's no doubt in my mind that that will be the case! Have fun!

Bom Natal malta!

Looks like Packt Publishing have another ebook offer on, valid until the 3rd January. All their e-books are US$5(£3) each but you have to buy a minimum of two for this to work.

Thanks Matthew, these API improvements are one of the most fun parts for me. Though I think the next step will be to get comprehensive unit test library specific to PW selectors, so that I can go in and add or tweak stuff, and be able to make sure I'm not breaking anything.

Sretan Božić i nova godina! (Merry Christmas and a happy new year!)

As I have said elsewhere on the social web "Wishing all a festive holiday season regardless of anyone's politics, faith, religion or culture."

!Feliz navidad¡

God jul och gott nytt år!

Hyvää joulua ja onnellista uutta vuotta kaikille!

Fijne kerstdagen!

Fijne feestdagen en een gelukkig nieuwjaar voor iedereen!

Ah the pixel coordinates were indeed not working correctly, the following code should fix that: if(strpos($this->cropping[0], '%') === false) $pointX = $gdWidth * ((int) $this->cropping[0] / $this->image['width']); else $pointX = $gdWidth * ((int) $this->cropping[0] / 100); if(strpos($this->cropping[1], '%') === false) $pointY = $gdHeight * ((int) $this->cropping[1] / $this->image['height']); else $pointY = $gdHeight * ((int) $this->cropping[1] / 100); Though if you want to specify a crop without resizing, it should be a different function in the Pageimage class or an extra option for the size function ("resize" => false or something?). I've created a GitHub repository for the FieldtypeFocusPoint module I'm developing. It's my first ProcessWire module so I hope I've done everything correctly. Maybe u guys can take a look at it? All suggestions are welcome https://github.com/u...FocusPointImage Usage: $page->image->sizeWithFocusPointCropping(704, 165);

Hi Ryan, Terrific! It's excellent the way you continue extending the powers of ProcessWire while still leaving the clean stucture in place and not making any assumptions about how the API must be used. Looking forward to 2.3! Thanks again, Matthew

Joss actually emailed me a similar question and I'll duplicate my reply here since it seems relevant: Performance as it relates to database is really not an issue that one needs to consider much (or at all) when it comes to creating their fields. Most field data in ProcessWire is loaded on-demand. It loads data selectively and only when it needs it. This enables it to be highly memory efficient with large quantities of pages in memory at once. When you have a $page, behind the scenes, none of the page data is actually loaded until you access it. For instance, if you access $page->body, then it goes and retrieves it at that moment (if it hasn't already retrieved it before). MySQL is extremely fast with simple primary key, non-joined selects, and we take advantage of that. What I'm trying to get across is that quantity of fields does not translate to an increase in joins or other factors that would slow the system down. Where ProcessWire does join data automatically is at page load time is when you check the "autojoin" box on a Field's "advanced" tab. Some fields you know will always be needed with every $page instance, and that's what autojoin is for. Typically, I make my "title" field autojoin, as it is already by default. I've hidden that autojoin option under the Advanced tab simply because most people never need to consider it. The original intentions behind autojoin have become less applicable than I originally thought [with regards to performance], so it's not something that comes up that often. ProcessWire also uses joins when it performs queries for $pages->find("selector"), and related DB-querying selector functions. It joins all the tables for fields that you query. So if you perform a find for "date>2012-12-19, body*=holidays" then it's going to join the field_date and field_body tables when a value matches. Though it doesn't do this for the purpose of loading the data, only for matching the data. Technically this type of query could be potentially faster if all those fields were in one table. But that doesn't translate to results that matter for us, and doesn't affect the way that you should use ProcessWire. The benefits of our one-table-per-field architecture far outweigh any drawbacks. I put a lot of time into finding the right architecture and balance here when coding ProcessWire 2. Incidentally, ProcessWire 1 did use the one-table approach (all the field data was stored with the page rather than in separate tables) and it was far less efficient with memory, and about the same in terms of performance. It's better to re-use something like "body" (when possible) rather than create "article_maintext" or other template-coupled variations like that. The reasons for that are for your own benefit. It is less to keep track of, and tends to foster better consistency. It also results in more reusable code and broadens the potential of where the data can be used. Take the example of an on-site search engine, like you see in the upper right corner of processwire.com. If we know that the main text field(s) of most templates has some consistency in their field names (like title and body), then we can write code that doesn't need to know whether something is an article, a press release or a product. We can find all pages that match "holidays" in the text just by doing this: $pages->find("title|body*=holidays"); But if created a separate textarea field for every template, then any code that queries those fields needs to know a lot more about them: $pages->find("title|article_maintext|pr_maintext|product_maintext*=holidays"); While that still works, it doesn't scale nearly as well. This also translates to the code you use to output the results. If you want to show a snippet of the matching text with the search results, you are going to have a lot more fields to consider than just "body". Now if each of your templates genuinely needs very different settings for each of their main text fields, then of course it's fine to create them as you need them. But in the real world, I think you draw more benefit by planning for reusability when possible. The benefits are for you (the developer), as it doesn't matter much to ProcessWire. Reuse fields where it's obvious that the name of the field makes sense in the context of multiple templates. If template "employee" needs a date_of_birth field and template "press_release" needs a date_publish field then just create one field called date and use it on both templates. On the other hand, if you need multiple date fields on the same template (like date_unpublish) then more specific field names start to make sense. In that case, I would usually use my date field for publish date, and create a separate date_unpublish field for my unpublished date field. Though some may prefer to actually have separate date_publish and date_unpublish fields because they are obviously related by name. Ultimately, use what works best for you, but always keep an eye out for obvious reusability potential with fields. I think that most people naturally arrive at the right balance for their needs after some experimentation. What is a best practice for one need might not necessarily be for another. So these are mostly general purpose guidelines and people should find what makes the most sense in their context. For the majority of cases, I think avoiding tightly coupled template and field names is a better strategy. TL;DR: It doesn't matter to ProcessWire what you do. Aim to reuse fields when you can and when it makes sense, for your benefit.

Hello Everyone, Sorry that I have not been on the forums much of late. As my development team moves to use ProcessWire as our main cms tool for clients. We have needed to make sure that ProcessWire works on nginx platform. We use both apache and nginx, we found as many already have that nginx is faster and easier to configure. It scales well and when you really need speed it is a great solution. Anyways with all that being said ProcessWire was surprisingly easy to configure for nginx and did not require adding or modifying any code. Using the same "try_files" directives used for Wordpress and Dupral I was able to run it under nginx, here is a sample config: upstream php { server unix:/tmp/php-cgi.socket; server 127.0.0.1:9000; } server { listen 80; server_name hostname; root /websites/path/to/processwire; index index.php; try_files $uri $uri/ /index.php?it=$uri&$args; location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi.conf; fastcgi_intercept_errors on; fastcgi_pass php; } } There are a few things that still need to be done like protecting the wire and certain directories like assets but so far everything looks to be working correctly. If ProcessWire has a test suite, I could run it against this server to see if everything is functioning properly. I think that advertising the fact that ProcessWire works under nginx would greatly help to attract more eyes to the project(not that it isn't doing great already) and to give options to hosting and scalability. If you would like help working on this for official support of the platform, perhaps with adding detection algorithms to the install or anything else that is needed, I would be glad to help. Anyways I hope someone finds this post useful.

I’ve been working on a simple admin theme. I originally just wanted to add a simple dashboard area on the home page to display some quick links to key actions and documentation for clients, but I ended up doing a whole theme. The main focus of the theme is for the client / editor role, so it’s not been optimised for the developer usage yet. There are a few enhancements which are aimed at clients (opening previews in a new window, showing tree actions on hover). I have also tried to optimise it for mobile layout. You can see a preview on this video It’s using the Bootstrap framework and Open Sans font. The main issues I currently have are a conflict with the Bootstrap framework scripts and the older version of Jquery that ships with the PW admin. If I upgrade to Jquery 1.8.2 a lot of PW admin functionality breaks (sorting, ask select, modals). If I stick with the currently shipped version of jQuery 1.6, the bootstrap scripts do not work (drop downs, message alerts, mobile navigation). The other big issue, is I made a few simple hacks to some core js files (/wire/modules/Process/ProcessPageList/ProcessPageList.js, and /wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.js) - this was mainly to insert extra css classes here and there or to show if the tree has children. Is there a better way to do this? Other issues I am thinking about Is there a way to modify the “add new page” workflow? So when the user adds a new page, I’d like to change the default “You are adding a page using the …” message. Maybe this could be an additionally template field called “instructions” or “”details” ? It could be a used as a kind of “templates documentation”, which could be used to document the project for other devs and designers and for the clients / editors. How can you modify the login screen without overriding this file (/wire/modules/Process/ProcessLogin/ProcessLogin.module)? Also not to sure if having two save buttons is good for usability - maybe I will just have one in the header and make it fixed as you scroll.

I was thinking of a way of creating custom admin pages without having to create a process module or having to use the $wire object. I came up with a process that is actually very simple (although I think it would be better to create a module for having this functionality). Here is how: (This will work with the default admin theme, but should also work with other themes) Go to your /site/templates-admin/default.php (if you don't have it, copy the /wire/templates-admin/ directory to /site/) and change this line <?php echo $content?> to this <?php if($page->template===$templates->admin){echo $content;}else{include($config->paths->templates.$page->template->name.".inc");}?> Then, go to the /site/templates/ folder and create a file named "custom.php" with this content <?php include($config->paths->adminTemplates."default.php"); Our setup is ready Now, to create a custom page in the admin: First, create the new page as child of /Admin/ and point to custom.php as the template file. To do this, when creating the template for the page, go to "ADVANCED" and write "custom" as the "Alternate Template Filename". Then, instead of creating a TEMPLATE.php file, as you normaly would, create a TEMPLATE.inc file. You can use all the API variables as you would in a normal template. Disclaimer: This is a proof of concept, and has still lot's of place for improvement. edit: changed from this if($page->process) to this if($page->template === $templates->admin)

I also started to see u when i did the logos. In diogos I see Photoshop Welements. I don't think the cloud is something we should incorporate into a or any of the logos of PW. Just to fit the current website... which will change in 2-3 years. The letters typing is ok, but doesn't make a logo I'd want to live with. I'm not sure anymore what is required or not and the way to go from here.

I'm not familiar enough with Laravel to be able to give a good example. But I'm guessing that if someone used a framework like Laravel with ProcessWire, they would make use of ProcessWire in a similar manner to how you would when using PW's API from a command line script or outside PHP file. You'd use PW for data and the framework for routing. That's just a guess though. Originally, the framework was just called ProcessWire and the CMS was called "ProcessWire CMS". But I've never given it much thought into formalizing the terminology, but like where you are going with it.

Happy Holidays awesome people! 2013 is going to be an awesome (PW) year. Wishing you all the best and thanks for contributing to a fantastic 2012!

Hi Everyone, Follow-up question: what's a good way to refer to the ProcessWire framework? Of course, the whole system is called ProcessWire. Just wondering if, for clarity's sake, we might refer to the framework (for example) as the "Wire Framework," or something like that. This might seem like a technicality, but my thinking is that it sends a message that there is a framework underlying the system. As ProcessWire gets discussed and blogged about more in the future, this distinction could help convey a degree of meaning to developers and designers who recognize such things. What's the "official" name? Thanks, Matthew

Greetings Everyone, Picking slideshow scripts can be time-consuming. So many great ones, but I always look for the ones that have the simplest markup for dynamic content. As interrobang suggests, Flexslider is excellent. I use it in a lot of sites. Another excellent one is BxSlider, which also allows a great variety of content: http://bxslider.com/ In my recent sites, I have been using both Flexslider and BxSlider Thanks, Matthew

Thanks

Nice job Soma. I think you've done about as good as can be done with the type we're using. The truth is that we need a full rebranding pretty soon. The current branding was just quickly cobbled together by me a few years ago with little time or thought. And making logos has never been a specialty of mine. As the project has grown a lot since that time, we're nearing the point where we need a better presence with our logo... one that solves all the different scenarios at the beginning. Regarding typefaces, I love Avenir but have come to kind of dislike the Mahalia face. Though when it comes to rebranding the logo, we don't necessarily need to stick with any past typefaces.

Per @nik's request (from awhile ago), I've expanded support for the parent field selectors that you can use with $pages->find() and related functions. You can now pass those functions selectors like this: parent.name=about parent.name=about|contact parent.title*=Something parent.body*=Something|Something Else parent.title|parent.body*=Something|Something Else parent.template=basic-page parent.template|template=basic-page|fancy-page // and I think this is the one that @nik requested: parent.title|title*=Something Pretty much any combination of stuff can be used with the parent selector. Previously, you could only use id or path. As an added bonus, you can now also perform partial matches on a page name: name%=something name^=some name$=thing parent.name%=something parent.name|name%=something parent.name|parent.title|title%=something|something else These new features are available via the latest commit to the dev branch (upcoming 2.3).

Yeah I've seen the Thumbnails module and I think it is great when u need to have full control over the crops. The module I'm developing works a little bit different: When a user uploads an image, they can (optionally) select the most important part of the image. They only need to do it once per image, and after that, all generated crops will make sure the selected part is visible in the crop. This saves time, because the user doesn't need to define (for example) 4 different crops per uploaded image. They just select the most important part of the image. And when you (as developer) need a new crop somewhere on the website, you wouldn't need to define a new crop for all existing images because it can be auto-generated according to the most important part. I hope this clarify's the difference.

Hi Martijn I have a very mixed opinion about any Wysiwyg editors - in an idea world I would probably have none, but I am aware that there needs to be some freedom too, and editors supply that. In bootstrap there are some very specific things that are not available unless you use styles. the "lead" style is one and a btn style is another (with what ever variations you want) Generally, the only one I bring out is the Lead style. The other styles I am talking about above are just odd layout things like H1-h6, paragraph line spacing and so on. These can be important, not because the user expects it to be identical, but because they should not be mislead as to the quantity of text - if on the front of the site you have a very open typography style, but in the back end it is very tight, it can be even more misleading. Having got that about right, when I use rich text editors, I often only use a couple of buttons - Bold and Italic, perhaps, or just one or two headings and a style. Basically, it is very, very specific to the use so that the user can see exactly what is expected purely by the lack of buttons around! Joss

ProcessWire is a content management framework, which is still a "framework", but more focused on a particular thing. Whereas the framework scope of CakePHP, Laraval, CodeIgniter, etc., is more broad and cover more territory. ProcessWire isn't meant as a replacement for one of those frameworks, but I think there are probably many instances where its focus might make it preferable. And an equal number of instances where the opposite is true as well. There's also something to be said for bringing the two together in some instances. Another big area of difference is that traditional frameworks enforce a particular approach to build on top of, whereas ProcessWire aims to be a lot more transparent, like jQuery. Frameworks set you up with a place to put your models, views and controllers, whereas ProcessWire puts in you in a plain PHP file (template file) that is given a location context ($page) and lets you take over from there. We think MVC is a good approach to take with ProcessWire template files, but don't enforce anything, as it's up to the developer. For better or worse, the possibilities are wide open in the same way they are with a PHP file on its own… though with a full CMF API at your disposal.

@k07n: Yes. If you set your permissions correctly on the webserver, apply the HTTP_MOD_REWRITE parameter and copy htaccess.txt to .htaccess then the only warning you receive from the installer is that it can't determine the server software version but it may be possible to continue (which it is!). I should also add that I didn't include: fastcgi_intercept_errors on; in my server configuration block. I have this in my NGiNX http block as a global switch. @netcarver: Thank you for the kind words. I may not post frequently but I try to make what I write useful to others. Regards, Neil Darlow

Greetings, I think re-using fields makes most sense, as long as the fields are really equivalent from one template to the next (as apeisa says). With contexts, you can re-use fields and still have them be unique for each template! Thank you for this, ProcessWire! One advantage I am seeing with re-using fields is that I can regularly create "inc" snippets that can be inserted into different templates that have identical sections (same set of fields). For example, in my current project for an arts organization, they have "events" that fall into several categories. I have separate templates that reference the same core "event" submissions, and using a $pages reference, each of the templates filters the results according to what someone checked off on a check-box (event category), but many other parts are identical across the templates. Just an example. Thanks, Matthew

Install NetTuts Fetch plugin. Use super+shift+p and find "Package Control: Install Package" enter and search for "Fetch", select and hit enter to install it. Tutorial here: http://net.tutsplus....-nettuts-fetch/ Use http://gist.github.com to post snippets and load them in when needed. Very handy. I often use the module template I created here: https://gist.github.com/2732707 Just enter it as for example "PW Module Template" to the config of the Fetch package, open command console super+shift+p and enter "fetch", you'll find 3 commands, select "Fetch: file" and select the entry from the list hit enter and it loads the code into the caret position. Start coding your module.