teppo

Two distinct points of view: Majority of the sites I work with require some sort of public API. This may be for local JavaScript, or perhaps I need to expose (as raw data or pre-rendered views) content to an external service. With this in mind I've been working on a built-in API for the Wireframe module and I've also got something similar planned for SearchEngine. In WordPress, plugins can inject their own custom endpoints to the global REST API. That in turn makes it easier to integrate with existing core or third party features (authentication and whatnot), things are more straightforward for plugin authors (no need to reinvent the wheel), and it's also easier for API consumers (familiar interface). Perhaps worth noting that this is not actually limited to front-end: it can also facilitate behind the scenes plugin-to-plugin integrations quite nicely. Let's say that I want to distribute a module that is focused on front-end features. Currently it would need to provide both back and front-end, since there's no public API I can tap into. SearchEngine might be one example of this: if there was a public API, I might be able to use that instead of implementing one of my own. I could list other examples, but the gist is that any front-end feature that needs to talk to the backend might benefit of this. If there was a public API (and by public I mean something accessible to, say, JavaScript) one could essentially develop front-end features, bundle them in a module or distribute in other ways, and then integrate them with ProcessWire without a need for a purpose built custom backend. In a way this would create a whole new market / open ProcessWire up for a new type of audience. Agreed, my experience is similar. New users tend to find ProcessWire very easy to use (certain differences in personal preferences aside), while much of the feedback regarding things like not having a sidebar seems to come from users with experience from other systems. Perhaps you're further down the adoption curve? One can always hope ? A few years ago it was easier to convince clients to try other platforms, today it's common for WP to be not just a strong recommendation but actually a strict requirement. I guess it boils down to the idea that if you're not an expert and have to make a decision about which offer to accept, the popular system is a safe bet. Also if you're requesting quotes and 4/5 recommend platform X, it does make one wonder if the majority could really be wrong. Thanks ?

Definitely one way to do it. My suggestion was largely based on the experience of working with code review in a previous job: CR is as much about education (nurturing a more productive team of contributors) as it is about making sure that the quality is solid. Obviously these approaches are not mutually exclusive ?

This has been a relatively common request for me as well. In fact a variant of the media library concept is on my todo list for tomorrow... ?‍♂️? I've found that this becomes more important when a site has more content and more content editors: sometimes it's about not having to maintain a separate media library (in a traditional media library, somewhat like the one found from WP, they would just upload the materials once and then reuse them everywhere with ease), and other times it's about knowing where each material has been used / being able to update it in a central place if it needs to change. In many (most) cases what we already have is more than enough, but regardless, I do run into this type of request every now and then.

It's true that this is not an easy topic. When it comes to the REST API shipped with WordPress... When it was initially added, we routinely disabled it from all the WP sites we maintained at the time. Mostly "just in case" and because initial versions (unless my memory fails me) had holes in them, but also because there was a very real chance of accidentally displaying content that wasn't actually intended as public. To my best knowledge it still doesn't ship with a very good native authentication solution. There's been some development in this regard and there are plugins for that, though — and again the API can be disabled if it's not needed. Even though it isn't without its issues (and even if it's not always particularly intuitive), it is now somewhat widely used, many plugins provide their own REST API extensions, and some plugins are even built on top of the API (though that might be at least in part due to WP's internal API not being all that great). The biggest benefits I see in a built-in API, even one that is disabled by default, would be that a) modules and other shared code can build on it since developers know that it'll be there and know how to operate it, and b) having a built-in API does sound better from a marketing perspective than "you can install it as a plugin/module". And it does give it some legitimacy too ? Anyway, definitely not an easy topic. If an API like this was to be added, I believe it should be disabled by default, there should be some sort of authentication mechanism built-in, and it would have to be very configurable regarding the data and operations that it would expose. Would also be interesting to benchmark what the "competition" is doing in this regard. @Jonathan Lahijani is definitely the one to talk about this, he's taken Repeater Matrix based content building to whole another level. Though I'd of course be more than happy to provide feedback and suggestions ? Oh, I can definitely agree with you here, design is always subjective. Personally I quite enjoy simplicity, but I also strongly dislike dropdowns — I'd much rather see all those top menus open (or collapsed and openable with a click) in the sidebar. It always feel it's a chore when I have to move a cursor over a specific item just to see what was under it... ? Interestingly the design of the admin was one of the first things our latest team member commented on when we were discussing the pros and cons of PW. I don't want to speak for her, but the gist was that perhaps PW would be a bit more "competitive" if the admin was easier for new users to grasp, and sidebar was something she specifically brought up. Again this is no doubt subjective, but I've heard similar comments more than once. It may be in part that folks are used to the admin in WP and comparing it to other systems they use, of course. Configurable sidebar would be a good compromise, something for everyone ? I agree with a lot of what you've said, and I very much appreciate your dedication to ProcessWire. That being said, the reason I commented on this was largely selfish: I've recently spent a lot of time and effort trying to convince folks both sides the figurative fence (devs and clients) of the fact that ProcessWire can indeed be trusted, and that the numbers they see (handful of devs here in Finland, small amounts of contributors in GitHub, etc.) are not all there is. The primary issue for me is not actually popularity. Personally I couldn't care less about that, but what I do care about is that recently the vast majority (at least half, but perhaps as much as two thirds) of potential clients have started with the demand that the project has to be built with a "popular" system (which usually really means WP). I can't speak for other markets, but here (and in the niche I'm in) it is already ridiculously difficult to convince buyers that the most popular option is not necessarily the best option. These buyers are often not especially technical and thus don't care that much about what goes on behind the scenes. What they do care is a) whether they can put their trust (and money) behind a less known platform, and b) whether they can be absolutely certain that there's always someone else to turn to if something goes wrong. Numbers work against PW in this regard, and while I'm well aware that challenging the role of the most popular CMS is not feasible (never say never...) an upwards trend would be a big plus ? When it comes to PR's, my suggestion would be to be as open as possible. I know that many of them are not "quite there", but perhaps you could provide some pointers, tell what's wrong and suggest some changes? It seems that many PR's are for minor things as well, typo fixes and such — I get that these don't really add a whole lot of value code wise, but the good thing about accepting them is that they do affect our numbers, and again that can be an important factor for getting new developers (and clients!) interested. (Some users may create certain types of "low value" PR's to get recognition for themselves, but personally I don't see much harm in that either. Mutual benefit and so on.) Anyway, just my five cents! I don't want to step on your toes here, just hoping that you can also see where I'm coming with this. I believe in ProcessWire, just trying to think of ways to convert non-believers (so to speak) ?

