Leaderboard

Are there any behind-the-scenes reasons that whitespace is not allowed in passwords, or is it a policy choice? I've found that people can remember phrases that mean something to them well so they make longer, more secure passwords/passphrases.

My experience is that once you get advanced, it can happen that you discover all the new bugs a dev brings. So not always recommended to run latest dev with a project you go live very soon. But sometimes you have to, to get a bugfix from a earlier dev version. Just my experience. Edit: To be fair. There can be bugs in both versions. But if you using dev I recommend you follow the commits, and see if an update is of benefit or not. I also sometimes wait 1-2weeks before updating, when there used to be bugs that were introduced in a previous commit.

http://stackoverflow.com/questions/9416508/php-untar-gz-without-exec

I think the message behind the new wording is that the you should stick with the stable version for existing sites because in some cases behaviors may have changed with the dev version and there might potentially be issues with 3rd party modules. The reason it is ok to use dev for new sites is that you are checking that everything is working as you are developing the site so you know that everything is working as expected. Personally I use dev on all my sites, but wait a little while to upgrade when Ryan has noted that there are some major changes - also I test these new changes for a bit on my dev sites so I understand the changes and help to debug any issues that may have arisen. Out of interest, check out the results of the poll on what versions people are using where: https://processwire.com/talk/topic/8946-dev-or-stable-branch/

The commits to the dev branch are always very solid and stable. I've used the dev branch for several production sites in the past, but fully realizing I do this at my own peril. I've never experienced an issue that caused me to revert to the master branch. However, I do try to stick with the current master for most production sites. Upgrading is super simple. As of 2.5.3 (the current master) you can upgrade/downgrade/DB backup from within the admin.

I think you can't as there's no fieldtype using it. I think Ryan did it mostly to give module developers the chance to reuse the code. But there's a 3rd party module that does allow for icon selection: https://processwire.com/talk/topic/8960-fieldtypefonticonpicker/

One more you can also get a field and get its parent InputfieldWrapper: $lastname = $modules->InputfieldText; $lastname->attr("name","lastname"); $lastname->label = "Lastname"; $firstnamefield = $form->get("firstname"); $fieldset = $firstnamefield->parent; $fieldset->insertAfter($lastname, $firstnamefield);

EDIT: This project has been put on ice - I don't work with ProcessWire in my day job anymore, so this project is looking for a new maintainer. Knowing that, you can decide whether it's worthwhile reading through 7 pages of posts EDIT: The source code has been dumped on GitHub - feel free to fork and have at it. There's one thing about ProcessWire that pains me, and I've brought this up before - it's the same problem I have with e.g. Drupal... Because the meta-data (Configuration, Fields and Templates) is stored inside the database, once you have a live site and a development site, moving changes from the development site to the live site is, well, not really possible. Repeating all the changes by hand on the live site is simply not an option I'm willing to consider. Telling the client to back off the site and give me a day or two to make the changes, and then moving the whole database after making and testing the changes on a development site, is really a pretty poor solution, too. I had heard some talk about a module in development, which would make it possible to import/export Fields and Templates? It sounds like that would mostly solve the problem. Ideally though, I'd really like a solution that records changes to Fields and Templates, and allows me to continuously integrate changes from one server to another. So I started hacking out a module, but I'm not sure if it's going to work at all, if it's even a good idea, or if it's worth the effort. I'm looking for feedback on the idea as such, more than the code I wrote, which isn't real pretty right now. Anyway, have a look: https://gist.github.com/b7269bb7bd814ecf54fb If you install this, create a "data" folder under the module's folder - migration files will be written there. Basic overview of the idea and code: The module hooks into Fields::load() and takes a "snapshot" of the current Field properties and settings on start-up. It also hooks into ProcessField::fieldSave() and when a field is saved, it compares it's properties and settings to the snapshot it took at startup - if changes were made, it writes the previous name and updated properties into a file. The same thing is not implemented for Templates yet, but would be. The migration-files are named like "YYYY-mm-dd-HH-mm-ss.json", so that they can be sorted and applied in order. Each file contains a JSON representation of a method-call - currently only updateField() which would repeat a previous set of changes and apply them to another installation of a site. (not implemented) So basically, the module would record changes to Fields and Templates, and would be able to repeat them. How those files get from one system to another is less of a concern - would be cool if servers could exchange migrations semi-automatically, using some kind of private key system, but initially, simply copying the files by hand would suffice. I'm more concerned about the whole idea of capturing changes and repeating them this way. Any thoughts? Is this approach wrong for some reason? Would this even work?

