Leaderboard

Friends of mine just showed me their firebase setup. They have collections and documents and so on and they have the problem that they don't have a fool-proof way to manage those collections (user data of their app, like customers, partners etc). ProcessWire's admin is such a great way to structure such content quickly and easily, so I wonder if anybody of you has ever built something where ProcessWire and Firebase where talking to each other. I think it shouldn't be too hard to build a PW instance that makes it easy to manage firebase data. Only thing I'm wondering is the communication between the two systems. It's an early stage idea so I'd be happy to get some pointers or experiences. Thx! ?

Building lots of process modules? This snippet might be something for you (hit ctrl+shift+p and type "snippets" and create/edit php.json): And one for creating the execute methods. I'm almost always rendering forms in those methods, no standard html, so this makes me more efficient:

@bernhard You still rock ? Thanks for this tip, this is also possible for PHPStorm, snippets are called Live Templates there. This is a great timesaver.

I'm not 100% sure, (but think so), if you will get better support when posting this into a dedicated Twig Thread, if there is any. Unfortunately I don't know anything in regard of twig. But there are modules available for twig template engines and when posting there, it may reach more users of twig, if they have set notify for new posts in that thread.

Visual Studio Code for PW Devs This thread is a place for ProcessWire developers who use Visual Studio Code (aka VSC or Code) to share their experience, tips, frustrations , solutions, code snippets and generally discuss all things VSC. From Wikipedia:

Tailwind CSS Framework, a utility-first CSS framework for rapidly building custom designs This thread is a place for ProcessWire developers who use (or would like to use) Tailwind CSS to share their experience, tips, frustrations , solutions, code snippets and generally discuss all things tailwind. From the creators of Tailwind CSS Moderator note: the first few posts in this topic were split from this thread. ########################## Thanks, @apeisa! Yes, Tailwind is awesome! Responsive classes are a clever idea indeed, much easier to work with. The authors did an excellent job and keep improving it. Some people may feel a little sceptical, but I fell in love with it the moment I built my first project. Although nowadays I work alone, I believe that Tailwind makes work between a frontend and backend developers much easier because it makes the HTML more declarative and you can grasp what the classes mean in a glimpse.

You see that there is an error in strings.php: The view variable is not set, and you try to modify a property of an object that isn't there. The view variable is available after the TemplateEngineFactory module is loaded. And make sure that in the settings of TemplateEngineFactory "API variable to interact with the view" is set to "view". So maybe you have to change the load order when strings.php is included.

Wow, just found their resources page ? Might be worth a look for someone else too: https://tailwindcss.com/resources

Hello @BitPoet I have a simple web magazine / News magazine project in hand, I have done the design work and was doing some PW basic setup. It seems to me your blog would fit with my requirement, I shall try, extend it and will give you the feedback soon. thank you

Has anyone tried https://lando.dev? I've just found it. (I need MariaDB and not MySQL.) *** But the hardware requirements are quite high... https://docs.lando.dev/basics/installation.html#hardware-requirements *** And are some of you happy with Devilbox or Laravel Homestead, for example? (Preferably on Linux.) Are they too complex to install or use, or do they take up too much space, for instance? Is it worth it? What are your opinions? Thanks in advance! NB: For the last projects, I developed online. I will normally soon invest in a new computer for several reasons, one of them - not the most important - being the space left.

