Leaderboard

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!

Hey @Wanze! These aren't really issues, more general feedback, so I thought I'd post them here. I've been evaluating this module as a solution for handling metadata, and as such have finally had some time to actually dig into it's numerous features – and while I see a lot of interesting stuff here, there are a few things that could perhaps use some polishing, in my opinion ? So one thing that confused me initially was the use of word "inherit". I managed to miss the point about default values being set template level in README (which obviously was a major reason for my confusion... but to my defence: when evaluating a new module I like to do it without reading too much first, since that's how most regular users – as in clients – are going to be using it anyway), so I imagined that the values would be inherited from parent pages. (Seemed a bit weird obviously, but whatever.) Now that I've double-checked the docs and understand that those values are inherited from the template, I'm actually wondering if you might consider calling this something else – perhaps "default"? It would also be good to explain somehow (in context) what "inherit" means, and where the value is inherited from? Note: I get that anyone installing the module and having access to template settings should probably realise what this is all about, but I for one don't give clients access to template settings (I see that as the developers' territory). Thus "inherit" doesn't make much sense to them – and since it's not explained in the admin (and they're unlikely to figure out that the site is using SeoMaestro and dig out the modules README or this thread), it can indeed be quite confusing. -- Another source of confusion for me was the Sitemap feature, mainly because it didn't seem to do anything. Now, looking into the source code, I see that you're using file_put_contents() – so apparently the module expects write access to the site root? It might be a good idea to add a check to see if this really is the case. At least I assume that this was the problem – didn't see any errors, but in my case Apache or PHP never have write access to directories with executable code, so if the module did try to write in those directories, it must've failed. (Personally I like the "hook 404 page and serve fake files" approach more when it comes to things like this – it doesn't require write access, and tends to work better overall in different environments.) -- Just some initial observations – hope you don't mind poking around. You're doing great job with this module! ?

Try: // Get names of fields on the page that are tagged with "custom" $custom_field_names = $page->fields->find('tags=custom')->explode('name'); // Do something with the values of those fields foreach($custom_field_names as $custom_field_name) { echo $page->$custom_field_name; }

If this is about tenancy management I'd strongly suggest using ryan's dynamic roles module (with all the known fixes) as a base. I once started to make it more flexible, so that you don't need a group per tenant, but rather it would match keys (e.g. tenant name or id). I just never came far because of other priorities. It shouldn't be super hard to do.

In my current job we don't actually use MS Office, and it has never been a real issue. Google's cloud apps are quite good (even better than MS ones in some regards), LibreOffice works for a lot of stuff, etc. The last time I did use MS Office it was actually the cloud based version of O365, due to various issues with desktop MS apps on macOS. My understanding is that this should work for Linux users as well? Anyway, there are two things keeping me firmly in the Mac camp: the UX (which includes both hardware and software), and the app support. Latter has been particularly so for design stuff – Photoshop, Sketch, XD, etc. None of those (to my best knowledge) work on Linux, at least not without some sort of emulator or virtual machine (which imho would pretty much defeat the purpose of running Linux in the first place).

I discovered Wireframe on Sunday after exploring the GitHub repo for the ProcessWire Composer Installer project that you mentioned in the latest PW Weekly. The documentation you've written for Wireframe is just awesome ? - engaging, comprehensive and clear. I have a short question and a long question... Does it make sense to use Wireframe together with Markup Regions in any way, or would a developer choose Wireframe or Markup Regions but not both? The long question relates to what you said here: I take this to be a reference to the superiority of a MVC approach versus the "default" approach of mixing business logic and UI logic together in a PW template file. I'd like to hear more of your views on this because you didn't talk about it much in the documentation, probably because MVC and the separation of concerns is discussed in plenty of other places around the web. But I was wondering if you think a MVC approach is always the way to go, or if is something you would weigh up the pros and cons of taking into account the parameters of each specific project, e.g. the scale and complexity of the project, if a team will be working on the project, etc. Personally I use Markup Regions and don't use any separation of business logic and UI logic into different files or folders. From time to time I think about changing to an MVC approach because so many people seem to recommend it, but when I weigh it up I don't see enough advantage versus disadvantage for the kinds of projects I work on. But maybe I'm overlooking something so I'd appreciate your comments. The main benefits of MVC as I understand it are... 1. If you have a team of people working on a project, maybe with different skill sets (e.g. a front-end dev and a back-end dev), then it lets each person focus on the parts that matter to them. For example the front-end person can focus on the view file without having to see any business logic which might distract or even be unintelligible to them. This totally makes sense to me and if I worked as part of a team this by itself would make an MVC approach worthwhile. But in my case I do everything alone from start to finish - design, front-end, back-end. 2. The business logic doesn't "belong" in the same file as the markup - it's better to keep it separate and it makes it easier to update a site. This seems more contentious to me, and perhaps depends on how much business logic there is. If I have some variable that I'm using within the markup I find it very handy to have the definition/construction of that variable present alongside its usage in output. So I'm not left wondering "what was it that I put into $related_products?" and needing to navigate to some other file to find out. Now if there were heaps of business logic it might start to feel like clutter within the markup, but when I look at the template files for my projects in most cases there's actually very little business logic present. Maybe that's partly because PW is quite elegant in that you can do a lot with a few lines of code, and partly because most of my projects are not very complex. But even if I do have a lot of business logic I find that placing it at the top of the template file is no problem at all. If I need to work on it I'd rather just scroll up than open another file, and I can use my IDE to collapse any blocks of code that I don't need to focus on. Would you say that MVC is an approach that is more suited to complex projects rather than simple ones? Things like layouts and partials that are offered through Wireframe are cool, but those are also possible with Markup Regions (layout = _main.php) and built-in PW methods (partials = $files->render). I have no doubt that Wireframe is a powerful tool, but do you see it as being the right solution for all projects or just some projects?

http://bfy.tw/OPbk Please provide some more information what you have tried so far, what worked, what did not work, where exactly you need help, what is the challenge/goal and so on.

Sorry, I think you misunderstood my question. I asked for a solution to find field values of a page, based on a specific field tag and not pages.

Thanks! I already found $page->fields in the docs, but didn't reconise that I could use ->find('tags=custom').

Thats great for you. But still nothing in the documentation suggests that it´s obvious just because its a method of $page. It´s says the data is independent of the fields of the page and such lead me to belive i could call $page->meta() from any page and get the data back that i saved. Anyhow, this post is for the people who don´t think its obvious. We are all different. But thank you for your input Markus. have a nice day and happy coding.

Hello fellow PW devs! This is a short story from the server management trenches. These past couple of days trying to solve an unexpected problem: after DigitalOcean patched the droplets in NYC3 region last week, my client's droplet became almost useless and went down a couple of times. The droplet has 2GB RAM and was running Ubuntu 16.04 that was updated to kernel 4.4.0-116 after the patch. The server was provisioned using Forge (forge.laravel.com). After sshing into it, and running "top" I've noticed the cause: "php-fpm7.1" processes (3-5 instances) were spiking the CPU to 100%. This was very odd, as the CPU usually kept around 33% most of the time. The site uses ProCache and markupCache and was getting around 800-1000 visits/day last week. I checked everything on PW's side and nothing seemed out of place, so I went restarting PHP and Nginx but the problem continued. I checked access logs and no suspicious activity shown up. I upgraded PHP to 7.2 to see if anything will changed but the problem continued. My only guess after all that is that the droplet in question got screwed up somehow, because I didn't see any complaints on the web of other people getting the same problem on DO (But I confess that I did a quick Google search only). So in the end I decided to create a new droplet, now with 2 CPU cores and kept the 2GB (1 extra core and $5 cheaper ). Reinstalled PW there and pointed the floating IP to this new server. The installation went smooth but to one issue: error log started to show messages of MySQL showing "to many files" error when the users were searching. I've never encountered this message before, so after reading some StackOverflow posts, I changed mysql.services config file to remove its file limit (https://stackoverflow.com/a/36807137) Everything is normal now, but I think I'll never discover what truly happened. Anyone else had this kind of problem with MySQL before?

I think there is no way around this currently.