Leaderboard

i finally found some time to finish the greek translation, you can download it also from github processwire-greek-language.zip

I don't think I have ever needed more than a standard mysql text field. 65,000 bytes is a lot already. Jeez, that's the same as the total RAM of my first computer Type | Maximum length -----------+------------------------------------- TINYTEXT | 255 (2 8−1) bytes TEXT | 65,535 (216−1) bytes = 64 KiB MEDIUMTEXT | 16,777,215 (224−1) bytes = 16 MiB LONGTEXT | 4,294,967,295 (232−1) bytes = 4 GiB

Seems like someone gained from the bite. A Norwegian punter has just won €2000 after backing Suarez to bite someone at the World Cup at 175/1 http://www.joe.ie/sports/betting/a-norwegian-punter-has-just-won-e2000-after-backing-suarez-to-bite-someone-at-the-world-cup-at-1751/

Edit 2: Found the problem. It's a bug in my Quick Tags Editor...

There is a software limitation applied by the sanitizer. For textarea fields this limit is 16384 characters. https://processwire.com/api/variables/sanitizer/ http://cheatsheet.processwire.com/sanitizer/properties-and-methods/sanitizer-textarea-value-options/

There are several options: Check if the $p has a specific template (or any other field). if(count($children) > 0 && $p->is("template!=news-item|other|template")) Or exclude above the loop like: $children = $p->children->not("template=news-item|other|template"); Or filter above the loop like: $children = $p->children->filter("template!=news-item|other|template"); See the excellent cheatsheet for more options in the PageArray/WireArray. Another option might be to use to use soma's navigation module.

Don't suspend Suarez:

Field Generator is a module to help you create random character strings and automatically assign them to one or multiple fields of your choice when a page is created. When setup, it will automatically do so whether you create a page through the administration panel or through code, meaning you don’t need to set $page->name or any other field of your choice, it just works automagically. Field Generator uses PHP’s openssl_random_pseudo_bytes() function to generate its random strings. It thus has both PHP >= 5.3.0 and OpenSSL as dependencies. Usage After installation, add rules through Setup > Field Generator. That’s it! Rules only run when first creating the page. For more information : https://github.com/plauclair/FieldGenerator Release : Version 0.9.0 This is the initial release. This is near stable and you shouldn’t be too worried to use it in production. Here is a screencast on how to use it.

Charlie Bit My Finger SUAREZ VERSION! https://www.youtube.com/watch?v=N5vREwbPbl4

I don't know if it has to do with that specific issue, but I think you should leave output-formatting off as long as you save stuff.

why not $lang = $languages->get($sanitizer->pageName($input->get->lang)); if($lang->id){ $user->language = $lang; $user->save(); } DOn't see the need for looping

Problem solved $vid_url = $pages->get(2331)->downloads; thanks anyway

Page "name" is not a field like the others. https://processwire.com/talk/topic/4720-how-to-set-page-name-in-different-languages-through-the-api/ You'd use $page->set(key, value); instead of setFieldValue()

Well, after a lot of fiddling, looking up the database and too much var_dump’ing, here’s the answer: if ($language->name == "default") { $page->name = $value; } else { $page->setFieldValue("name".$language->id, $value); } Where $language is a correctly queried language.

That did the job ty. Here is my code: <?php class removeInactiveUsers extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Remove inactive users', 'version' => 101, 'summary' => 'Every X minutes removes inactive accounts', 'singular' => true, 'autoload' => true ); } public function init() { $this->addHook('LazyCron::everyMinute', $this, 'removeInactiveUsersFn'); } public function removeInactiveUsersFn(HookEvent $e) { $inactiveUsers = $this->users->find("!user_activation$=0"); if(count($inactiveUsers)){ foreach ($inactiveUsers as $u) { $this->users->delete($u); } } } } Ty for help guys

Try replacing: $users->delete($u); with: $this->users->delete($u); Also, turn on debug mode so you get some error reporting - these should be showing up.

