Leaderboard

This week I've got to keep the blog post a little brief because I've been so caught up in this weeks' updates that I've run out of time to write much in the post! The updates this week are not actually to the core code, but rather to the API reference documentation for ProcessWire 3.x. There's lots more work to do still, but I definitely have a good start, so going to introduce it here in this post. https://processwire.com/blog/posts/processwire-3.x-api-reference/

Ryan, you're a legend! Reviewing all that documentation must have been an enormous job. Having up-to-date docs is just so valuable to the PW community so a big thank you for this!

You can halt() like this: <?php if ($config->ajax) { // Do your stuff here echo 'Heard It Through The Grapevine'; // Call halt() to prevent further loading return $this->halt(); }

This thread might help - https://processwire.com/talk/topic/225-how-to-work-with-ajax-driven-content-in-processwire/

Changing the salt won't do anything because the salt is only needed to compare passwords with their db value, which does only happen on login and not for active sessions.

session->getAll() does return all session variables, but not sessions. Forcefully logging users out can be done by removing their session files / db entries or by implementing a bit of code into the processwire bootstrap, which checks if a user should be logged out forcefully and redirect right afterwards.

If you are using Google analytics you could easily use it to track your downloads and have nice statistics and setup conversion goals and so on. You would only have to change your template code. No extra fields... easier than it may sound from the docs: https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide#setting-up-event-tracking

Hello adrianmak! How do you handle passing values to the PayPal checkout? Maybe you'll need something like this: if($user->language->isDefault()) { $value = $page->fieldname; } else { $value = $page->getLanguageValue($user->language, 'fieldname'); }

ClearCacheAdmin Module Since there's so many asking how to clear cache. Here comes a helper module that let's you clear caches directly from the admin menu. Additionally it has its own admin page that's a collection of the various caches available in ProcessWire in one place. See some infos and clear them. WireCache (using $cache) caches in the DB and there no way to clear it from the admin. Now you can delete the entries individually or all in one go. Supports following cache types: - Template "Page" Cache (disk file cache) - MarkupCache module (file cache) - WireCache (DB) - Other files and directories found in assets/cache/ path Wanted to do this for a long time. It was also great fun to do it and give something to the community to also learn something. For now it's on github only. Requires ProcessWire 2.6+. https://github.com/somatonic/ClearCacheAdmin

This week's version of ProcessWire adds several new panels that provide simpler and more direct access to the page tree, page view and debug tools. New page view options also include multi-language selection and configuration support. And if that's not enough, we've also got install-time utf8mb4 support and more! https://processwire.com/blog/posts/pw-3.0.15/

I have just delivered this website: Into Nature (Dutch only), about an 'Art expedition' through the province of Drenthe, in The Netherlands. I built the site for Vandejong. The site is made using two distinct parts/techniques: Processwire for the back-end (through a RESTful json api) and the front-end is built on Ember.js. This is my third large site built this way, and the first I am completely happy about. A page called 'API' is the main interface between the two: it uses urlSegments and parses the content from the PW pages into Ember-friendly JSON data. As Ember is very strict (heavily based on the Convention over Configuration concept), and Processwire is extremely versatile, the way Ember requires its data dictates the way I shaped the API. Both @clsource's REST-helper and ProCache are used to format and cache the API responses, making the API very responsive. Something that was initially hard to wrap my head around was how to deal with the site's routing/pagetree. While Google now indexes modern 'single-page' web applications, for instance Facebook still scrapes their opengraph from the raw HTML pages. I dealt with this by giving the Ember app and the PW page-tree use the exact same routes / pages. Every Processwire page is a valid starting point for the Ember app, while also including the scrapeable meta tags belonging to that exact URL. As a result, the whole thing is nicely CURL-able and bot-friendly.

I tried to delete the old order template and repeater field, and to create both a new one. Issue is still existed. Anyway, I have posted an issue on github https://github.com/ryancramerdesign/ProcessWire/issues/1790

echo json_encode($out); return $this->halt();

Simply clicking 'Like' is waaay too little an appreciation of this. Absolutely extraordinary! And the idea of 'an API to the API' is inspired (and a little poetic).

Just used this excellent suggestion and thought I might as well post some code here. $upcoming_events = $pages->find("template=event, event_date>=today, sort=event_date"); $prev_event_month = ""; foreach($upcoming_events as $upcoming_event) { $month = date("F", $upcoming_event->getUnformatted("event_date")); if($month !== $prev_event_month) { echo "<h2>{$month}</h2>"; } echo "<h3>{$upcoming_event->title}</h3>"; // more event markup here $prev_event_month = $month; }

AWESOME!

I've always found PW upgrades and downgrades very straightforward. The upgrade module will auto backup your database and files too. http://modules.processwire.com/modules/process-wire-upgrade/

For that number of data nodes I'd suggest using neither repeaters nor ProFields Table but a PageTable. Even for a small repeated fieldset of 3 fields this would result in 180 to 240 Inputfields just for the repeater. This can really draw browser rendering performance even if the server does respond correctly. If the number of repeater fields would be near 12-15 you're also close to hitting max_input_vars limits. With PageTables both issues do not apply.

Ok, thanks. Seems that 1.2.6: fail (f8d4ca6c1f8afe31331bdaa94a89b50874371586) 1.2.5: works (TracyDebugger-3f7e1081446ba2d65c8ab2f093f5cb88bfd3bda3)

@tpr - sorry to hear that - definitely weird as it's working fine here. Obviously hard for me to debug without any errors. It would be awesome if you could figure out the exact commit that breaks it for you. You can download the zip from Github for each commit quite easily. That will take you to a link like this: https://github.com/adrianbj/TracyDebugger/tree/0b9696921bcd33ac18460b5501f13c8784b4188b From each of these you can use the normal "Download Zip" button. Sorry this could be quite time consuming for you. You probably do this already, but in this situation I always grab the middle commit between the one I know is working and the one that isn't. If that works then split the difference to the latest and if it doesn't split the difference to the oldest and so on - that should reduce the effort significantly. Thanks for taking this on!

It is a core module, but you have to install it. It's in Modules > Core > FieldType > Profields: Page Table, and you click on Install.

http://modules.processwire.com/modules/process-custom-upload-names/ That module will ensure nice filenames - you can configure however you want. That's great for future images, but for the current ones - there is an option in the module to "Rename on save" - generally I don't recommend this one, but in this case it would allow you to create an API script to loop through all pages and resave them. I would test first on a sandbox PW install to make sure everything works as expected.

Thanks for this module, it works even as expected in a 3.x ProcessWire installation. But it took me a while to understand how this module works and what I have to set up. At the end it's pretty easy but I had to read 9 forum pages and failed initially by installing the wrong module. I summarized all collected information and updated the Readme file (see PR at Github), maybe someone else could benefit from this. To prevent others from installing the old module as well, could @apeisa or someone else having access rights maybe add a litte note to the first post? One more thing: I use MarkupSEO and got some trouble overriding the module config data for each site. Unfortunately I found no way to hook into that specific function and decided to submit a PR as well. Now I can use the following config: $config->MultisiteDomains = array( 'domain1.com' => array( 'root' => 'www.domain1.com' ), 'domain2.com' => array( 'root' => 'www.domain2.com', 'http404' => 1932, 'markupSEO' => array( 'piwikAnalyticsIDSite' => 12, 'titleFormat' => '{title}' ) ) );

@Jon - the wire class can be used inside functions - so in the case of Joss' issue, he wanted the solution to be in a function. when outside of a function like in a template you can use the $pages variable directly...

How about sort pages by date (in the main query), and echo month name if it's different from the previous?

Quick 'n' dirty guide if you want a single page tree with the same content in different languages. The URLs will then look like example.com/en/my-article or example.com/de/mein-artikel 1:) Download and install ProcessWire 2:) Install the modules you find under the "Language" Tab. 3:) Go To Setup->Languages and add new languages. Please note, that the default one is also the default language of your site* 4:) For every field type text or textArea change the Type to TextAreaLanguage or TextLanguage. (e.G. body with TextArea becomes body with textAreaLanguage). You fields should now have multiple tabs for each language, if you edit a page. 5:) Go to the root page (/) and look under "Settings" Setup an URL for every language, e.g. en,de,ru,... . Looks like this: http://take.ms/34Tq5 6:) Create pages and fill in the content. You can build a front end language switch as described in Ryans API Language page. ProcessWire will take care of changing URLS (e.g. /en/example to /de/beispiel) and you can access the current language via $user->language; *It's possible later to define another language as the default language.

Oneliner alarm <?php if(!$session->noPop) include("./popup.inc"); $session->noPop = 1; ?> No intendation

thanks netcarver & diogo - it's working and so simple to implement with PW. this is what i ended up with: <?php if(!$session->noPop){ include("./popup.inc"); $session->noPop = 1; } ?> -marc