ryan

@horst That's great! Thanks @arjen! The more people we have working on it I think the better. I think part of the issue before was just that I created the page 5 years ago and had been the only one making updates to it, and likewise only one that crosslinked it to the CMS and CMF list pages on Wikipedia. I'm guessing this flags it somehow, as Wikipedia likes to see more community involvement (which makes sense). Since I'm still the person that originally created the page, I think it's also best that I'm not the one that adds it on other sections in Wikipedia. If any of you guys thinks that ProcessWire belongs on the Wikipedia CMS and CMF lists, would you consider adding ProcessWire to these pages below? List of content management systems: https://en.wikipedia.org/wiki/List_of_content_management_systems List of content management frameworks: https://en.wikipedia.org/wiki/List_of_content_management_frameworks

Thanks @adrian great to see it back! It looks like you know Wikipedia much better than me, would you be able to help maintain the page for ProcessWire going forward too?

I emailed with the guy that deleted it last month. I didn't get a clear answer about what the problem was, but there were a couple of old links in there that went to 404s, so I think that was part of it. It also sounds like some people helping to manage content at Wikipedia don't think that those involved in a project should be the same ones to maintain the Wikipedia page on it. I think that makes sense in a lot of cases (like for commercial projects especially), but doesn't make much sense in our case. I am aware that nearly all the other CMS projects (open source and commercial) are maintaining their own Wikipedia pages. If someone else would be interested in helping to maintain the Wikipedia page I think that would be good, so that it's clear it's a community and not just some dude in his basement trying to write a Wikipedia page for something that nobody knows about. I did make a lot of edits and removed old links, updated information, etc., but honestly can't figure out how to publish it. So it remains a draft for now. I think we may need someone that knows Wikipedia better to figure this out. But I would like to go ahead and re-publish our Wikipedia page. But how?

New master and dev versions released, more coverage of what you can do with the new Functions API, plus a couple useful tips and tricks. https://processwire.com/blog/posts/processwire-3.0.40-core-updates/

I recommend using API $variables for most cases, but here are a few instances where you may prefer the function versions: If an API variable is out of scope (like in a function), then you may find the new function versions very useful. If your editing environment provides more benefits to you for using the function versions (like auto-completion and docs) then that's also a compelling reason to use them too. This is something we haven't been able to provide before now. If both of the above apply to you, then also use the functions API where you would have previously used wire(). If neither of the above apply to you, then just use API $variables (fewer characters to type, and no questions about what instance). Basically, use whatever provides the most benefits to your scenario. For all practical purposes, $page and page() are synonymous. I don't see any reason to use $wire in template files–that's really more for core use. The new skyscrapers template files were specifically developed to demonstrate the API variables as functions for that blog post. Basically, I wanted to show you how they work rather than just telling you. So I went out of my way to use them for this particular case. I personally use API variables in my sites, though will be glad to have the convenience of more options when needed. Function alternates to our API variables have been requested multiple times. That's because it's more friendly in how it enables communication between developer and editing environment. I agree that's a good reason to have them. However, you'll likely only want to use them if you find them beneficial in this way. It's completely IDE friendly, and that's actually one of the reasons for this approach versus using user defined $variables for regions. We're just working with strings here. Keep in mind the "+" is only something you add to the region name if you specifically want to prepend or append to an existing value that's already present in there… and most usages probably won't involve that. I'm not sure how to make prepending or appending more convenient than adding a single "+" character to the region name. I'm lazy and don't like to type a lot, so gravitate towards the simplest possible solution. But always open to suggestions.

This week has been busy! We've got updates to our demo site, a new functions API, and other core additions that you may find useful in template files. https://processwire.com/blog/posts/processwire-3.0.39-core-updates/

This week we've got a new dev branch version with several updates which we'll merge to master soon. This post also includes a useful recipe on how to log all outgoing emails sent from your site. https://processwire.com/blog/posts/processwire-3.0.38-core-updates/

