Leaderboard

I hope that you have had a great week! I’ve been working hard on finishing up the LoginRegisterPro module this week and actually have it ready. But I’ve been told I have to get off the computer in 20 minutes, so so I think I’ll wait till Monday to release it. But I do have the new info page (which is kind of like last week's blog post) and new documentation page now online. The documentation page in particular is pretty comprehensive. In last week’s post there was a form to request more info once it’s released, so if you are interested in this module and haven’t filled out that form, please do. That’s how I’ll be sending out the introduction coupon code this time around, for those that want it. There have also been some core updates this week, but it was just a few commits, so not enough to warrant a version bump today. That’s actually a good thing, as no major new issues turning up means one step closer to merging onto the master branch. There will be a new master version before this year is done! Thank you for reading and I hope that you all have a great Christmas and/or holiday week next week!

Hey folks! I've been a bit quiet here, but that's mostly because I've been busy building stuff with ProcessWire and Wireframe ? Just wanted to give a quick heads-up for a new feature called components that I'm currently testing (it's in the dev branch of the module already), in case anyone wants to comment on it before it gets merged to the master branch. Wireframe components are classes extending an abstract base class (\Wireframe\Component), and they can either render output directly by implementing the render() method, or they can be rendered using a separate Component View file. This is probably a familiar concept to most, but the general idea is that while partials ("dumb" files with no way to process params, and no clean way to separate code from markup) are enough if you just have some relatively static snippet that you need repeatedly, components add an extra layer where you can a) specify which params they accept, b) process those params, and c) include any additional "business logic" that should be triggered when the component is rendered. Here's a simplified example of how this comes together: /site/templates/components/Card.php (class for the Card component) <?php namespace Wireframe\Component; /** * Card component */ class Card extends \Wireframe\Component { /** * Constructor method * * @param \ProcessWire\Page $item Page related to current Card. */ public function __construct(\ProcessWire\Page $item) { // Pass properties to view $this->title = $item->title; $this->summary = $item->summary; $this->image = $item->get('image|hero_image'); } } /site/templates/components/Card/default.php (default view for the Card component) <?php namespace ProcessWire; ?> <div class="card"> <?php if ($image): ?> <img src="<?= $image->size(640, 480)->url ?>" alt="<?= $image->description ?>"> <?php endif; ?> <h3><?= $title ?></h3> <?php if ($summary): ?> <p><?= $summary ?></p> <?php endif; ?> </div> ... and for fetching and rendering the component, there's a little static helper in the Wireframe module class: <?php foreach ($cards as item): ?> <?= Wireframe::component('Card', [$item]) ?> <?php endforeach; ?> Note that Wireframe::component() actually returns an instance of the component class, not a string, but since \Wireframe\Component::__toString() calls \Wireframe\Component::render(), what we're doing here is essentially the same as echoing out the result of (new \Wireframe\Component\Card($card))->render() ? So, anyway, that's basically what I've been working on here. I'd be happy to hear if you have any comments on this addition – I haven't yet merged it to master since I'm still experimenting with it, and I'd like to avoid as many breaking changes in the master branch as I can. So far this has worked great for me, but to be honest my requirements have been pretty basic. Thoughts?

This is an example of something I do with Profields Table for replacing Twilio message and error codes with links to the entry in the logs on the Twilio site. You should be able to adapt to your needs. // link SID and error code columns in User message tables to the Twilio log entry $this->wire()->addHookAfter('InputfieldTable::render', function($event) { if(!in_array($event->object->name, array('received_messages', 'incoming_messages', 'queued_messages', 'undelivered_messages', 'failed_messages'))) return; $text = $event->return; if(preg_match_all("/<td>(S|M)M(.*?)<\/td>/", $text, $matches)) { foreach($matches[0] as $match) { $sid = str_replace(array('<td>', '</td>'), '', $match); $text = str_replace($match, '<td><a href="https://www.twilio.com/console/sms/logs/'.$sid.'">'.$sid.'</a></td>', $text); } } if(preg_match_all("/<td>([0-9]{1,})<\/td>/", $text, $matches)) { foreach($matches[0] as $match) { $errCode = str_replace(array('<td>', '</td>'), '', $match); $text = str_replace($match, '<td><a href="https://www.twilio.com/docs/api/errors/'.$errCode.'">'.$errCode.'</a></td>', $text); } } $event->return = $text; });

I just released v1.1.2 which has all the same features but removes dependency from MySQL >= 5.7.8 and fixes some minor issues. The module can now be used on any MySQL setup. You can update to or install from scratch the latest master version. If you run into problems, please report here or open an issue on github. Thank you.

I'm no expert but to me it looks like for sites not enduring transaction heavy traffic MyIsam is still a bit faster, eg: http://kedar.nitty-witty.com/blog/choosing-between-myisam-and-innodb-mysql-storage-engines also, corrupted tables are less problematic, eg: https://www.knownhost.com/wiki/developmental/mysql-myisam-innodb Anyways, thanks for all refactoring efforts!

That's not the same thing. They are basically the opposite of each other. The hook method above allows for a specified number of items in each sub-WireArray, with the number of resulting WireArrays not specified. WireArray::slices() allows for a specified number of sub-WireArrays, with the number of items in each sub-WireArray not specified. To illustrate:

OK, I have it: var orderActionStrings = config.orderActionStrings; $('.ResendInvoiceButton').on('click', function(e) { e.preventDefault(); var a_href = $(this).attr('href'); ProcessWire.confirm( orderActionStrings.confirm_resend_invoice, function() { // OK click window.location.href = a_href; } ); }); This will fully replace this var orderActionStrings = config.orderActionStrings; $('.ResendInvoiceButton').on('click', function() { return window.confirm(orderActionStrings.confirm_resend_invoice); }); with a nice vex dialog! @bernhard thank you for your forum thread! I would have never found this feature as it is completely undocumented (except in the sources).

Hey folks! I'm happy to finally introduce a project I've been working on for quite a while now: it's called Wireframe, and it is an output framework for ProcessWire. Note that I'm posting this in the module development area, maily because this project is still in rather early stage. I've built a couple of sites with it myself, and parts of the codebase have been powering some pretty big and complex sites for many years now, but this should still be considered a soft launch ? -- Long story short, Wireframe is a module that provides the "backbone" for building sites (and apps) with ProcessWire using an MVC (or perhaps MVVM... one of those three or four letter acronyms anyway) inspired methodology. You could say that it's an output strategy, but I prefer the term "output framework", since in my mind the word "strategy" means something less tangible. A way of doing things, rather than a tool that actually does things. Wireframe (the module) provides a basic implementation for some familiar MVC concepts, such as Controllers and a View layer – the latter of which consists of layouts, partials, and template-specific views. There's no "model" layer, since in this context ProcessWire is the model. As a module Wireframe is actually quite simple – not even nearly the biggest one I've built – but there's still quite a bit of stuff to "get", so I've put together a demo & documentation site for it at https://wireframe-framework.com/. In addition to the core module, I'm also working on a couple of site profiles based on it. My current idea is actually to keep the module very light-weight, and implement most of the "opinionated" stuff in site profiles and/or companion modules. For an example MarkupMenu (which I released a while ago) was developed as one of those "companion modules" when I needed a menu module to use on the site profiles. Currently there are two public site profiles based on Wireframe: site-wireframe-docs is the demo&docs site mentioned above, just with placeholder content replaced with placeholder content. It's not a particularly complex site, but I believe it's still a pretty nice way to dig into the Wireframe module. site-wireframe-boilerplate is a boilerplate (or starter) site profile based on the docs site. This is still very much a work in progress, but essentially I'm trying to build a flexible yet full-featured starter profile you can just grab and start building upon. There will be a proper build process for resources, it will include most of the basic features one tends to need from site to site, etc. -- Requirements and getting started: Wireframe can be installed just like any ProcessWire module. Just clone or download it to your site/modules/ directory and install. It doesn't, though, do a whole lot of stuff on itself – please check out the documentation site for a step-by-step guide on setting up the directory structure, adding the "bootstrap file", etc. You may find it easier to install one of the site profiles mentioned above, but note that this process involves the use of Composer. In the case of the site profiles you can install ProcessWire as usual and download or clone the site profile directory into your setup, but after that you should run "composer install" to get all the dependencies – including the Wireframe module – in place. Hard requirements for Wireframe are ProcessWire 3.0.112 and PHP 7.1+. The codebase is authored with current PHP versions in mind, and while running it on 7.0 may be possible, anything below that definitely won't work. A feature I added just today to the Wireframe module is that in case ProcessWire has write access to your site/templates/ directory, you can use the module settings screen to create the expected directories automatically. Currently that's all, and the module won't – for an example – create Controllers or layouts for you, so you should check out the site profiles for examples on these. (I'm probably going to include some additional helper features in the near future.) -- This project is loosely based on an earlier project called pw-mvc, i.e. the main concepts (such as Controllers and the View layer) are very similar. That being said, Wireframe is a major upgrade in terms of both functionality and architecture: namespaces and autoloader support are now baked in, the codebase requires PHP 7, Controllers are classes extending \Wireframe\Controller (instead of regular "flat" PHP files), implementation based on a module instead of a collection of drop-in files, etc. While Wireframe is indeed still in a relatively early stage (0.3.0 was launched today, in case version numbers matter) for the most part I'm happy with the way it works, and likely won't change it too drastically anytime soon – so feel free to give it a try, and if you do, please let me know how it went. I will continue building upon this project, and I am also constantly working on various side projects, such as the site profiles and a few unannounced helper modules. I should probably add that while Wireframe is not hard to use, it is more geared towards those interested in "software development" type methodology. With future updates to the module, the site profiles, and the docs I hope to lower the learning curve, but certain level of "developer focus" will remain. Although of course the optimal outcome would be if I could use this project to lure more folks towards that end of the spectrum... ? -- Please let me know what you think – and thanks in advance!

Hi everyone. I've just committed v2.0.0 of this module with some BREAKING CHANGES. The breaking change is the removal of the "Enable for API" option. After lots of discussion and testing with @Robin S's help we decided that it's best that this module doesn't handle renaming via the API - it's not really its intended purpose, but there are also too many complications when it comes to dealing with hooks that save pages. This has allowed me to simplify the module significantly as well as now all the renaming is done via JS which is more inline with how the PW core sets the page name when you initially title a page. This update also adds individual Exempt Roles settings for each of relevant settings, rather than the old overarching option. I have also done quite a bit of cleanup and refactoring, but all those should be taken of via the module's upgrade() method. That said, I still recommend taking a good look over the settings page to make sure it's still showing what you expect and that the module's behavior is still correct for your needs. Please let me know if you find any problems. Happy Holidays all!

I would recommend doing this on the front-end: when the close button is clicked, hide the box and set a cookie. Check the cookie on page load (with JavaScript) and only show the box if the cookie isn't set. This is all pretty simple, and you can likely find a pre-built solution with a bit of googling. If front-end implementation isn't, for whatever reason, possible, you can also also set the cookie with PHP (if you're running ProcessWire 3.0.141 dev or later, check out $input->cookie) or use $session to remember that the user has closed the box. This will, though, require that you pass the request to PHP first – for an example the "close button" could actually be a link to something like "/?close_the_box=1" which then triggers required PHP code in your home template, or you could perform this query with JavaScript when the button is clicked. Hope this helps a bit.

I think this is a great addition! I made something similar a while ago (called Widgets) but it wasn't as thorough, simple, or effective as your Component implementation. I look forward to trying it out ?

Well... did you actually read it? There are useful hints in there, starting at "IIS was not able to access the web.config file for the Web site or application. This can occur if the NTFS permissions are set incorrectly." And there are several suggestions under "Things you can try". Take a look here:

Done ?

@gebeer You might want to clean-up some of the copy-paste inline comments that shipped with the example code from your module's code ?

This is already integrated. Each country (most countries!) has its own locale data (currency symbol, tax rate, provincial/territorial taxes if applicable, tax names, decimal symbol, etc). Tax rates can be overridden per country (and per territory if applicable). This is a frontend issue which you will need to integrate yourself using ProcessWire $language API and your method of detecting customers location (taking into account the various pros and cons of each). This is about shipping zones. It is already built in but you will have to set up the zones yourself including: The shipping countries (and territories if applicable) Shipping rates in that zone, whether they are flat- or price- or quantity- or weight-based Whether you are using shipping classes (e.g. light goods, fragile products, hazardous, bulky, etc) As well as shipping methods (e.g. normal, express, next day, Post Office, etc). Specifying a maximum shipping fee (if you wish) as well as shipping handling fee (optional) Etc The above allow a lot of control straight out of the box. This is about a 3rd-party software. You will have to do the integration yourself using Padloper 2 API (for inventory). Probably not practical in your case, but please note that in Padloper 2 you can manually create an order (or using the API).

https://dockyard.com/blog/2019/12/19/lessons-learned-10-years-of-running-a-software-consultancy

Yes, in this example I was saving in the admin. Thanks.

Guys, just to give you an update: I still want and have to work on this module before I can release it on github. I am changing a big part of the rendering of the actions, so they work either in card or in table view. Sadly I hadn't much time in the past, because I changed my company to a GmbH, had to design a new logo and website texts, and all that legal stuff that comes with changing your company. And don't forget about my customers, who also want their work done. I hope to get some time in the next weeks, so maybe I can work after christmas on this, but no promises.

Now that PHP 7.4 is stable, I have updated the Tracy core to the latest version and also made a few other fixes to the module for PHP 7.4. Please let me know if you notice any problems. Note that this issue in the PW core (https://github.com/processwire/processwire-issues/issues/1041) currently breaks the RequestInfo panel on 7.4.

I don't want to derail this thread, but just want to say thanks so much for mentioning this. Coincidence or not? Just today someone on a client project mentioned SonarCube (which is basically the same, but installed locally, and also from the same company), and now I took a look at SonarLint, which can be added to IDEs as plugins. I will definitely try out their IntelliJ plugin. Judging from the SonarCloud results for WireFrame, it really sounds like a great tool. Sort of like ESLint, but on steroids :-) The estimated "time to fix" and references to rule (definitions) are a nice touch.