Oh. One more. I get that this is literally something you said you're well aware of, but I'd still like to say that I would absolutely love to see more pull requests get pulled into the core this year ? This has been brought up many times over the years, but the truth is that "if ProcessWire is so good then why are only a handful of people interested in contributing" is still one of the FAQ's I ever so often find myself answering. At least in the market I am in appearances and popularity matter a great deal, for clients as well as developers. I want to be able to justify why I'm not using the most popular platform out there, and sadly it's getting harder and harder by year (and a rather low number of contributors isn't helping, at the very least).

Off the top of my head if I had to name the things that are going to be — and, to be fair, have already been for some years now — potential "game changers", it'd have to be "flexible content" (as in some sort of page or site builders) and "headless" (as in native, external APIs). Neither of these is anything new, and both I believe have been mentioned here, and perhaps even existed on our roadmap in one form or another. In my experience the API part is driven largely by developer intent: there are many developers out there who prefer to work with something like JavaScript, or simply want to make a more clearly defined distinction between the data (API) and the application/front-end. WordPress has a native REST API, which (while not perfect) often gets the job done. Bolt has native REST and GraphQL APIs. And then there are all sorts of headless CMS' out there (Contentful, Strapi, Prismic, and so on) that have taken this even further, though I'm really not an expert on those myself. If ProcessWire wants to attract more developers, especially the types that enjoy working with modern technology and particularly JavaScript, this might be worth considering. Modules like AppApi and Process GraphQL have done a great job at providing an almost-out-of-the-box solution, and it's also very easy to build APIs on top of ProcessWire, but a native API would bring certain benefits that none of these solutions can do. That being said, it would also likely be a massive undertaking and would no doubt require a lot of planning: ProcesWire has a fantastic "internal" developer API, so the bar for a built-in "external" API would be pretty high ? As for flexible content, this is now something we use for pretty much every site we build. Unless it's a registry of predefined items (which is pretty rare), it's going to benefit from some sort of flexible content strategy. These days most content editors just can't be satisfied with "here's a CKEditor field, it works kinda like Word" — they demand quite a bit more than just that. We've been using RepeaterMatrix for this purpose and for the most part it works, but I do have to admit that it doesn't feel as slick and intuitive as some of the competition. Both Kirby and Bolt have interesting ideas in this regard, and Gutenberg is starting to look very interesting as well. Finally, a pet peeve of mine: the admin. While I really enjoy using ProcessWire's admin, there are also things I don't quite enjoy. For my taste it feels a bit overly verbose with all those lines, and when I look at the screenshots from something like Bolt, I really miss a sidebar. A proper one, one that stays in place, like the Reno theme had. I know I sound like a huge WordPress fanboy, but this is something they got right early on, and based on user feedback I'm not alone with that opinion. ... so that's one smaller-but-still-possibly-somewhat-meaningful feature I would like to see on our roadmap ? Now, having said all that: I know this is nothing "unique" or "groundbreaking". A lot of other systems are already doing these things. I would love to throw in an idea or two that no one has yet thought of, but honestly I think on the web today it's more about "who does it best" than "who has the most unique ideas".