Here's my very first and not polished version of ru-RU translation. So, now you can enjoy all this cyrillic madness Ryan, I have a question. Is it possible to store cyrillic symbols without this transformstion to Unicode (?), so the json files are editable in any editor? It's not too much needed though. Update: I've just created a GitHub repo ProcessWire Russian Language Pack ru-RU where you can find the latest Russian language pack for PW's backend. Also attached a new version of the pack, but in future I won't be updating it here, so please download it from GitHub. slkwrm-ProcessWire-Russian-Language-Pack-ru-RU.zip

Hi to all, As I've mentioned earlier to Ryan, ProcessWire runs fine on Windows 7/2008 Server setup with IIS 7.5 WebServer with IIS Mod-Rewrite from Micronovae that can read .htaccess file. The problem is that this IIS filter is free for development use on localhost without limitations but it's not free for production use on live server (it costs $150 per server license). I've found another solution that works flawlessly and it's absolutely free. Download URL Rewrite Module 2.0 for IIS from http://www.iis.net/download/urlrewrite and install it Define new web site under "sites" in IIS Manager and point it to directory where you've unzipped ProcessWire files Download web.config (translated from original .htaccess) file from this post, unzip it and put it in ProcessWire root directory Delete .htaccess file (because you don't need it any more). I hope that this will help someone if the need arises for ProcessWire use on this kind of install. web.config.zip

In the famous "30 minutes" thread MadeMyDay somehow made a point by putting ProcessWire into context with TYPO3. Recently, I got an inquery for a multilingual website for a speaker agency. A customer looking for an Open Source solution. These speakers had meta data attached (topics, languages, speaking areas, gender) and this database would be the most essential part of the website. Also, a password protected area was needed where speakers could supply materials such as slides to an exclusive user group. Sounded like the perfect job for ProcessWire, unfortunately, after a while of internal consulting and decision-making, the customer chose TYPO3 instead. PW was totally new for them, they admitted to be fascinated by it, but went with the system they knew in the end. That, and Marc's above mentioned comment made me think. ProcessWire does a good job catering developers but still has room for improvement, in my opinion. Throughout the 30 Minutes / WP Tavern article I often read, "once the developers are on board, the rest will follow". I'm not so sure. It would not hurt to emphasize PW's abilities to serve as a business/enterprise CMS right now. Take the benefit teaser on typo3.org for example, a perfect intro. It states: Open Source Enterprise CMS Scalable Web Application Framework Large, active global community User friendly with unlimited extendability Integrated Development and Editing Workflows I guess most of these advantages do fit to ProcessWire as well or, in the case of continuous integration, are on the doorstep (at least that's how I read "Integrated Development"). And PW's community may not be large yet, but is damn active. Apart from that, the home page is full of, hm, let's say: trigger words that work on some business business owners: "enterprise", "professional", "web solutions" and "certificates". I'm not proposing to copy all this. But I have an idea: Since both TYPO3 and ProcessWire are relatively big here in Germany (each on their own scale) one could emphasize the "also a perfect business CMS" aspect on http://de.processwire.com. I guess this won't hurt "the brand" at all, but, possibly, create some insights on if and how such a communication strategy could work. /edit: These automated capitalized words in the thread title are really annoying :-/

I am not sure if maybe this problem is back, or certain MySQL configurations are still causing issues. Here is some further reading: https://processwire.com/talk/topic/8759-cannot-add-new-language-in-latest-dev-bug/?p=88530 https://processwire.com/talk/topic/5286-switching-fields-to-language-fields-produces-fatal-errors/ I'll make sure it is made aware that this still seems to be an issue. What version of MySQL are you running?

