Leaderboard

Last week I mentioned we'd be continuing the documentation updates into this week and that's exactly what we did. All in all, these documentation updates involved 46 files and 5264 additions, so far. Read more about it in this weeks' blog post: https://processwire.com/blog/posts/processwire-3.0.16-continues-expanding-documentation-and-more/

There is a CKEditor plugin that looks like it's designed for what you want: http://ckeditor.com/addon/div You can try it out in the demo, third toolbar row.

is_int() & is_null() if(is_null($page->cruise_spaces)) if(!is_int($page->cruise_spaces)) if($page->cruise_spaces === NULL) if($page->cruise_spaces !== NULL)

I am passing on this information to make you aware of some recent changes to the Google Chrome browser. Security Update for Chrome Version 50 http://googlechromereleases.blogspot.com/2016/04/stable-channel-update_28.html No More Updates To Chrome on Windows XP/Vista and MacOS 10.6/10.7/10.8 after Chrome Version 49 https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html Note: Many of you will have your computers setup to automatically update the Chrome browser, however you should be aware of these important changes to ensure your browsing experience is still secure. https://sites.google.com/a/chromium.org/dev/Home/chromium-security

$childCount is a PageArray but you need a number. Add ->count() after children(...)

Hi dlen, I don't know to which particular post you are referring too, but in general: this is why. See our PHP Coding Style Guide for more information.

