Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/14/2019 in all areas

  1. No blog post this week because I don’t have anything new or interesting to write about just yet (unless you like to hear about repairing fridges and clothes dryers). But I’ve been focused primarily on completing the FormBuilder updates that I mentioned in last week’s blog post, and it’s looking very good, though I’ve still got a little further to go with it. When it comes to multi-page forms, I’m trying to cover all of the exceptional cases where sessions expire, cookies clear, etc., and want to make sure a form-in-progress continues to work through all these situations. Multi-page forms can be potentially long and people can invest lots of time in them (relative to regular forms), so trying to make it all as resilient as possible. This takes lots of time developing and testing, so that’s what I’ve been doing. I’ll be doing some of that next week too, though also have been planning to dig back into the core issues repo and start working through some of those in preparation for a new master version this Fall. Hope you all have a great weekend!
    8 points
  2. Well... there is enough space in the forums for a DIY section. ?
    5 points
  3. One of my client's website is running on Nginx : https://ricardo-vargas.com It works, but I think a better approach in most cases is to run Nginx as a reversed proxy with Apache serving the files, like I did for my other client: https://www.brightline.org. You get the benefits of easier configuration and a better performance (compared to only run Apache).
    4 points
  4. Hey folks! I've been a bit quiet here about Wireframe, but the thing is that I've finally got a couple of "real sites" (as in not my own projects) to implement it on, and that has brought up some new requirements and a few issues. I haven't had the time to dig into a whole lot of really new stuff (components and such), but I have made a lot of other updates to the framework. As such, Wireframe 0.6 was released late yesterday. (A release on Friday the 13th, consisting of a total of 13 commits – not being superstitious here.) I've been updating the docs at wireframe-framework.com as well, but some parts remain a bit outdated. A lot of what happened in this version doesn't really affect the use of Wireframe, but some things do – and one change may even break some existing implementations: It used to be possible to set the view file or layout from Controller with $this->view->layout = "some-layout" or $this->view->view = "json". This has been deprecated and removed in favour of a setter/getter API: $this->view->setLayout("some-layout") and $this->view->setView("json"), and getLayout() / getView() for reading the value. In addition to some obvious benefits from type hinting etc. this also makes it harder to accidentally change something when you thought you were just passing a variable to the View ? There are now three ways to perform actions and pass data from a Controller to the View: Controller::init() (triggered as soon as the Controller class is loaded), public methods (which are made accessible in the View as $this->method_name), and a new addition Controller::render() (called right before the page is rendered). In most cases where one might've used the init() method before, render() is a better choice, as there's less chance that code will get executed "unnecessarily". In addition to existing Page::layout() and Page::view() methods there are now specific setters/getters: Page::setLayout("layout-name"), Page::getLayout(), etc. Original "unified setter+getter" methods may actually get removed at some point, as they're often ambiguous and make code arguably less readable. Quite a few other changes as well, some of which improve performance and others that make the API more polished. Some bug fixes too, though those mostly apply to what I'd consider "border cases" ? Here's the full changelog for Wireframe 0.6.0: ### Added - New Page methods Page::getLayout(), Page::setLayout(), Page::getView(), and Page::setView(). - New Controller::render() method, executed right before a page is actually rendered. - New ViewData class for storing (internal) data required by the View class. - New getter/setter methods for ViewData properties for the View class. - New method Wireframe::getConfig() for getting current config settings. - New method ViewPlaceholders::has() for checking if a placeholder has already been populated. ### Changed - Various View-related features moved from Wireframe module and ViewPlaceholders class to the View class. - Removed access to local get* and set* methods via the PHP's magic setter method __set() and getter method __get() in the View class. - Redirect feature no longer fails if provided with a WireArray data type; in these cases the first item is used as the redirect target. - Improvements to PHPDoc comments. ### Fixed - An issue with Config class where the "all directories exist" message was sometimes displayed unintentionally. - An issue where View Placeholder values might've been overwritten because existence of earlier value was checked inproperly. - An issue where empty / null view file would be automatically replaced with value "default". On a related note, for this version I decided to give sonarcloud a try. For those who don't know it, it's a sort of a code quality inspector, and it's free for public projects. It didn't have a whole lot to complain about at this point, but it's good to have some sort of validation in place just in case. I will also be digging deeper into reported "code smells", as some of them definitely make sense to me ?
    4 points
  5. In the last few weeks... or almost months... I worked on a project for a restaurant. Sad to say that the company behind the restaurant went out of business before the project could be finished - or was paid or the website ever saw the light of day. As there is kind of a lot of work in it... but yet a lot of customization... I decided to create a site profile of it and make it public as ProcessWire Barebone Site Profile. Right now I'm stripping out every client detail and finish some functions and details that were planned a few weeks back so you can build right on top of it, if you like or want. Maybe it's only a playground for someone or an inspiration for how to f**k up data-mangement... but hey... better than a ZIP file on a backup drive. ? As the project was and is super tailor-made to that client, it may not work for a lot of restaurants out there, but nonetheless I don't want miss the opportunity to offer a foundation for upcoming restaurant projects you may face. The project had a huge focus on dishes, beer and wine variations so those templates are kind of feature-rich. You might want to rip out some of it as most restaurants don't focus that much on those details. Important details I want to be honest and clear about: this profile does NOT include a highly polished and usable frontend as the design is paid and therefore can't be made public the frontend will be a collection of re-usable snippets to show every possible detail of each page, item and whatever the whole site profile will be without any support - future updates aren't planned right now the site profile will be released in single-language setup only (english) existing translations (as seen in parts of the screenshots) will be changed to english existing data, for example dishes, will be replaced with demo content if you, one of your clients or anyone else wants to use this profile - feel free to do so Pro Modules were already stripped out of it only public modules were used and are included with the profile itself the full module list will soon be published on Github the full README will soon be published on Github the full LICENSE will soon be published on Github So... yes... that's just a short preview of an upcoming site profile. As mentioned before, the site profile will most likely never ever receive any future updates, so it will be available on Github only. It's not planned to publish this as a full featured site profile, yet. More details, screenshots and the site profile itself (of course) will be available soon. Questions? Please feel free to ask. Github Repository: https://github.com/webmanufaktur/pwbrestaurant
    3 points
  6. 3 points
  7. I may have missed some of the points made here (sorry in advance), but regarding links opening in new tab/window: please keep in mind that this is a problem from accessibility point of view. For typical desktop users with decent eye sight etc. this is usually not a problem – and in fact it may be nice in some cases that a link automatically opens in a new tab – but for most screen readers (apps, that is – and thus their users as well) it's a real problem. From what I've heard/read, it can entirely mess up their understanding of the context. WCAG advises that if you're about to open a link in a new window, you should provide a clear signal that this is going to happen. This can, for an example, be a note at the end of the link text: "(opens in a new window)". If you care about accessibility, think twice before you use target="_blank". And for those cases where the client requests this, be sure to inform them that it will likely cause issues for some users. If the client still wants to go with it then by all means do it, but I've found this argument to resonate quite well with most sensible people ?
    2 points
  8. Pushed a fix for RockMarkup2 and related modules (RockTabulator) not working in subdir installations. RockFinder2 was also affected because of the wrong api endpoint url.
    2 points
  9. 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!
    1 point
  10. @teppo's argument here is solid and I thought... cool... just add some details to those links with CSS-magic: a[target=_blank]:after { content: " (opens in a new window)"; } BUT... not all screenreaders support that feature... all I found was kind of a mixed result. https://www.powermapper.com/tests/screen-readers/content/css-generated-content/ Just in case for those who had a similar idea. ?
    1 point
  11. Maybe I will have one in a week or few days, as I just yesterday uploaded a new project to a custom stage, where the customer uses an own server where I could configure apache for PW, but nginx seems to be in front of it as a load-balancer. I'm not sure how this works, as I had no time for looking around or asking, but maybe this is a similar setup as Sergio mentioned? (When I reloaded the apache service during the installation setup and I hit F5 to early in the browser, I got a nginx message "Bad Gateway"). The site will go live next week, I think.
    1 point
  12. I had some weird symbols in that file where the base64 encoded string was. No idea where they came from, but I will only investigate if the problem occurs again. Thx for your help!
    1 point
  13. @wbmnfktr Thank you, gleaned a lead from that old thread. Everyone; Still interested in seeing live PW sites running on Nginx, so please post if you know of any.
    1 point
  14. Not really but... https://timmehosting.de/processwire-hosting-auf-nginx Those were my only links to this topic. I remember a more packed thread but can't find it. ?
    1 point
  15. I've encountered users who don't even know what a tab is, and are confused when they cannot get back to the site they were on before by just hitting the back button! It's no use keeping your site up in the background if your users don't know how to get back to it ? So on principle I agree with @adrian on this, but our clients still keep asking for target="_blank", so that's that.
    1 point
  16. The easiest answer: you upgraded your local environment a few weeks ago. The more complicated answer: well... yes... don't know. Never had this kind of issue with ProcessWire itself.
    1 point
  17. Keep in mind that these two lines do exactly the same thing, so you only need one of them.
    1 point
  18. Because at this point, $notes is only a string. $dude->notes returns the contents of the field notes, not the field itself. Why do you need to assign the field to another variable? In most cases this should be enough. $dude->notes = "He's a dude"; $dude->set('notes',"He's a dude"); $dude->save(); //or $dude->setAndSave('notes',"He's a dude");
    1 point
  19. As threatened in Ryan's announcement for 3.0.139, I built a little module for sliding toggles as a replacement for checkboxes. Styling of the input is CSS3 only (with all the usual caveats about older browsers), no JS necessary, and may still be a bit "rough around the edges", so to speak, since I didn't have much time for testing on different devices or brushing things up enough so I'd feel comfortable pushing it to the module directory. But here's the link to the GitHub repo for now: InputfieldSlideToggle Fieldtype and Inputfield that implements smartphone-style toggles as replacement for checkbox inputs. The visualization is CSS-only, no additional JS necessary. Status Beta, use with caution Features / Field Settings Size You can render the toggles in four different sizes: small, medium, large and extra large. Off Color Currently, "unchecked" toggles can be displayed either in grey (default) or red. On Color "Checked" toggles can be rendered in one of these colors: blue (default), black, green, grey, orange or red. Screenshots Some examples with checkbox label View all Size and Color Combinations Small toggles Medium toggles Big toggles Extra big toggles
    1 point
  20. Hi @Hardoman I post you a code example below that works for me since ages and also with recent PW versions. It includes watermarking too! It is called in a custom module and the event is >before "InputfieldFile::fileAdded" <, but you can call it in ready.php too. Hopefully it is of help for you. Otherwise please ask further. :) public function importImage($event) { $inputfield = $event->object; // handle to the image field if(!$inputfield instanceof InputfieldImage) { // we need an images field, not a file field return; // early return } if(version_compare(wire('config')->version, '2.8.0', '<')) { $p = $inputfield->value['page']; // get the page, PW < 2.8 } else { $p = $inputfield->attributes['value']->page; // get the page, PW >= 2.8 | 3.0 (or only from 3.0.17+ ??) } if('images' != $inputfield->name) return; // we assume a field with name: images if('album' != $p->template) return; // don't do it on other pages than archive album $image = $event->argumentsByName('pagefile'); // get the image // prebuild variations // AdminThumb $image->height(260); // AlbumThumbnail $portrait = $image->height > $image->width; $w = 228; if($portrait) { $w1 = intval($w); $h1 = intval(($w1 / 3 * 4) + 38); } else { $w1 = intval($w); $h1 = intval(($w1 / 3 * 2)); } $image->crop("width=$w1, height=$h1"); // Slick-Slideshow $wmPng = $this->pages->get('id=13967')->getUnformatted('watermark')->first()->width(403); // sharpening added, quality from 80 to 90 $master = $image->contain('width=1000, height=700, quality=100, sharpening=none'); $master = $master->pim2Load('full', false)->watermarkLogo($wmPng)->setQuality(100)->setUpscaling(true)->setSharpening('none')->pimSave(); $sizeArray = array(array(448, 336), array(678, 506), array(908, 676)); foreach($sizeArray as $sizes) { $master->size($sizes[0], $sizes[1], array('upscaling'=>false, 'cropping'=>false, 'quality'=>90, 'sharpening'=>'soft')); } // sharpening added, quality from 80 to 90 // prebuild variations // check / import IPTC data $additionalInfo = array(); $info = @getimagesize($image->filename, $additionalInfo); if($info !== false && is_array($additionalInfo) && isset($additionalInfo['APP13'])) { $iptc = iptcparse($additionalInfo["APP13"]); if(is_array($iptc) && isset($iptc["2#025"]) && is_array($iptc["2#025"]) && count($iptc["2#025"])>0) { $tmp = $iptc["2#025"]; $tags = array(); foreach($tmp as $k=>$v) { if(empty($v)) continue; $tags[] = jhpTextConversion(trim(strtolower($v))); } $p->images->trackChange('tags'); // prepare page to keep track for changes $image->tags = implode(', ', $tags); $p->save('images'); // save the page } } // check / import IPTC data }
    1 point
  21. I know I am getting OT, but I almost never use target="_blank" anymore. Here are a few thoughts: https://css-tricks.com/use-target_blank/ I think the key thing for me is that it's really hard to prevent opening a new tab when it is used, but it's really easy for the user to choose to open in a new tab if they want, so my rule is that unless the user will lose unsaved form data as a result of opening a link in the same tab, I never force a new tab.
    1 point
  22. Thx @kongondo I'm also really loving it already. RockFinder1 felt complex in comparison and every added feature added more complexity to id. Now using the queryselector syntax things got a LOT easier and therefore a lot more solid, eg https://github.com/BernhardBaumrock/RockFinder2/commit/6ca0937a499259afe46745ef4cce4486fdc9443d
    1 point
  23. ?? Just kidding...I'm loving this module and the improvements! Great work :-).
    1 point
  24. Just added support to hide columns in the final output. Before I've always hidden those columns via JavaScript in the final table, but if you don't need them, why not removing them from the result before transmitting them to the client? Now it is as simple as that - and the example also shows the new concept for single-page-reference joins which I really enjoy using as it is so much clearer than in RockFinder1: $rf = new RockFinder2(); $rf->find('template=husband'); $rf->addColumns(['title', 'wife']); // wife is a single page reference // find all wifes $wives = new RockFinder2(); $wives->find("template=wife"); $wives->addColumns(['title']); $rf->addJoin($wives, 'wife'); Result so far: id | title | wife | wife:title --------------------------------- 11 | John | 22 | Sue Hide the wife column (the page id of wife pagefield): $rf->hideColumns(['wife']); id | title | wife:title -------------------------- 11 | John | Sue ?
    1 point
  25. Here's a basic example of how you could save files to a PW page via a front-end page using tus-php and Uppy. 1. Install tus-php via Composer. 2. Create a PW template that will provide the tus-php server endpoint - in this example the template is named "uppy". In the template Files tab, disable any automatically appended template file. In the template URLs tab, allow URL segments. If using Tracy Debugger, disable the debug bar in the front-end for this template because we don't want any output from Tracy being included in the response. The contents of the uppy.php template file: <?php namespace ProcessWire; // Create PW temp directory $td = $files->tempDir('uppy'); $td_path = (string) $td; // Create TusPhp server $server = new \TusPhp\Tus\Server(); // Set path to endpoint - no trailing slash here $server->setApiPath('/uppy'); // Set upload directory $server->setUploadDir($td_path); // Listener function for when an upload is completed $server->event()->addListener('tus-server.upload.complete', function(\TusPhp\Events\TusEvent $event) { // Get path of uploaded file $file_path = $event->getFile()->getFilePath(); // Add uploaded file to "files" field on Home page $p = wire('pages')->get(1); $p->of(false); $p->files->add($file_path); $p->save('files'); }); // Send response $response = $server->serve(); $response->send(); // Exit from current PHP process // Could probably use PW halt here as an alternative // return $this->halt(); exit(0); 3. Create a page using the template - in this example the page is at url http://1testing.oo/uppy/ 4. Add the Uppy assets, JS and markup to the template of the front-end page that you will upload files from. Markup Regions are used in this example. <pw-region id="scripts"> <script src="https://transloadit.edgly.net/releases/uppy/v1.4.0/uppy.min.js"></script> <script> const uppy = Uppy.Core({debug: true, autoProceed: false}) .use(Uppy.Dashboard, {target: '#uppy-box', inline: true}) .use(Uppy.Tus, {endpoint: 'http://1testing.oo/uppy/', limit:10}); </script> </pw-region><!--#scripts--> <pw-region id="stylesheets"> <link href="https://transloadit.edgly.net/releases/uppy/v1.4.0/uppy.min.css" rel="stylesheet"> </pw-region><!--#stylesheets--> <div id="body"> <div id="uppy-box"></div> </div><!--#body--> 5. Upload files via the front-end and see that they are added to the "files" field on the Home page.
    1 point
  26. https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ After reading this article highlighting the utility-first approach, a couple of things popped into my mind: This utility-first approach is mainly for large frameworks and/or for pre-made high-level component libraries where spending the time on all the extra work this approach introduces is worth it. For the frontend of brochure sites and even for classic retail webshops strictly sticking to this approach can be overkill and limiting in terms of "custom design", even though it is supposed to be able to deliver some sort of freedom in customization. If there is only one or two developers working on a not so big website, the advantages of this atomic utility-first approach fade away. My issues with this atomic style utility-first approach: - Memorizing the classes takes a lot of time as one has to learn a brand new language, translating a lot, eg: .flex-no-wrap means flex-wrap: nowrap; .flex-wrap-reverse means flex-wrap: wrap-reverse; .min-h-full means min-height: 100%; .min-h-screen means min-height: 100vh; And the list goes on... One has to spend quite a lot of time using the library in order to learn all this mapping. - Even though the CSS library is there, one has to start from scratch in terms of implementing "building blocks"/"components" for the site. Not having pre-made high-level components means that there is no help in this regard, it's very much like building the frontend based on SASS/LESS only (except for the utilities out-of-the-box, of course, but still...) - The approach of limiting text sizes, colors and similar to a few can be limiting for custom frontend design. By only using statistics to judge a particular design is short-sighted, I think. The Author lists some stats on popular massive sites out there, listing data like: Stripe: 189 text colors, 90 background colors, 35 font sizes purely based on some simple counting of the number of property values being used. By not knowing why those colors are used, stats do not mean too much, see for example: https://stripe.com/blog/connect-front-end-experience Being armed with some experience in working with colors one knows that – for example – bright text on dark background looks thinner than dark text on bright background and for this reason the trick of making bright text on dark background just a tiny bit brighter than its counterpart on bright background can be used to make text more readable. Also, properly matching colors is not always possible by picking colors form a small color palette, as our brain can observe them differently depending on the context. I understand that using hundreds of colors is most probably unnecessary, but relying on a fixed number of a few dozen can be limiting at times. The Author also states: "I don't think you should build things out of utilities only." and I agree ? For small and mid-range frontend projects I think UIkit 3 is a better choice as it provides high-level components based on low-level ones which can be mixed in lots of clever ways. I usually add the BEM-like approach to my code too, so that any deviation from the otherwise LESS customized UIkit can be applied in a maintainable manner.
    1 point
  27. Hey folks – a quick update: Wireframe 0.5.0 was released couple of days ago. Compared to 0.4.x this version mainly fixes bugs and improves performance – nothing particularly major, but if you're using Wireframe, it's a recommended update. On a loosely related note, Tracy Debugger has been really helpful in figuring things out, identifying bottlenecks, etc. Brilliant module ?
    1 point
  28. Hey everyone searching for this topic — if you're using Let's Encrypt with URL validation, don't forget to replace the part blocking dotfiles location ~ /\. { deny all; } With block denying everything BUT .well-known location ~ /\.(?!well-known).* { deny all; }
    1 point
  29. Nginx ? Why not take the overengineering to the next level and compile PW to c++
    0 points
×
×
  • Create New...