Based on the Modules class it looks like module versions are checked by Modules::checkModuleVersion(), which gets called when individual modules are initialized (Modules::initModule()). From here on I'm largely guessing, but what I'd probably try first would be iterating over all modules (assuming that you want this to occur for all of them) and then calling something along the lines of... if ($modules->isInstalled($module_name_or_class) { $modules->get($module_name_or_class); } ... for each of them — first check is just to make sure you don't accidentally install all modules, while get should trigger upgrade check (if I'm correct, that is) ? Sounds a little hacky, not sure if it'll work 100% or if there's a more straightforward way. I couldn't spot one, though.

I'm not sure I fully understand what you're trying to achieve here, but no — this is not something SearchEngine does. It creates a single index for the entire site. I have considered adding support for multiple indexes, but a solid need for that never surfaced. Would be interesting to hear if there's one now, though admittedly this seems more like a need for a custom search engine, and thus likely has little to do with this module. The TL;DR seems to be that "this is not the module you're looking for", but I'll go through your questions just to clarify things: I'm not entirely sure what you mean by adding custom operators. If you're referring to selecting some operator that isn't available via SearchEngine settings, that's possible, but to be honest most of the selectors that make sense within site search queries are already there. As always it's good to read the docs, though; understanding selectors and selector operators is a key factor when working with ProcessWire ? Anyway, the settings you see in this screen are defaults. Most site search tools don't let visitors select operators or even alter the sort order in any way, so setting them once here is enough. If you're working on something more complex — perhaps something like library databases often provide — these settings have little to do with that. In this case you're probably not going to have much use for SearchEngine, although it's of course possible to create a custom search feature and use the search_index field as a regular field in your queries. At the moment you can't. These are not fields, they are indeed (literal) table columns. Search Engine doesn't work on that level. It'd be possible to add this feature, but at the moment this seems like an extremely rare need, and as such it's not particularly high priority. The selector inputfield you see when you use "Index pages now" feature is only a tool for finding the pages you want to index, and it's using the core Inputfield Selector for selecting applicable pages. The first part is not really in the scope of SearchEngine: it's a tool for providing a site search, and since sites consist of pages, that's what it will list. It does indeed sound like you're looking for something more customized. ... although you can in fact a) completely skip any front-end markup generated by SearchEngine and provide your own instead (basically just use the search_index as a regular field in queries), or b) modify markup generated by SearchEngine using hooks, or even c) hook into the indexing process to fill in other custom fields in addition to the default search_index field. All of these would require plenty of custom work, and I'm honestly not sure if you'd find SearchEngine useful for your needs; you may find it easier to build the entire thing from scratch.

Sure, it should work just fine. Let me know if you run into any issues though!

