Leaderboard

Thanks for posting, this implementation looks pretty cool. I think Drupal lends itself particularly well to this sort of thing given that it's a markup generator where there are a lot of known factors both in structure and markup. What I usually think of as a disadvantage becomes an advantage with this sort of thing. It seems like a natural progression for Drupal as the admin side often is just an extension of the front-end already. I would also like to see something similar in ProcessWire at some point. But as a fun module useful for specific situations, not as a recommended way to edit most content. Inline editing is eye candy rather than something that's actually positive for the online experience. It really sends the wrong message when it comes to content portability and accessibility. Editors need to be focused on the content, not "this viewport." It goes against the nature of markup and regresses one back to thinking on print terms. I can see one of my clients trying to put a line break in the headline to make it look the way they want it, and then ending up with what looks like an error on mobile and feeds. That's just the tip of the iceberg. It also means you are no longer editing an an environment designed for editing. A place ideal for viewing and one ideal for editing may be very different places. But I like the potential of having a front-end editing capability for those times when the developer determines that the front-end is a good place to edit some things. Spark will be a good project to keep an eye on.

You don't have to use strtotime() or mkdtime() to build a timestamp if you don't want to. (you used to have to back in older versions though). You can use any date string recognized by strtotime, i.e. here's an example that loads all pages for a year specified in the URL segment: $year = (int) $input->urlSegment1; $blog = $page->children("date>=$year-01-01, date<=$year-12-31");

I just commited a major update to this theme I use every day Improved page tree with some new icons. Changed login screen a bit. Changed content layout to have all content, title and tabs included with round corner and slight shadow... Made sure that everything works with field columns (had still some issues). Made the max width of layout a lot wider. I updated the first post with the lates screen. If you happen to find any bugs or problems, please let me know so I can fix it. Latest screen:

Sneak Preview (everything configurable, styling mostly controlled by admin theme):

Ok, i did it I put a repeater inside itself just to see what would happen, and the result is not pretty. As soon as you create a page with it, it creates a big number of repeater pages and breaks the system. It would be better if PW would just disallow this.

Thanks Soma - I use this on every PW install. Sure, most of those are just on my local server, but that still counts.

Antti, As far as I can tell, URIs are all represented in a subset of ASCII characters (see RFC3986) but allow for the embedding of other characters (including unicode characters) by allowing them to be percent encoded into the URI. Browsers understand this and decode URIs to display the correct characters in the address bar and they allow you to enter the unicode when typing the characters in the address, converting them on submission using URL encoding. You can do this yourself in PHP using urlencode() or rawurlencode(). Looks like copy and paste out of chrome is pulling the encoded string out of the address bar. Edited to add: Just found the relevant part of the article I linked...

Hey! Although ProcessWire is fairly simple, you won't put it to work without some effort. If you are willing to try, we will be here to help for sure. Still, maybe you should have a look at these "put on the folder and go" self hosted CMSs http://gpeasy.com http://www.razorcms.co.uk/ edit: ah! by coincidence, gpEasy was referenced on another thread today have a look at it http://processwire.com/talk/topic/1365-inline-editing-the-drupal-spark-way/#entry12240

Looks really nice Soma.

Looks cool, I'll give it a shot 2night.

It sounds like the behavior you had before was with beautify turned off, and now it's turned on. Beautification includes removing adjacent punctuation characters, in addition to other things. You should be able to override that by setting it a second time (so that it knows you are serious). Try this: $p->name = $filename; $p->name = $filename;

Ryan, he means the default URL description text. Which is nice, but if you enter a space in the description there will be still a space above the input text field. I figured that adding in a 0 (zero) will ommit it completely, thus no space anymore. I think there should be the default text in the field description, or none at all. So you can input or leave it empty, without asking anyone. AS for the other problem of field heights. It's annoying and I started a js script that would set all (in one row) to the height of the highest. Unfortunately it's more of a bad hack to something that should be possible in browsers since a decade (imho) and will fail for the reason you mention. Maybe we will find some solution here that works better.

I can duplicate too. Though taking a closer look, I don't see an obvious reason or fix for this. I think it just gets down into the DOM manipulation done by tabs and the effect on events. I'm going to have to come back to this one, so have added an issue report at GitHub.

A module doesn't necessarily need it's own directory, you could just put it in /site/modules/. But for modules that have more than one file, it's good to put them in their own directory. The directory should be of the same name as the module. However, there are cases where you might have multiple related modules go together (like the LanguageSupport modules), so PW will let you have a dir one depth that doesn't match the module name. In that case, it's good to name it with the primary module name (with LanguageSupport again being a good example of this). The modules in /wire/modules/ also use this quite a bit for grouping, as there are dirs for Process, Fieldtype, Inputfield, etc. You can do this for 1-level but not 2. The point of this is to place some limits on the directory parser to keep things fast. While it's not good to place them there, if you are aware of it and can respond properly during upgrades, I can't think of any reason why 3rd party modules wouldn't work from /wire/modules/. It seems like it should be okay. PW does keep a cache of module locations, so if it's one you had moved, that might have caused the error. But I can't think of anything else without seeing the actual error message. There aren't any real technical differences between /wire/modules/ and /site/modules/.

