Leaderboard

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.

Added new module PageDeferredPublish to Intermediate modules - Module allows you to publish a page at a time interval in the future e.g. 24hrs. adds Publish Later buttons to edit page and page tree uses LazyCron to count down pages that are both unpublished and have been checked to publish later when page count down reaches 0, page publishes

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/

Also, added super simple ProcessSimpleAdminPage module to Intermediate modules – to show adding admin pages within a module.

If you can, disable the session DB-handler. It is known for this behave in regard with multiple parallel images uploads. Or, if you cannot switch to session handling via files, the only other alternative is to switch PW Version up to PW 3.0.21+ (?) not sure the correct version where DB-Sessionhandler was updated / corrected. Other possiblities are not there in your case, I believe.

Take a look at those: Mysql 5.7 changed the default value options for date fields.

@tpr I just want to say a big thank you! I'm back from holidays so I could actually update the module and it works fine so far. The new appearance of the normal Sticky Header (not the compact one) with the always show search field is my most favorite setting.The "dropdown" version of System Notifications is great improvement too. Just one issue I have: with the above mentioned normalSticky Header + always show search field setting I do not have access to the search field in narrow viewport, the search field simply disappears. All in all, you managed to improve the Reno Theme in such an extent that there is no more reason to prefer the classic admin theme to it.

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.

If you still want to go with the .htaccess route instead of Jumplinks, you might want to provide us some additional information. What I mean is that, for an example, /solutions/eventdirect should definitely redirect the user to http://www.mngdirect.com/eventdirect. Are you saying that this redirect doesn't happen at all? Another thing I find curious is the placement of these redirects in your .htaccess file: here you've got "RewriteEngine On" right after "Options +FollowSymlinks", but in the default .htaccess setup "RewriteEngine On" is placed much later in the file. Did you alter the .htaccess file and add *additional* "RewriteEngine On" row, or how did you end up with this setup? Which version of ProcessWire are you using, by the way?

The operating assumption here is that you are using Processwire, so yes, it is a factor. If this assumption is true, then you'd simply need to use the fantabulous Jumplinks module. And also it is curious that your target URLs do not have trailing slashes, which is the default for PW. If you have not changed the default behavior, then you'd be getting a 2nd unwanted 301 redirect to the trailing slash.

There are basically four different environments to talk about. TemplateFile TemplateFile is core class, which does include your template files, but does also power things like $page->render(), wireRenderFile(), wireIncludeFile() and others. This class will automatically make all API Variables available as local variables. Meaning all those included files can directly use $pages, $page, … . It won't work inside any functions defined in those files, because of the way PHP does scope variables. Classes extending Wire Every class, which is extending the Wire class will have access to API variables via $this->pages, $this->page, if the properties or __get() are not overwritten. Also there's $this->wire('pages'), which is less likely to be overwritten (even some core classes need to use $this->wire()). Anonymous functions There are some methods in the processwire code, which accept anonymous functions as parameters (e.g. WireCache). Those anonymous functions can retrieve api variables as parameters, even though I'm not sure how exactly this is working or if that's often used. Everywhere else Outside of wire classes, template files and special anonymous functions there's the wire() function, which is basically the same as $this->wire() in wire classes, but as a global function, which is accessable anywhere after pw is started. With PW 3.0 and multi-instance this is the option to avoid. Places, which technically are number 2, but it may not be apparent to everybody: Custom PHP code for fields like FieldtypePage or FieldtypeMarkup: As those PHP code is evaluated/run inside those (input)field classes there's (besides manually available local api variables) always the option to use $this->pages or $this->wire('pages'). All those template files included by the TemplateFile class: For the same reason as above there's not only $pages available in those template files, but also $this->pages, $this->wire('pages').