PHP 7.4 here as well. So far I can't remember having any major issues going from 7.1 to 7.2 and then 7.4. Most sites I run are relatively up to date, though, and generally speaking I don't use that many third party modules either. To be honest if there's any reason to worry I'd recommend 7.4, or perhaps even 7.3 (it's still supported for a while and would give some extra time to prepare for a bigger jump.) Probably going to set up a new server on weekend and move some sites there. Might as well go with PHP 8 and see how that goes ?

This is a long shot, but you should start by making sure that file WireDatabasePDOStatement.php exists in /wire/core/. It could potentially be an issue with one or more missing files, so getting a new copy of the wire directory could be a good idea as well.

Just checking: TextformatterVideoEmbed is listed before TextformatterPrivacyWire? If it's the other way around, this won't work. This could potentially affect the situation. I would make sure if it makes difference, i.e. try disabling it and see if that changes anything. So far this has worked for me, but let us know if the issue persists ? Edit: if TextformatterVideoEmbedOptions runs before TextformatterPrivacyWire, this will definitely break things due to this line: https://github.com/blaueQuelle/privacywire/blob/master/TextformatterPrivacyWire.module#L51. Seems like an easy fix, though. Admittedly the order of the modules is a bit fragile, but part of it is really due to the way textformatters work and there's not much that can be done about that.

Thanks — this is now fixed as well ?

@adrian, that PHP 8 issue should be fixed now. At least I assume it is — still don't have PHP 8 test environment, so it would be great if you could give it a try and let me know how it goes ?

Thanks for reporting this, @adrian! The issue is clear (return types for magic methods are now enforced by PHP) and the fix is simple, but I'll have to set up a test environment to make sure it really fixes the error... and doesn't introduce any new issues ? I'll get back to this ASAP. Edit: the dev branch at https://github.com/wireframe-framework/Wireframe/tree/dev now contains a fix for this, if you'd like to give it a try. I'll have to test this properly before merging to master.

You can find a live example of this from https://github.com/blaueQuelle/privacywire/blob/master/PrivacyWireConfig.php: $f = $this->modules->get('InputfieldText'); // ... $f->useLanguages = true; (Here it's a text input, but this should work for textarea as well.)

Just a quick heads-up: https://www.php.net/releases/8.0/en.php. PHP 8.0 is out. Some pretty fancy new features there, really looking forward to getting my hands on this one ? Might be a good idea to test before updating any critical environment, though. As always there are some backwards incompatible changes etc.

Just to be clear: in my opinion it's actually perfectly fine to perform redirects in Apache config files, site-specific vhost files, or even in the .htaccess file. It's just that they should use RewriteRule (mod_rewrite) instead of Redirect (mod_alias). If a new site requires redirects for old URLs, this is typically how I handle it — this way I have full control over wildcards and such, and there's very little overhead. Nothing wrong with using Jumplinks (or ProcessRedirects), of course. That slight overhead they add (booting up ProcessWire, checking for redirects, etc.) rarely matters ?

This "it" variable where ProcessWire internally gets the requested URL, see https://github.com/processwire/processwire/blob/master/wire/modules/Process/ProcessPageView.module#L320. If you're seeing these in your redirects, it probably means either that this Redirect is after ProcessWire's initial htaccess rules, or alternatively that Apache doesn't stop processing the htaccess file when it finds the Redirect row. I'm not completely sure if Apache should stop at Redirect or not, so you may have to use RewriteRule instead, specifying [R,L] as flags. Edit: gave this a quick try and it seems that there's no obvious way to make Apache stop parsing further rules when Redirect occurs. Simply put RewriteRules should be used in this situation instead — or you can use a module / code approach, which of course comes with some overhead. Overall mixing mod_alias and mod_rewrite seems like a bad idea ?

While I kind of share your opinion on the vendor lock-in thing, I don't think this is going to be a big deal — as Ryan pointed out the vast majority already use GitHub, even though some popular modules are currently on GitLab. Looking at this from Ryan's point of view it's likely less work to develop (and maintain) features when you're using a single API rather than multiple... and if that helps Ryan keep things up and running, I think it's a good approach. Also personally every time I want to report an issue or send a pull request (or merge request in GitLab) it's a bit of a nuisance if the module is not hosted on GitHub. What I'm trying to say here is that since GitHub is the most popular option by far, as well as the platform we're using for core development, hosting third party modules there makes collaboration easier ? Regarding "own git" or "custom download URL" it's good to keep in mind that a lot of the data can be pulled automatically via GitHub API, and this would defeat that purpose. Custom download URL would also be potential risks in terms of security — public git repository, and preferably one with a GUI, is a must-have for this exact reason.

Awesome — thanks Joshua! Just a heads-up: I've opened a new PR for you to check out at https://github.com/blaueQuelle/privacywire/pull/10. This is quite opinionated, so let me know if you don't feel it's a great match with the module. Basically what I've added is support for the textformatter module to replace embedded media/video iframes with PrivacyWire enabled ones. It's mainly a compatibility layer for TextformatterVideoEmbed ?

Hey @joshua! I'm not sure if this is a real bug, but on one site I have a script like this: <script id='taeggie-feed-widget-script-xxx' type="text/plain" data-type="text/javascript" data-category="marketing" data-ask-consent="1"> jQuery.getScript(...); </script> This works and the consent info/request box is displayed. If I click the "accept" button from this info box it goes away and the script gets executed, so all is good in that case — but if I instead click the "accept all" button from the (separate) cookie management banner, the info and accept button next to the script are not removed. Note that the script works as expected regardless of which accept method I use, so the only issue here seems to be that the info box / accept button are not removed. If I refresh the page, they are gone. Is that a bug, feature, or user error? ?

Hey @Ivan Gretsky — thanks ? With latest version (just released, 0.27.0) you can make the module store page ID as an indexable field. This will allow the page to be found by its ID (since that is now included in the index) OR you can use syntax such as page.id:1234 to specifically search for a page with this ID (though this would likely also match page.id:12345 etc.) Of course id:1234 will also work, but may result even more false positives. If you update to the latest version of the module, note that you also need to add id as an indexable field and rebuild your index before this will work.

Just checking: do you have VersionControl module installed? Core doesn't (as far as I know) have this kind of error anywhere, so it could be a third party module (and VC is one module with that exact error message) ?

New release — 0.18. This version adds Tracy panel for Wireframe: Obviously the panel will only show up if both Wireframe and Tracy are installed. Currently it displays some content I thought could be useful while developing, but I'm open for suggestions. Tracy doesn't really enforce any rules here, so in the future the panel could also provide interactive developer tools or something along those lines... just not sure yet what would be useful ? Thanks to @adrian for adding support for custom panels!