In addition to our regular core updates, we also have a new ProFields module to introduce to you this week. It’s something a little different that we’ve found pretty useful and think some of you will too. It's also available for download now in the ProFields board. This blog post covers it in detail: https://processwire.com/blog/posts/text-blocks/

So far things are going great for our new master version of ProcessWire, version 3.x. In this post, we'll take a look at what's new in ProcessWire 3.0.36 master, plus a look forward at what we'll be working on in the weeks ahead. https://processwire.com/blog/posts/processwire-3.0.36-and-looking-forward/

Last week we called it a soft launch, but this week we'll say ProcessWire 3 is now released and considered our new master, version 3.0.35. This post is a changelog of sorts, where we will cover all that's new in ProcessWire 3! https://processwire.com/blog/posts/pw3-changelog/

This is a good reminder for me. There's not enough time in a week (since I got back in town) and there's plenty of little details I still have to attend to, which is why I thought calling it a soft launch was better. This will definitely be added though. You are completely right here of course. I have updated the blog post to add that as well. I agree with this. Composer is pretty awesome and all, but it's not every day that I have a use for it. The work I do rarely requires anything outside of what is already in the PW core. This is likely common among web developers that build sites in PW or some other system that already provides the majority of what you will need. Sephiroth's comment is true when you step outside of this context though, into the wider development world of PHP. With version 3.0 we're hoping to bring more of that world into PW's audience. So even though most of our current audience likely doesn't use/need Composer for many of the sites they develop, my hope is that will change as more people relying on Composer begin to use ProcessWire. Also depending on the site/app, the PW core/modules can't always accommodate every need, so I expect people will very likely increase their use of Composer when the needs for something more arise.

First off, a big thanks to Jonathan Lahijani and Benjamin Milde for taking over the last two weeks of blog posts while I was traveling. They did an awesome job. If you haven't yet read Jonathan's CMS Critic case study or Benjamin's Migrations module introduction, be sure to check them out. This week we started using our new GitHub organization repository to soft launch version 3.0. ProcessWire 3.0 now appears on packagist as well (installable via Composer). We’ve got several other updates for you as well! https://processwire.com/blog/posts/hello-pw3/

This week's blog post is written by Jonathan Lahijani where he writes about the works he's done with CMS Critic: Read the blog post at: http://processwire.com/blog/posts/cms-critic-powered-by-processwire-again-case-study/

This week we’ve loaded up our new ProcessWire repository with the latest 3.x version and we have some more details on that, as well as the official 3.x release date. We’ve also got a recipe you might find useful here as well. https://processwire.com/blog/posts/pw-3.0.33/

Beautiful site, great work Tom! Would you mind adding this one to our sites directory? https://processwire.com/about/sites/submit/

In this post we take a look at the latest core updates and go into detail about how we might handle the release of ProcessWire 3.0 and 2.8. https://processwire.com/blog/posts/pw-3.0.32/

Thanks Ivan, I really appreciate it! You give me way too much credit and are too kind, but such a heartfelt message still leaves me speechless, so thank you again. I don't think I want any kind of luxury car! I'll be honest, while I was sad to give the car back, I was also glad to because it's just plain stressful. There's no problem if someone dents my car or something gets scratched, etc., but borrowing such a fancy car makes you always worried about where you park. If a bird poops on it you have to clean it right off, and so on and so forth. All these things I never worry about, but became apparent when I had to be responsible for such an object for 2 days. I imagine a lot of stress comes with owning something like that. I'm sure to many it's worth it, but still, glad I don't have to think about that kind of stuff every day. If I were to ever own a car like this, I'd buy it after it's already many years old, inexpensive, and has the battle scars to show it. \