This has apparently been disabled because the circular reference lead to problems: https://github.com/ryancramerdesign/ProcessWire/issues/663 One possible solution for you would be to default to $page if no page is selected. Seems intuitive enough for the user, unless you need “no selection” to actually mean “no selection”. Another thing you could do would be to add a “proxy” page somewhere, called “<This Page>”, and check if that was selected, then use $page.

Passwords aren’t stored as plain text in the DB, so that shouldn’t be an issue. If one is worried about leading/trailing whitespace, one might as well disallow that specifically, or routinely trim passwords (and tell the user about it). Plus, we deal with spaces in POST data all the time anyway?! Even this forum allows spaces in usernames, which kind of blew my mind the first time I logged in. I really dig it. I’m a big proponent of long passwords and I feel, calling them “passwords” instead of “pass phrases” was a major mistake, leading to the stupid password policies we see everywhere, when in reality, the best thing you can do is just have a long-ass combination. Personal sentences are great for this. Easily typed, because that’s what we’re used to type, and easy to remember, because unlike cryptic alphanumeric combinations with an obligatory exclamation point at the end, they make sense even without thinking up mnemonics first…

I don't see through your code and don't understand the why and what and how the form is built. Does your fieldset have a "name" attribute? It needs one, as the InputfieldWrapper::get() search for "name" key.... Just to mention you can also use find() to search by id: $fieldset = $form->find("id=myfieldset2")->first(); here the same with nested fieldsets, still works fine: $form = $modules->InputfieldForm; $form->action = "./"; $form->method = "post"; $fs = $modules->InputfieldFieldset; $fs->attr("id+name", "myfieldset"); $fs->label = "My Fieldset"; $fs2 = $modules->InputfieldFieldset; $fs2->attr("id+name", "myfieldset2"); $fs2->label = "My Fieldset2"; $field = $modules->InputfieldEmail; $field->attr("name","email"); $field->label = "Email"; $fs2->add($field); $field = $modules->InputfieldText; $field->attr("name","firstname"); $field->label = "Firstname"; $fs2->add($field); $fs->add($fs2); $form->add($fs); $lastname = $modules->InputfieldText; $lastname->attr("name","lastname"); $lastname->label = "Lastname"; $fieldset = $form->get("myfieldset2"); $firstnamefield = $fieldset->get("firstname"); $fieldset->insertBefore($lastname, $firstnamefield); $content .= $form->render(); First works cause it's correct, second isn't. You field $someotherfield isn't child of InputfieldWrapper $form. But it is a child of InputfieldWrapper $fieldset1.

PW Dev >= RC in anything else.

Thanks a lot for your quick response! I understand the philosophy. And it's a good news, I'm happy to know that we can enjoy the dev branch without "great danger"...

This works fine for me. $form = $modules->InputfieldForm; $form->action = "./"; $form->method = "post"; $fs = $modules->InputfieldFieldset; $fs->attr("id+name", "myfieldset"); $fs->label = "My Fieldset"; $field = $modules->InputfieldEmail; $field->attr("name","email"); $field->label = "Email"; $fs->add($field); $field = $modules->InputfieldText; $field->attr("name","firstname"); $field->label = "Firstname"; $fs->add($field); $form->add($fs); // insert later $lastname = $modules->InputfieldText; $lastname->attr("name","lastname"); $lastname->label = "Lastname"; $fieldset = $form->get("myfieldset"); $firstnamefield = $fieldset->get("firstname"); $fieldset->insertBefore($lastname, $firstnamefield); $content .= $form->render();

I have this topic for open source related campaigns: http://ubuntuforums.org/showthread.php?t=1946197 Here's one project that has attracted a lot of attention and some criticism: https://www.indiegogo.com/projects/sondors-electric-bike High drama levels: https://electricfatbike.wordpress.com/2015/02/27/electric-fatbike-com-officially-ends-our-coverage-of-the-sondors-ebike/

Any website that promotes Processwire will always be of benefit and helpful by encouraging others to try out Processwire that are looking for a cms. But for me the best way is to focus on making Processwire the best it can be and everything else will follow. There are still many other areas of Processwire that can be improved on and when that is done and focused on I think Processwire will speak for itself. In my experience though admittedly I haven't built websites for businesses larger than 10 staff is that if you do your job properly and come across as someone who knows what they are doing the buyer of your service will be more than happy to let you make the decision on what is best for them as that's one of the points of hiring an expert in the first place.