Just a note: The rule of thumb of moving Drupal to PW is: do it ASAP.

I, for instance, use different mail library, because builtin mail() is often acting funky when working with UTF-8. Also, swift::mailer is awesome.

Or, alternatively (of you don't want to read the other thread) – you just get 'starttime' and 'endtime' of the timespan (in the timestamp format) you wish to get pages for and do simple query: $archives = $pages->find("template=blog, created>=$starttime, created<=$endtime");

This might be what you are looking for Marty: http://processwire.com/talk/topic/263-creating-archives-for-newsblogs-sections/ Pete: no need to loop all the articles just to get all the years, you just need to know the first year there has been article published.

Hi recyclerobot, I don't know if this will help but here's a quick rundown of what I did to get this working. I setup a new Ubuntu 12.04 64-bit server in a fresh virtual machine & configured it as an SSH server with a static IP address (Actually, I just cloned one I'd prepared for something else). Then I followed this HowToForge tutorial about installing nginx + mysql + php-fpm. Only thing I did different to the linked tutorial was that I setup APC instead of Xcache. Following that I installed vim-nox, git & phpmyadmin and then created a new DB and DB user for ProcessWire to use. I then did a git clone into /usr/share/nginx/www/pw and added an entry to /etc/hosts called "pw-nginx.test" and also setup this config file in /etc/nginx/sites-available/pw-nginx.test ... server { listen 80; server_name pw-nginx.test; root /usr/share/nginx/www/pw; index index.php; try_files $uri /index.php?it=$uri&$args; location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_index index.php; fastcgi_intercept_errors on; fastcgi_pass unix:/tmp/php5-fpm.sock; } location ~ /\.ht { deny all; } } That's about as bare bones as I could make it. Next, I created a symlink to this file in /etc/nginx/sites-enabled, reloaded nginx and pointed my browser at pw-nginx.test (I had to add pw-nginx.test to /etc/hosts on my client box too) and I saw the ProcessWire installation page. You may need to fix any permission issues and definitely ignore the warning about .htaccess problems in order to install ProcessWire. Well, to cut a long story short, ProcessWire installed fine and, as far as I can tell, the admin and public interfaces work correctly too. But note this: This configuration is totally insecure. All the protected assets that Ryan posted about above (except for the .htaccess file) are accessible from publicly accessible URLs. As I'm new to nginx, I've not had time to lock down what I posted above. All the above is from memory and I may have missed something. If something occurs to me, I'll update the above. Anyway, hope that helps.

You don't have a scientific spirit

The joys of recursion

This was one of the resources that as soon as I looked at it, it kicked me from a looker to a doer with PW. Fantastic resource Soma. Thanks. I have worked with many CMS's and clarity (good clean documentation) is a very crucial aspect to get people involved and to stay with a project. I give 5 out of 5 stars to PW for this. I look forward to helping where I can.

Found PW through a tweet! Was looking for a clean and streamlined CMS to migrate MODx evolution sites from as the dev team replaced it with Revolution which was too big and heavy for smaller marketing sites IMHO. I have deployed sites on Drupal, MODx, EE, Pyro CMS and can tell you that for many of the types of sites we build, PW is a better match. Currently converting a +150 page site over now and scoping a few more.

Hi All, I am wondering if it would it be possible to use the new language features in 2.2 to create different versions of content for mobile devices and tablets. Detect on the front end and redirect to the right "language". That way you could have content optimized for device groups. I know Adobe has taken this approach with there BC platform. I have not looked in to the language features yet as I am new to PW and just getting my feet wet. @Ryan - Fantastic project. Excellent documentation. Impressive forum participation. Wow. I usually build highly structured sites and PW fits that like a glove plus it looks like a winner for marketing sites / landing pages. Impressed and thankful. Cheers.

I can confirm.

Thanks RC - Glad to be learning along. Funny how I'd been sliding over that template editor few times this round and never caught-on to that action mentioned :|

This template was made before the column feature was introduced. So look in the code, the columns have a special class (guess something with "column", I am not at my computer now). Just apply a "float:left;" to that class in the admin's CSS. edit: I think it is the class "InputfieldColumnWidth". Look for that in the ui.css or add this: .Inputfields > li.InputfieldColumnWidth { float: left; clear: none; margin-top: 0; margin-left: 1%; } .Inputfields li.InputfieldColumnWidthFirst { clear: both; margin-left: 0; }

It will. I want to configure sets where widgets (or whole sets) that can be defined: - global - per role - per permission - per user