Found some helpful discussion related to this issue here. The value of the inputfield must be set to a Pageimages object for an existing page. By default $page is used (which isn't what is wanted for this example) but it can be changed to a different page. In the context of Soma's gist the fix is to add the following at the end of the "success" section: $form->get("myimages")->attr("value", new Pageimages($uploadpage)); So the complete success section is if(!count($form->getErrors())){ // if no error occured // create new page and save values $uploadpage = new Page(); $uploadpage->template = "upload-entry"; $uploadpage->parent = $pages->get("/upload-api/"); // add title/name and make it unique with time and uniqid $uploadpage->title = date("d-m-Y H:i:s") . " - " . uniqid(); $uploadpage->addStatus(Page::statusUnpublished); $uploadpage->save(); // save uploaded files to new page and remove temp files $files = explode("|",$form->get("myimages")->value); foreach($files as $file){ if($file && file_exists($upload_path . $file)){ $uploadpage->myimages->add($upload_path . $file); unlink($upload_path . $file); } } $uploadpage->save(); $form->get("myimages")->attr("value", new Pageimages($uploadpage)); $sent = true; // or better do a redirect here before showing thank you text. }

You can try == "". But just use var_dump($page->cruise_spaces), or echo(gettype($page->cruise_spaces)) to see what it really is.

Hello, Try by using title instead of Title.

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

Worked perfectly! Thank you @tpr.

added the module to the modules directory and changed version number to 1.0.0 please let me know if anyone experiences problems

I think this is the problematic step. CKEditor can't know that you want to wrap these selected elements in a new element. Try creating an empty paragraph (maybe with a space or temporary character in it), select and apply the "Box" style, then cut and paste your paragraphs into it. You're probably aware of this already: it will be easier to see your box element if you add some styles for .box in your CKEditor "contents.css".

Hook into Users::added and add the role to those users there.

Thanx for sharing your findings!

I'd suggest using the WireUpload class instead of trying to emulate what it does: https://gist.github.com/somatonic/5233338 It's also best to let the file / image field move added files to the correct location and not moving them there beforehand.

This seems like it might go back a very long time: https://processwire.com/talk/topic/1125-images-field-returning-array-even-when-max-files-set-to-1/ I feel like I have come across this before too and been in a hurry and just used ->first() rather than trying to debug it. A couple of things that work other than first() $user->of(true); echo $user->avatar->url; or this: $u = $users->get($user->id); echo $u->avatar->url; Both of these work. In a rush so not sure why - I don't see why the $user object seems to have outputformatting off by default - maybe this is intentional, but I don't recall.

Damn it. You were faster. I had the same module on my to-do. Thanks for the module. Very helpful! I have three more points as a feature on my idea list: empty the ProCache and AIOM+ cache when they are installed. Remove all image variations and a short-cut to clear everything at once.

Thanks @Mats! The map tiles are designed in Mapbox, the map itself is built on Leaflet.js, using the great Ember Leaflet addon. Once you get the hang of Ember.js (quite a steep learning curve) and it all starts making sense, it becomes really logical and fast to build upon. Because it is so strict, you can predict how components and external addons will work, and how to separate your functions. All using the same philosophy. As a result, it's peanuts to toggle markers and other layers on the map that relate to other items in the application. Let me illustrate how easy it is. The polylines are added by adding a Polyline-layer, which is part of the Ember Leaflet addon. It requires 'locations': an array of lat/lng points. The stripped down version of it works like this: 1. From the API we get, for instance, this JSON for the Hoofdroute (main route) -> http://www.intonature.net/api/routes/hoofdroute 2. Through the default Ember Data Rest adapter this JSON gets loaded into the route* model: // models/route.js import DS from 'ember-data'; export default DS.Model.extend({ title: DS.attr("string"), points: DS.attr("array"), color: DS.attr("string"), }); 3. After the model promise is fulfilled, it renders the Template belonging to the Route*, often with help from an Controller to 'decorate' the data. If that made no sense, you can also read that previous sentence like this: Through the magic of Ember this ends up at the Map Component which is inserted into the Explore template. The stripped down version of the Explore template: {{!-- templates/explore.hbs --}} {{map-component locations=locations currentItem=currentItem currentPreviewItem=currentPreviewItem routes=routes }} 4.And then inside the map component we get the following: {{!-- components/map-component.hbs --}} {{#leaflet-map id='explore-map'}} {{tile-layer url=tileLayer}} {{#each routes as |route|}} {{#if route.points}} {{#polyline-layer locations=route.points color=route.color }} <span class="route-label">{{route.title}}</span> {{/polyline-layer}} {{/if}} {{/each}} {{/leaflet-map}} And that is essentially it. We load the /explore route*, which loads data from the server and puts it into a model, then renders its template. This template contains a component which draws polylines on top of a tile layer. My previous large map-oriented / PW- & RequireJS powered project took overall about 300 hours to develop. In large because I had to invent the wheel, discover fire, and then deal with burning wheels everywhere. In short: I was missing a strict, well defined idea of which part is responsible for which function, something that happens to a lot of developers I have noticed. That, combined with the incredible shitty documentation of the non-standard Google Maps stuff and some other setbacks made it quite a tedious project. (The resulting site is still quite nice though: http://www.vangoghroute.nl ) Developing Into Nature took me around 90 hours, of which maybe half map-related. I still had to figure out a lot, yet I don't think I'll quickly return to the old world of "Php-generated html with bits of Javascript here and there and oh let's throw some more Ajax at it shall we?" * Let me clarify: We are dealing with 2 kinds of routes here. First of all the "Into Nature art routes", and then there are the 'Ember Routes'. Ember Routes are the urls of the app, and responsible for getting data and injecting that data into models.

Thanks for the hint, it's fixed. I thought I tested the link! Considering this module and future development of PW. Yeah, I was playing around with that yesterday, but couldn't see a solution. Unfortunately I knew this would one day lead to complications. :/ After little experimenting I think we need to rethink $page->url rewrites Multisite does in the admin and consequently in the front-end. I always feared it was maybe dangerous/adventurous and would lead to problems sooner or later. There's so many things to consider it's crazy. So, after long thinking and testing, I'm heading towards letting the $page->url alone, to not get in the way as much as possible. Then we just have to make sure 2 things: 1. when an url is viewed containing a "domain" in its path that is recognized, to redirect the correct domain/url. So a view link will just work. 2. to have correct url on the front-end output, we can parse the $page->render() output and replace/fix those urls output from templates and RTE's. This way such new features like the "View" options work out of the box. Also cross Domain linking in RTE would work also. I got a test version working so far but not sure about what to further consider with this new approach.

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}' ) ) );

New update to v0.0.5. Lowered minimum required PW version. I just tested it on a install with PW 2.6.10 and fixed some small issues. Added support for WireCache entries using a selector as expires instead of a date.

Yeah https://github.com/somatonic/ClearCacheAdmin/commit/88da90563991b7e156d0738143be7b17dc43249b I'm running php 5.3 and it works.

Not at all. Yeah why not. But I originally just wanted to be able to trigger the various caches by simply using their own API. I wasn't doing any real operations or deletions just delegation. I now added support for "Other files and directories in the site/assets/cache/ dir". For now they will now show up in menu and on admin page and you can delete them recursively. Version 0.0.2 is commited.

Hi Barry, you could install Admin Custom Files and use the 'ProcessPageEditTruncate.js' drop-in. That one is multi-language aware.

To add a new menu item in the admin, you just go in there and add a page like you would anywhere else (and use the 'admin' template for that page, or one of your own if you prefer). If you want it to live between 'Pages' and 'Modules' then just drag it between those two. If this is something that you want to do automatically (like as part of a module installer) let me know and I'll post a code example. My understanding is that you want to display a custom HTML table of pages on your new admin page. You can go about this in two ways: Option 1 You can do it the same way as you would for any other template in your site. Only you would select your new template for that page rather than the 'admin' template. You would set access with the page (2.0) or with the template (2.1). The advantage of this approach is that it's really easy. The disadvantage is that your page may not look like the rest of the admin or use it's systems (which may or may not be useful to your need). Option 2 Use the 'admin' template for your page, create a new 'Process' module and install it. When you edit your new page, it will ask you what Process it should run, and you'll select the new Process module you created. This is the approach you want to take if you want to maintain a consistent admin experience or you want to package your functionality into a reusable module. Here's an example of how to create a Process module: /site/modules/ProcessHello.module <?php class ProcessHello extends Process { public static function getModuleInfo() { return array( 'title' => 'Hello', 'summary' => 'Simple Process module demo', 'version' => 001, ); } public function execute() { return "<p><a href='./hi'>hi</a> or <a href='./bye'>bye</a></p>"; } public function executeHi() { $this->message("Well hello"); return "<p>You clicked hi!</p>"; } public function executeBye() { $this->setFuel('processHeadline', 'Goodbye?'); $this->error('Not so fast!'); return "<p>You clicked bye!</p>"; } } Regarding your question about permissions: The user must have access to the page your Process is on before they can execute it. And they will already by default (unless you change around the page/template permissions). But in PW 2.0, they must also have access to a permission with the same name as the module. PW 2.0 installs that automatically with your module. This is only applicable to non-superuser roles (superuser can already access everything regardless of permission). In 2.1, PW doesn't install a permission and access to the Process is assumed if user has access to the page it's on. If you want PW 2.1 to behave like PW 2.0 and require a specific permission before it'll run the module, you want to specify it in your getModuleInfo function: <?php public static function getModuleInfo() { return array( 'title' => 'Hello', 'summary' => 'Simple Process module demo', 'version' => 001, 'permission' => 'name-of-permission', // NOTE THIS ); } Replace 'name-of-permission' with the permission name you want it to require. It can be any existing permission, or one that you've created. Your module can also check other permissions on-the-fly, but I won't get into that here unless someone wants me to.