Additional side note: It seems my post confused a few of us. Therefore a few more details about my workflow. Clarification The above mentioned workflow does not involve ProcessWire. This workflow applies only to the part of creating HTML, CSS and JS for a project in its static version. You can call it a prototype, a template library, a loose collection of web-related documents, or however. This step is done way before I fire up ProcessWire (or give the files to another developer in case of Typo3, the CMS we don't name here or whatever). Each time I start a new client project for a website I already have in some kind a full-featured, defined and approved design - either made in Adobe PS, IS, XD, Sketch, Figma or any tool you can imagine - most of the time it's not my part to be honest. I can then work out each and every detail, plan out the things that were needed, look for repetitive elements and their modifications and states. The result of that (my work) needs to get an approval by the designer and the client - afterwards I create a new ProcessWire instance and migrate everything in template files and smaller bits I will need later on. With this overall approach I have had enough time to know how to structure the data and content in ProcessWire which makes things in it super easy and super fast most of the time. Hope this helps.

Hope you guys are having a great week. I'll keep this week's update short since everything I'm working on is in-progress rather than ready to post. But I can tell you about a few things you'll likely see in next week's post: First is that I've got multi-page/paginated form support just about ready to release in FormBuilder. What this means is that you can take forms (especially long forms) and break them up into multiple paginations. This makes for multi-part forms that are more digestible and easy to use for users. The end of each pagination has "Next" and "Prev" buttons for navigation between them. FormBuilder validates each pagination independently as it is submitted so that any errors are taken care of as the user proceeds rather than all at the end. And these are true paginated forms, rather than a JS manipulation of existing forms. More on this next week. I'm also working here on a new Inputfield module called InputfieldToggle. It's an alternative to the core InputfieldCheckbox and the intention here is to make it a selectable alternative for FieldtypeCheckbox fields. Unlike InputfieldCheckbox, it is presented as two radio buttons for "on" and "off" states. (It's also possible to have a "no selection" state distinct from the "no" state, where supported). It comes predefined with several toggle types (Yes/No, On/Off, True/False, Enabled/Disabled), along with the ability to specify your own (multi-language too of course). Like a checkbox, because it is a toggle, it holds a value of either true (1) or false (0). There is also null for no selection. While this is a relatively simple Inputfield, it answers a common need (at least in my experience) and often can provide a better experience than a standard checkbox, depending on the input need. Not to mention, it's a lot more efficient than using an Options or Page field to accomplish the same thing. In addition to sites and apps running in ProcessWire, I think this particular Inputfield has a lot of potential use in the core and its administrative forms, so I might include it in the core, though not yet certain. I'm already using it quite a bit in forms I'm developing for clients in FormBuilder, where in many cases I find it a better fit than InputfieldCheckbox. Lastly, there are some nice UI enhancements just about ready for manipulating column widths of fields in ProcessWire. It makes it a much simpler and quicker job than it currently is, so I'll have more on that next week too. Have a great weekend!

Paginated forms: Looking > Forward > To > This > Alot. Thank-you!

A RepeaterPageArray is a type of WireArray so it should work as is. And it's working for me so double-check your code (e.g. invisible characters from forum copy/paste).

You will need: ProcessWire (of course) ProcessWire ProCache ProcessWire Modules as you like and need Netlify Account (in my case, you can use any other hosting or Github pages) Git Account (Gihub, Gitlab, Bitbucket) ScreamingFrog (free version should fit most needs) Things to keep in mind FormBuilder will not work (out of the box) 40x/50x must be defined separately Redirects must be defined separately Module-based functionality will not work GDPR/Opt-in/Cookie consent must be added differently Avoid using core/module files (UIKIT, jQuery, CSS, etc.) Where to save files and how to address them Most content and design related files can be saved in ProcessWire itself. Logos, favicon, trust icons and whatsoever. Some files can't be stored in ProcessWire - or shouldn't be stored in it - fonts and sitemaps (XML) in my case. While developing the overall site always use relative paths and URLs. Fonts and other assets need to be addressed by their web-root-based path (/site/templates/myassets/font.ttf and so on). Internal linking should be relative as well. Otherwise you have to change those link URLs manually which is PITA. Which files to copy and where you find them As we use ProcessWire we want and should use everything we can to make our webdev life easier here. Let ProcessWire and some modules do the work while harvesting the results for our benefits. While ProCache takes care of generating minified CSS and JS, SEO Maestro generates a nice and handy sitemap.xml. Depending of your installed modules you want to (at least) double check the output and results in your static site. As already mentioned FormBuilder and Simple Contact Form will not work, 404 management and redirects by the awesome Jumplinks modules will not work, too. Instead you have to create your very own .htaccess file with all redirects and error documents. Other modules like MenuBuilder, SEO Maestro and some other modules do a pretty good job even in your static site as their benefits result in already rendered HTML/pages. Autolinks, Automatically link page titles and Share buttons are some modules that will work as well. While it didn't work for me it may work for you - the Cookie Management Banner module. I had some issues and decided to install and use Cookie Consent manually. The Workflow First of all build your site. Make it perfect. Do whatever you or the client wants or needs. Whenever possible look into your rendered HTML and cached pages. Take a closer look at all the URLs and paths. It's already a good idea to run ScreamingFrog and find out if there are any files missing, links broken or pages missing. When everything is done, clear all cached files, all minified JS and CSS. Start a ScreamingFrog session and let it run. It will visit each and every page on your site it can find. Hidden pages, orphaned pages and of course drafts and pages behind JS-links will not be found and therefore cached by ProCache. Look into /site/assets/ProCache-XXX/ and /site/assets/pwpc/ now and double check that there are your pages and JS/CSS files. You will need those afterwards. If everything is fine you have to copy things around now. The Setup - folders and structure In my case the easiest way to go was setting up two local sites - one with ProcessWire and another one with the static files, assets and other things I needed. In the examples below only relevant parts are listed. project.pw.test (ProcessWire) /sitemap.xml (Generated by SEO Maestro) /site/assets/files/ (copy the whole path) /site/assets/pwpc/ (copy the whole path) /site/assets/ProCache-XXX/* (copy only the content of this folder - all files and folders) /site/templates/myassets/ (copy the whole path) project.sv.test (Static version) .htaccess (for redirects and 40x/50x error pages) 40x.html 50x.html /sitemap.xml /site/assets/files/ /site/assets/pwpc/ /site/templates/myassets/ all files and folders from /site/assets/ProCache-XXX/ As you can see there are only a few things to copy. When you're done with copying these files to the static version of your project, open it up in your browser. Check for missing files and test it. Let ScreamingFrog do the most work and check for any kinds of errors. Fix them in your ProcessWire-site and copy and test again. Check your 404s, your redirects and everything else you would normaly test. Create checkafterupdate.txt and write down whatever went wrong in your first try. This will be a great checklist later. The Final Step As everything is copied now and at its correct place you can upload it to your host. In my case the static version is a private git repository on github.com. I can commit and push my changes there and Netlify takes care of publishing the new version - most of the time within seconds. The benefit of using git - compared to S/FTP - you always have some kind of control if something brakes and you have to revert and check changes. In my case it's Netlify but you can use Github pages or any other hosting solution you want/the client pays for. Be careful with GDPR-related things as DPAs. You have to have them in most cases - Netlify did a great job here and I found everything I needed, while Github disqualified itself back then due to missing documents and kind of a sluggish support. Questions? Ask.

https://blog.theodo.com/2019/07/vscode-php-development/

Not sure if anybody is already using it... I'm using it every day and I'm extending the api from time to time. Today I added a setFieldOrder() method. Now it is quite easy to change the order of fields and set new column widths: // adjust field widths $rm->setFieldData('project', ['columnWidth'=>33], 'rockinvoice'); $rm->setFieldData('inv_date', ['columnWidth'=>33], 'rockinvoice'); $rm->setFieldData('type', ['columnWidth'=>34], 'rockinvoice'); $rm->setFieldData('invoicetomarkup', ['columnWidth'=>100], 'rockinvoice'); $rm->setFieldData('due', ['columnWidth'=>25], 'rockinvoice'); $rm->setFieldData('paid', ['columnWidth'=>25], 'rockinvoice'); $rm->setFieldData('num', ['columnWidth'=>25], 'rockinvoice'); $rm->setFieldData('sap', ['columnWidth'=>25], 'rockinvoice'); $rm->setFieldOrder([ 'type', 'invoicetomarkup', 'due', 'paid', 'num', 'sap', ], 'rockinvoice');

An update to the hook in the first post for PW v3.0.117 or greater. // Add a new 'chunk' method to WireArray, the equivalent of PHP's array_chunk $wire->addHookMethod('WireArray::chunk', function(HookEvent $event) { /* @var WireArray $wire_array */ $wire_array = $event->object; $size = $event->arguments(0); if( !((int) $size > 0) ) throw new WireException('WireArray::chunk requires an integer $size argument greater than zero'); $chunks = new WireArray(); for($n = 0; $n < count($wire_array); $n += $size) { $chunks->add($wire_array->slice($n, $size)); } $event->return = $chunks; }); This returns the chunks as a WireArray so you have the option of using WireArray methods. So if needed you could do something like: $items = $pages->find("template=foo"); $chunks = $items->chunk(5); $three_random_chunks = $chunks->find("limit=3, sort=random");