Doesn't "template=user, !login_end<=today" work?

https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=64049

I've updated the module so now it's possible to set a custom time in seconds to control the cache in the browser and in CloudFront. Previously it used the Expires Header but it's advisable to user the Cache-Control directive instead.

Quick hint for translation: 1. Step use the ProcessLanguageTranslator https://github.com/kixe/ProcessLanguageTranslatorPlus/blob/master/README.md 2. Step with this Addon you could choose any "untranslated" file in a List including corefiles... best regards mr-fan

As far as I know most of the language packs are changed with full releases, so there are differences between 2.4. and the dev version. Have you tried deleting the existing InputfieldPage.module translation file and manually add a translation via the admin backend, instead of uploading the json from the language pack?

When its not of any concern that the navigation will be 'static' you could use a field of the type Page which contains a list of the pages you need to list. Create a new field called navigation of the type Page, make sure it can contain multiple pages and select the Homepage as parent. Then attach this field to the Home template. Next thing to do is add all the pages you want to list in the navigation and sort them the way you like. Then in your code you can loop trough them as follow: $navigation = $pages->get('/')->navigation; foreach($navigation as $item) { // your html for the menu }

As a quick heads-up I've just updated the module (twice, as it turned out that Joss' problem was related to certain regexp not expecting .co.uk TLDs..) and it should now work with the new Google Maps URL format. The problem is that this new format is more difficult to work with than earlier one, so I'm doing some ugly tricks (such as relying on old maps URLs) to keep things working. This is not a good solution in the long term, which is why an extensive rewrite of this module is going to be required soon, unless there's some solution I just haven't thought about yet. I've added a new checkbox to module config, titled "use coordinates". If this is checked, new maps URLs will be embedded based on coordinates, which is accurate but also replaces place name with those same coordinates. If it's not checked, location name will be used instead, which is far less accurate and for Finnish place names, for an example, practically didn't work at all. Like @Hani pointed out above, old Maps URLs still work -- which is a very good thing, since at least it means that old content should (for the time being) remain intact

i usually do this: $totalPages = ceil($total / $items_per_page); edit: ah - just noticed adrian got there first...

This solution from diogo looks clean and logical: https://processwire.com/talk/topic/1074-get-total-pages-pagination/?p=9411 What have you tried that didn't work? You can also get the count of pages like this: $num_pages = $pages->count("selector"); Then obviously divide this by the number of items you are displaying on each page and then ceil() the result. Although this option would require a second query to the database, so go with the first option if you can.

Congrats to all Germans, you guys played good!

Recent versions of the dev branch add some more classes in there (if I'm remembering correctly) to make more style options possible in the pagelist. The separator character is now added by CSS rather than being in the markup, which is probably why it started showing up there. If it turns out to be problematic, I can change it back to a non-css solution for that.

If a customer want a Drupal or a Wordpress site, it's up to them. We try to convince them for ProcessWire. If they don't want ProcessWire we help him to find an other company who delivers Wordpress or Drupal. Building a site in Drupal & Wordpress is 1 but maintain it is a whole other story. It would take me ages to find out how those structures/template-languages work & i won't remember it after a year or so. Customers are better of with an external company making those Wordpress/Drupal sites. It's not unthinkable that Wordpress or Drupal looses interest for the big public. Maybe some other player will show up on the market or a huge security hog will be all over the news. Popularity can drop very quickly and then you're sitting there with your template-tag knowhow. Lots of time spend in ProcessWire is PHP time. PHP will not out of the picture soon and if it does, you learned a proper scripting language, not a template language. I can ask a PHP developer to build a site using PW, give him the cheatsheet, and let him start right away. ( That's unthinkable with the other 2 ) I want to gain valuable knowledge while working having fun, ProcessWire let me do this.

Yet another option would be FieldtypeConcat, where you can combine the output of multiple fields into one, and then use that field as your page list label.