No, sadly I don't own a Tesla Model S. Instead I own a 1994 Mazda. But with getting ProcessWire 3.x ready to release, I didn't have a lot to write about this week. So figured, why not chat about something else I'm passionate about (this is a blog after all). Last weekend, I got to pretend that I owned a brand new 2016 Tesla Model S (P90D) for two days and a couple hundred miles. I was so inspired by it, I figured why not write something. We'll even attempt to draw some parallels with ProcessWire. This post also covers updates to several 1st party modules. https://processwire.com/blog/posts/tesla-model-s/

For the modals, after line 352 of PageFrontEdit.js there is setBusy(false); Try adding this right before or after that line: t.trigger('pwreloaded'); I think that will work. But another route is that when the modal window closes a 'pw-modal-closed' is triggered, and that can be captured. That line 352 is within such an event handler, which may serve as a potential implementation example.

Make sure you've got the JS console in Chrome open or something, so that cached files aren't a factor. I'm trying to write about this without being at my computer where I can test it, so take these more as pointers rather than exact code. But you might need to expand that event handler to something like this: $(document).on('pwreloaded', '.pw-edit-orig', function() { // ... }); The front-edit editor uses wrappers <div class='pw-edit-orig'> and <div class='pw-edit-copy'> where "orig" means the original container, and "copy" means the copy for editing.

Alex, an idea here, but I've not tried it yet. If you find it works, I can update our PageFrontEdit.js in a similar manner to trigger the events mentioned below. What's needed is an event triggered that you could monitor and then re-initialize your carousel. First you'd need to update the /wire/modules/Page/PageFrontEdit/PageFrontEdit.js file Starting at line 283, you'll see this: copy.hide(); orig.show(); Update that to this: copy.hide().trigger('pwreloaded'); orig.show().trigger('pwreloaded'); Then in your own JS, monitor the event and re-init your carousel when it occurs. Something like this: $(document).on('pwreloaded', function() { // whatever your carousel init code is, for example: $(this).find('.my-carousel').carousel(); }); Let me know if something like this provides what you are looking for?

This week work continued on preparing 3.x (and 2.8.x) for release. One of the features of 3.x that we'd not yet covered in much detail was the multi-instance support. So the primary focus this week was in making sure we clarified and simplified some things in that respect. This post covers all the details. In addition we've also got some $session updates that we think you'll like! https://processwire.com/blog/posts/multi-instance-pw3/

Some autoload modules establish API variables, like ProCache ($procache) and FormBuilder ($forms). But the wire() method really doesn't have anything to do with modules at all (other than that you can retrieve the $modules API var from it). So continue using $modules->get() to retrieve your modules, and avoid stuffing modules into API vars unless it's something the module itself intends. However, anytime you find the ability to establish your own API vars useful, there's certainly no harm in using it. Just keep in mind that var will remain in scope for the entire request.

Wire::setFuel() is a deprecated method, so don't bother using it. But the purpose of it was to set an API variable. The recommend way to set an API variable now is using the $this->wire() method (available on any Wire derived object). // Set a 'hello' API variable $this->wire('hello', 'Hello World!'); // If outside an object (like in template file) you might do this instead $wire->wire('hello', 'Hello World!'); // If you want to lock it (prevent changes) specify TRUE as last argument $this->wire('hello', 'Hello World!', true); Once an API variable is set, it works the same as any other API variable in PW. It can be retrieved like this: echo $this->wire('hello'); // in object echo $this->hello; // in object echo wire('hello'); // anywhere echo $wire->wire('hello'); // in template file echo $wire->hello; // in template file echo $hello; // in template file All of the above do the same thing. The first two are what you might do from within a Wire derived object or module. And the rest are what you might do from a template file or related (like init.php or ready.php). The last (shortest) example would require that the 'hello' API variable had been set before the file that it's in (like a template file) had started rendering. See the wire() method documentation for more.

@Joss Still seeing that error after yesterday's update/fix to 3.0.29? Just wondering if this is the same issue mentioned by fuzendesign above (which has been fixed) or if what you are seeing is still present. I'm guessing it's fixed since both refer to the same line number, but wanted to double check.