Just as a heads up if someone needs database testing: I am trying a different approach at the moment: I simply added a database configuration to the config.php which is used if PW is called from PHPUnit. in config.php if(isset($_ENV['UNITTEST']) && $_ENV['UNITTEST'] == true) { $config->dbHost = 'localhost'; $config->dbName = 'db-test'; $config->dbUser = '...'; $config->dbPass = '...'; $config->dbPort = '3306'; $config->httpHosts = array('localhost'); } and my PHPUnit configuration.xml looks like this <phpunit ... some settings here ... > <php> <env name="UNITTEST" value="true" /> </php> </phpunit> maybe this will save someone a headache in the future

Global variables are against the principle of object oriented programming. LostKobrakai made a good point. One could always write something like this: $_GLOBALS['page'] = "I'm a string page"; and your code breaks... If you're in a class derived from wire, the cleanest way to get the API variables is like this: $this->wire('page'); $this->wire('sanitizer'); // They could also be accessed directly, but then you're not 100% sure if the member is overwritten with something else $this->page $this->sanitizer The global wire function is there to access the API variables in (global) functions, or static methods when you're in a class. You don't even need to reassign them to local scoped variables, just use them like so: echo wire('page')->id; ... or if you really want local variables with a one liner, write a little wrapper like this: function getApiVars() { return array( wire('page'), wire('pages'), wire('sanitizer'), ); } // And then list($page, $pages, $sanitizer) = getApiVars(); Or another possibility would be to inject them into your class/method, if you don't subclass Wire. Cheers