Leaderboard

Since allow_url_fopen() is deactivated by some hosting companies here is a little workaround for using Curl: open MapMarker.php and insert somewhere (e.g. after the last function) the following function: private function file_get_contents_curl($url) { $ch = curl_init(); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_URL, $url); $data = curl_exec($ch); curl_close($ch); return $data; } comment out the follwing check: if(!ini_get('allow_url_fopen')) { $this->error("Geocode is not supported because 'allow_url_fopen' is disabled in PHP"); return 0; } and change this line: $json = file_get_contents($url); to $json = $this->file_get_contents_curl($url); works fine for me.

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.

Hej! Has anyone ever tried to save & load the files in / from the S3 instead / beside of the local filesystem ? by using http://framework.zend.com/manual/de/zend.cloud.html it is very esay to implement to save/load: http://blog.ebene7.com/2011/01/21/amazon-s3-mit-php-stream-wrapper-verwenden/ - but will PW work with it? By module? Or even better: a plugin that automatically saves/serves any files handled by the backend.. We will now try to build this, but we'll also happy about any thoughts about it!

Yah! First poll! For fun, but also seriously...

I never wanted to imply that there wasn't a good reason to implement it the way it is now, just why I would've liked the option to edit them in a text editor.

We use PHP built in JSON functions for speed and efficiency. PHP 5.4 adds two new options to json_encode for unescaped UTF8 and "pretty in print", so I think PHP 5.4 will solve this and I will implement a version check so PW takes advantage of it.

I actually did. Why? First of all, I prefer working with larger amounts of text or code in my favourite text editor over working in a web frontend any time. Second, using search/replace mechanism would've made it much easier to keep the translation consistent. There are quite a number of phrases in the translateable files which are used two or more times. (Which, by the way, is a bit inefficient.) I ended up not using my favourite editor (which can handle .json files) because the language .json files are minified and apparently use some kind of escaping for special characters (like German umlauts). I didn't want to risk losing work over some weird side effects of using an editor.

I have a site using it (cloudflare) and in the last 30 days It saved about 70% of my bandwidth normally used on my VPS (with most big files already S3) and it cut the load on the server by about 50%. I have articles that get picked up by other sites and spikes in traffic so that was another win. Another nice feature is it blocks the most of the scrapers that would hammer the server to steal the content. That site gets about 10k users a day and the speed has really picked up and lowered the response time considerably. So far very impressed. Saves me from upgrading the VPS and plus It was a freebie offering from hosting provider that site is on, so I jumped on it. I think they give it away free to get the analytics on the traffic. But that is a better deal for me than Google analytics getting it all since the user does not benefit from that, now do they (just "better targeted ads").

Inline Editing. What fun that is. Adobe took their standalone inContext editor ( an inline) and added it to their Business Catalyst hosted offering. Developers can add attributes to the code (a div with a proprietary tag) that would be recognized by the inContext editor, to restrict the features of that editors use of it. That can certainly help to control the mayhem. But there is lots of that with inline. Plus I hate to see proprietary elements added to html but you usually do need someway to control the users editing scope. For the most part, my experience with end users has been that they need a simple structured way to submit content types that followed repeatable patterns while having some latitude within the "textarea" to add media elements and such. A focused backend serves that purpose. So I don't pine for it as a feature in a CMS. What I do like is the ability to control the presentation of the data entry process. PW has those features with the exemption of required data entry on fields (or am I missing that?). +1 for the repeatable fields. In summary aside from the "wow factor" I feel inline editing is overrated and when available, underutilized. Besides in a few years 60+% of users will be mobile or tablets anyway. Apps rule that space today and will in the future. That means more structure. We will have to create our interfaces to serve the users on the tools they will be using not the ones we do. I am not planning on giving up my keyboard. In fact you can pry my keyboard from my cold dead hands. Or maybe my keyboard will be the surface of the desk while a kinetic or similar device is reading my finger movements in 3D. Ahh what a wonderful time to be an interface / app developer!

Lovely, this is going in my book of web design quotes. Inline editing always struck me as a halfway solution. I used to offer it to my clients as a feature (in CMSes like Joomla and Concrete5), but after a while they all stopped using inline editing. It's a lot easier to talk about a single editing mode rather than two editing modes (inline and control panel), and the existence of two can be really, really confusing for users.

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

If you need a quick affordable and PCI compliant solution to plug a cart into Processwire you might want to take a look at Foxycart.com. It is a javascript based cart (obviously requires javascript client side)that you can plug into anything trivially. It's well thought out. Lots of options. Nothing to maintain. What's nice is being free to turn any page anywhere in your site into a product. Used it with Modx sites without a hitch.

I am planning to make all render methods (the ones that output markup) hookable and also configurable. Although other way to look at it is that these modules should give you all the "low level" methods that make it simple to build your own cart. So current method here is to render the cart by yourself all together (in your template for example). So instead of this: <?= $modules->get("ShoppingCart")->renderCart() ?> You would do something like this: $cart = $modules->get("ShoppingCart"); $items = $cart->getCurrentCart(); foreach ($items as $item) { // get product price from actual product page $product = $pages->get($item->product_id); $total_price = $item->qty * $product->sc_price; $out .= "<td>{$product->title}</td>"; $out .= "<td><input data-price='" . $product->sc_price . "' name='items[{$product->id}]' type='number' size='2' value='" . (int) $item->qty . "'/></td>"; $out .= "<td>" . $cart->renderPrice($total_price) . "</td>"; $out .= "<td><a class='remove' href='./?sc_remove=" . $product->id . "'>remove</a></td>"; } echo $out; Well, look into renderCart() method in ShoppingCart module, it should give you best picture what to do there. But $items has all your items (page id and title), just iterate over them.

Ok thanks for mention. Then I guess it's because it's theme dependend. Couldn't this be done without, and add hidden to such things (as with the mastheader) inline? Every such feature will require to update all themes in the future and can be a trap or/and annoying. Maybe it doesn't make sense, and can't be done as I think. Just wanted to mention it. Sorry, now trying to find the issue, it was a "fault" on my side. The process input css is the one hiding it with absolute position and I overwrote without knowing the context class to add padding and top attributes, thus overwritiing the top -9999 of the core css. So it's all good I guess anyway

I just wanted to say that you can easily put static html files inside PW with all the advantages: nice urls, making them appear on dynamic navigation and searches, or being able to make them dynamic quickly, to name only few. For this, you just have to put them on the templates folder and change the .html extension to .php. Then, go to templates in PW and create a new template for each one, and associate them to these files. Then, create the pages on the tree and choose the correspondent template. That's it! There are also advantages on keeping them as static files of course, being speed the most obvious.

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.

I would take this route... Make the "container" pages you're saying having a template "redirect", with only a single page field "redirect_page" with pagelistSelectMultiple input Then have the template file code: $session->redirect($page->redirect_page->url); or how about "redirect-to-firstchild". $session->redirect($page->children->first()->url); Edit: Another option would be to use javascript to set urls of first level to "#".