Interesting topic, thanks for creating it Joshua. We have had similar talks since Drupal seems to be a platform that many organisations know in Finland. Big boys only talk about Drupal or Sharepoint. I have had my talks with our clients about "PW vs Drupal"... today I just do what Ryan once suggested: show them PW - build something quick, let them see how you develop with it and how quickly you can make things. You know you can build the whole backend of "events management" or "custom application never build before" in just about 30 minutes. Just build it. But if you do want talk about PW and Drupal, you should mention these things (I am by no means a Drupal expert and too lazy to check all the facts, so take this with grain salt and please do correct me if I am telling lies): Drupal release cycle is too fast for many. They try to get new major release every two year and only two latest are supported. Also major releases do break APIs, so probably most of the custom development need to be redone at least every four year. This might be fine on some projects, but for our clients that is usually an impossible schedule. It helps a little that new versions usually don't ship on time, though - and also some community efforts are trying to keep older versions secure. Ask people about their Drupal projects... most are not too proud of those: "This is little hacky" or "We didn't follow most of the best practices here, since we were in hurry". Those comments we got from the company, that we bought to teach us Drupal development and wanted them to show us their best work... Many people build sites with Drupal without really knowing how it works... which is understandable since it takes about 6 months to learn that beast (heard that 6 months estimate from CEO of biggest Drupal company in Finland and my initial feeling and personal experience suggest that it is pretty accurate). Drupal development is very different from normal PHP coding: If you (and your co-workers) have invested 6 months to "unlearn" PHP development and learned Drupal, you don't want to think about alternatives on that point. Drupal projects are expensive. In Finland ie. "The cost of Drupal web projects usually begins at about 20,000 euros, but projects best suited to Drupal generally cost more than 100,000 euros." (source: http://northpatrol.c...nal-products-2/). I usually draw a picture where PW is lots of tiny blocks, that cover 80% of needs and very little goes away. So you just build the remaining 20% and you get exactly what is needed. With Drupal (or any other "big" platform) you do get big block that goes well over 100%, but has more than 20% of holes. So you do have to build the remaining 20%, but also end up more than what is needed. So if you want to get rid of all the bloat, you do have more work to do. I have personally tried and wanted to learn Drupal for many many times. I always end up with big frustration and sites that were "nearly there". That was before PW, of course. EDIT: This was all very technical, so might want to talk this language only with tech orientated clients. With others, I would focus on PW admin usability and flexibility on frontend.

I've never seen a panther fly... but if they would it would be more elegantly than a pig for sure

I respect Drupal, but strongly dislike using and developing in it. This comes from a couple years of developing sites in it. The problems with Drupal have certainly been a motivation in making ProcessWire happen. Out of the box, ProcessWire is going to be a lot better at the large scale than Drupal. ProcessWire's architecture, foundation and API are far better than Drupal (captain obvious). People may use Drupal at large scale, but I don't believe the product itself was ever truly designed for it. Like with WordPress, being used at the large scale is something that happend to Drupal rather than something it made happen. Drupal is a pig that people have affixed wings to because there wasn't any other way to do it at the time. You see similar things happen with the other big platforms (WordPress, Joomla). As far as pigs go, Drupal is a good one. There are some things to respect (though not necessarily agree with) about Drupal's roots and the original thinking behind it. There's no doubt that it is far better than Joomla, for anyone that cares about this stuff. Beyond that, where it excels is in all the 3rd party stuff written for it, to do just about anything. It's a diesel-powered cuisinart in that respect… whatever you need to blend, it will blend… but it'll be messy. Working at large scale, 3rd parties have built all kinds of caching, CDN and load shifting things to throw on top the pile (and likewise with WordPress). Even a pig can fly if you strap wings on to it. And Drupal has a lot of folks thoroughly invested in it to the point where they are making that pig fly. Drupal is also such a household name that it represents a low-risk position for decision makers (low risk of job loss from choosing Drupal). None of this makes it a good product, just a safe one for people that don't know any better. But for people that do know the difference, we want a panther, not a pig.