Jumplinks for ProcessWire Latest Release: 1.5.63 Composer: rockett/jumplinks ⚠️ NEW MAINTAINER NEEDED: Jumplinks is in need of a new maintainer, as I’m simply unable to commit to continued development. Jumplinks is an enhanced version of the original ProcessRedirects by Antti Peisa. The Process module manages your permanent and temporary redirects (we'll call these "jumplinks" from now on, unless in reference to redirects from another module), useful for when you're migrating over to ProcessWire from another system/platform. Each jumplink supports wildcards, shortening the time needed to create them. Unlike similar modules for other platforms, wildcards in Jumplinks are much easier to work with, as Regular Expressions are not fully exposed. Instead, parameters wrapped in curly braces are used - these are described in the documentation. As of version 1.5.0, Jumplinks requires at least ProcessWire 2.6.1 to run. Documentation View on GitLab Download via the Modules Directory Read the docs Features The most prominent features include: Basic jumplinks (from one fixed route to another) Parameter-based wildcards with "Smart" equivalents Mapping Collections (for converting ID-based routes to their named-equivalents without the need to create multiple jumplinks) Destination Selectors (for finding and redirecting to pages containing legacy location information) Timed Activation (activate and/or deactivate jumplinks at specific times) 404-Monitor (for creating jumplinks based on 404 hits) Additionally, the following features may come in handy: Stale jumplink management Legacy domain support for slow migrations An importer (from CSV or ProcessRedirects) Open Source Jumplinks is an open-source project, and is free to use. In fact, Jumplinks will always be open-source, and will always remain free to use. Forever. If you would like to support the development of Jumplinks, please consider making a small donation via PayPal.

The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2

Hello, I made this clone of the Ghost Blog System (http://ghost.org) for demo of the Wire Render Pattern as well as a multi language site and menu system. https://github.com/NinjasCL/pw-ghost As always MIT licence.

Thanks! Does it happen under 960px page width? AOS doesn't do anything there it's "desktop-only". Most of the (admin) style tweaks behave this way.

Looks okay to me. A couple of minor things that won't be related to your problem: $sanitizer->username is deprecated in favour of $sanitizer->pageName I don't see where you set the default state of $error, so you may get an undefined variable notice when an exception is not thrown. Things to try: log $username and $password before $session->login() to check that the variables are holding the correct information. can you login with this username and password at the PW admin login?

Thank so much, would have never have figured that out! I've disabled the DB Session handler for now, and is all working fine.

Sorry, I forgot about it. Another solution would be to stick with PW 2.7 and the (old) SessionHandler-DB, but uploading multiple images packed into a ZIP! (only one ZIP at a time) This I uses on a client side with (old) SessionDB-Handler since PW 2.5, (upgraded to 2.6, then to 2.7) for years now, and it works correct!

I would hook and save the PageTitle field. Seems like a reasonable option with the least effort.

@teppo Update: it appears to be PHP 7. If I downgrade to 5.6.22 the clock icons appear on the fields.

I would also go for the Jumplinks module. One great feature is that you can mass upload a CSV file with all the pages that you would like to redirect. After that you can check how often the old link has been redirected to the new location and perhaps remove the redirect when it isn't being used anymore.

Working, legend! It was the old Unpublished pages thing again (something that tripped me up when I first start learning PW), thanks again everything seems to be working and will be releasing deffered pages module soon. (wish the forum still made solved buttons)

status=unpublished or include=unpublished

For anyone interested, there will be a (german) introduction hangout today about what that slack channel / community is all about and a little bit of craft talk (even though pw is also quite well represented).

Yeah, just write something to the log in your method. I'm on mobile, so no example unforunately. You could even simply die(); the whole thing. Is your module autoloaded?

Hi I also stumbled across this problem. It looks like the new variable handling of php7 is responsible for that... I found a solution wich works on php 5.6 and 7. Just posted an github issue with explanation... https://github.com/adrianbj/TableCsvImportExport/issues/1 greetings, tom

Exactly. There is no question anymore. It works. Just wanted to share.

This is my most ambitious PW site yet: http://vroom.pt It's an auto ad portal specially designed towards professional dealers. Some highlights you can't really see just browsing the website: Custom CMS for dealers (screenshot); Auto generated, customizable website for each dealer (examples here and here); The dealer can choose between a dark or light theme, then set a tone color; More themes will be added in the future with completely different designs. Optimized search algorithm to keep speed reasonable even when searching through thousands of results.