/?/ is not the url that was called, it's what the shutdown function outputs when $page isn't set. You'll have to dig into the webserver logs to see which url was called for real.

Hi! Thank you for this great module. Easy to implement and exactly what I was looking for. //Jasper

I've just tested these with 2.5 and everything is running nice and smooth.

I've a feature request. As I can assign users of ProcessWire the right to view/list hanna codes it would be nice to be able to incorporate a description field, where I can add small explanations for each code. This way the list/view permission would be more useful on it's own. This could maybe later be incorporated in something like a small dropdown underneath hanna code textfields.

Greetings, This is one of my primary reasons for getting away from Joomla and discovering and falling in love with ProcessWire. I wish this problem were more known. I work with a number of Drupal/WordPress/Joomla people, and I am amazed at how many just assume that what you install in these systems is safe. I'm talking about developers, by the way, not "regular" users! It's not only malicious plugins -- innocent ones can be an issue too. They all open security holes. A well-intentioned developer can compromise your application (I witnessed it first hand). I think another part of the problem that we don't hear about is hosting dishonesty. A lot of hosts specifically market to the Joomla audience (for example), and they spread a bit of false security. I've had conversations with two developers in recent weeks who host at a particular cloud service, and they both believed that the host protected their sites from malicious plugins. (I actually went so far as to write to this host and ask them to guarantee this, at which point, of course, they admitted it was not true). On a related note: happy two-year mark Joss! I'll try to round up the old Seblod and Molajo team for a celebration. Amy Stephen might come too. Matthew

I may would go with something like processwire.com/business/ or business.processwire.com or business.pw ((or enterprise.pw or vip.pw) redirecting to processwire.com/business/) which points out why ProcessWire is able to be used as enterprise/business CMS. Maybe also offer Premium Support and so on. Probably I would use a little different design of the page (at least colours). A little bit darker. So it feels more classy. And enterprise people think they are in there own section. Good examples: http://vip.wordpress.com/ https://www.dropbox.com/business/

I totally agree. Especially in Germany, TYPO3 has that weird reputation of being the best and most professional CMS/F in the room, although I perceived it on the editor/usability- and templating-side as unnecessarily complex (I tend to think that the service ecosystem that developed around this complexity tries to keep it that way). Since both TYPO3 and ProcessWire are relatively big here in Germany (each on their own scale) one could emphasize the "also a perfect business CMS" aspect on http://de.processwire.com even more Communication-wise, there's plenty to learn from the big fishes. /edit: I started a new thread on this topic since it's not really related to the WP tavern article: https://processwire.com/talk/topic/7184-lets-highlight-processwires-ability-to-be-an-enterprise-cms/

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.

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

Ok, last one on this, but just so you guys know about the kind of journalistic quality we are dealing with in that blog post, this is the thumbnail that was used to illustrate it: http://wptavern.com/tag/processwire

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.

Could it be built more rapidly, smoothly and reliably with ProcessWire? Absolutely. Could the same be said of using a quality framework vs. starting from scratch? Yes, though I'd personally choose ProcessWire. Would it be as scalable as building something from scratch, and optimizing it specific to the need? No way. As Facebook grew, they even went as far as to build their own PHP, separate from the one you can I use. Using an existing PHP framework like ProcessWire is an excellent way to take a potentially big idea to fruition. If the idea is a good one that delivers on being the next Facebook or Craigslist, then you'll have no problem getting the resources to take your application code where you need to. I think most of the heavy-hitting services out there start this way, and then move on to something custom once the scale justifies it. But that scale is extremely large. It would be cost prohibitive to build for that scale when you haven't yet reached it. In terms of price to pay, the most likely needs for scale can be solved by increasing your server's resources or switching to a cloud-based hosting environment that can scale larger than an individual server. But again, if things get Facebook-large, then you'll be in an entirely different segment where you'll probably be building not just your own software, but your own hardware too.

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