teppo

Version 0.21.0 released: ### Added - Hookable method MethodPropsTrait::getMethodPropCacheName(string $name, string $context). Note that when hooking into this method one should refer to the object that implements the trait, such as a specific Controller class. ### Changed - Include language ID in persistent cache name generated by MethodPropsTrait for cacheable methods. @Zeka, thanks for bringing the lack of multi-language support for cache names up. While testing I noticed that a site I've been working on recently was in fact also affected. Not a huge deal in this case but it could've caused some confusion. For the record: I ended up just adding the language ID to the key. If LanguageSupport is not installed it'll be a blank value, but that doesn't really matter ?

That's a strange one. A couple of checks first: Does your layout file include the ProcessWire namespace? If not, you'd have to call it via \ProcessWire\Wireframe (though adding namespace is always a good idea). Which version of Wireframe do you have installed?

Absolutely, both options seem reasonable — I'll add this to my todo list!

Generally speaking PHP 7 and 8 tend to work similarly in these situations — PHP 5 was more "forgiving" ? Anyway, it could be related to VC 1.3.1. I've been using VC 2.x for a very long time, will have to set up a test site for 1.x. Edit: turns out it's an issue affecting PW < 3.0.166. At least this particular instance of it is pretty easy to circumvent; I've prepared a fix, but will have to test carefully before releasing it.

Hey @PWaddict! So far I've been unable to reproduce that. I'm running PHP8, which should be close enough, but there are no warnings for me. The error you've mentioned — assuming that you're using recent ProcessWire version — seems to point to WireDatabasePDOStatement::setDebugParam(), and more precisely it getting an integer as the param name. I've no idea how that could happen, and at the very least I can't find anything in Version Control that should (directly) cause it. So... if you have any additional details, like where in the Version Control this error might originate, that'd be great. Also: which version of ProcessWire and which version of Version Control are you using?

Similar experience here. For me it was all about adventure games — Space Quest, Kings Quest, Police Quest and Quest for Glory, as well as point-and-click games such as Maniac Mansion, Monkey Island, etc. Especially early adventure games with a text parser were brilliant tools for learning the language: while they didn't necessarily require you to be fluent in English, you had to have a decent vocabulary and at least some idea about how to form sentences ?

Hey @Pete! Not sure if this has changed recently, but just noticed that http://processwire.com/talk/ works as well. Should/could this redirect to the HTTPS version instead? Unrelated note regarding moderator actions: I'm pretty sure that flagging someone as a spammer used to hide their posts. Doesn't seem to work that way anymore. Also I seem to recall there being some sort of limit to what new users can post. Am I wrong or did something change regarding this/these? ?

This looks like the .htaccess file found from /site/. You should check the one in your websites root directory (one folder above /site/) instead. As @wbmnfktr mentioned, similar issues have been covered here before. This one could be related (though I'm kind of guessing here). It's a bit old so there have been some changes to the root .htaccess file since then as well:

It's not really about being clever: the core ships with a metadata file (wire/core/.phpstorm.meta.php) that makes PHPStorm aware of the inner workings of the wire() method. PHPDoc comments only state that the wire() method may return a number of different objects, so there's little that the editor can figure out from that alone. VSCode doesn't (AFAIK) have anything similar to this, but depending on the plugins you use this may be possible — with some caveats. I use PHP Intelephense, and while it does actually read PHPStorm metadata, it doesn't seem to support reading it from subdirectories: https://github.com/bmewburn/vscode-intelephense/issues/1384. At the moment I don't have any idea how to get this to work, except of course for duplicating the metadata file to your project's root directory. (Or finding a plugin that supports this feature ?)

It can result in a lot of data being stored in the database. From your earlier post it sounds like that could be at least one reason why your database takes so long to back up. In my experience a ProcessWire database taking very long to migrate/backup/etc. usually means that the site has at least one, and possibly more than one, module that keeps storing data without limits (or with very loose limits). Jumplinks' 404 monitor is one module/feature that can do this, while ProcessChangelog and ProcessLoginHistory are other typical culprits. I believe Jumplinks has an admin tool for checking the number of stored 404 hits and clearing them, so it might be a good idea to check that, just in case ?

The biggest issue seems to be that /site/templates/js/jquery-1.7.2.min.js is somehow corrupted. Try transferring it again, or alternatively downloading jQuery 1.7.2 directly from jquery.com or some other site where it's available in it's original form. Edit: actually... same goes for most of your other JS files, and some parts of CSS files as well. If you have original (pre-transfer) versions somewhere, try transferring them again (via FTP or whatever method you used). It looks like something went wrong while files were being uploaded (or downloaded). If you have the full source code for the site available, you may even want to transfer it again to the server, or alternatively compare it with current versions to make sure there are no more broken parts ?

Thanks, @adrian. I agree that this is the simplest solution, and probably the most sensible one right now. It's now included in the dev branch of the module ?

Great — let me know if you run into any trouble and I'll be happy to help! If you mean which file, for this purpose (saving pages in the admin) you could put the hook into site/templates/admin.php, but site/init.php is likely just as good (and also catches page saves that occur outside the admin).

Thanks! Currently "id", "name", and "title" are indexed automatically for page reference fields. If a programmatic approach is easy enough, you can modify this behaviour and add more fields by hooking before Indexer::getPageReferenceIndexValue() and modifying the $indexed_fields argument. Alternatively you could hook into this method and in specific cases replace the behaviour completely, for an example by returning the output of the indexPage() method for each individual page instead (here's a loosely related example). Let me know if you need additional pointers and I can provide some sample code.

Seems reasonable. In fact I had similar issues earlier, but those were fixed by switching from substr() to mb_substr(). This case seems a bit different, though. I'll try to set up a test case and see what I can do about that; so far I've only managed to end up with a partial encoded entity, 80& instead of 80' and so on ? Meanwhile I noticed that in some cases the new auto desc feature generates odd looking "......" character sequences and other weird results, so there's more to tweak anyway. I'll try to dedicate some time to this in the next few days. Just to make sure: did you mean HTML Entity Encoder?

I'm not Adrian (obviously), but from my side things seem to be running smoothly now. Been running a bunch of my own sites on PHP 8 for a month or so. As long as you're using the latest dev version, that is — I ran into some bugs in current master that I'd consider showstoppers, though can't remember exact issues. I think one was somehow related to image sizer, at least ? New minor issues still seem to pop up, such as this one from a few days ago: https://github.com/processwire/processwire-issues/issues/1363.

Sounds like a neat feature, but this will get somewhat complex ? At the moment automatic description is generated by looking for the (first instance of the) query string (as a whole) within the index, and then converting that + a sensible amount of "padding content" to an excerpt. So far so good. Now, in order to generate an excerpt based on multiple words... Search query needs to be split by whitespace, and perhaps other characters as well. Each word should be matched individually. Preferably words should be matched in any order, just like they are when the query is performed. Here we should probably include more than just the first match, or at least that's my initial gut feeling. Since there may be many individual matches, we need a limit to how much content gets displayed, and we should also have some sort of algorithm in place to figure out which matches to use. Of course some of this may not be strictly speaking necessary: just finding a match with any single word from the query would be pretty much as simple as the logic we now have in place. But in this scenario that would result in somewhat suboptimal results. Anyway, just thinking out loud here. I'll give this a shot and see what I can come up with ? By the way, this is somewhat off-topic but this is one of the reasons I almost never use this operator: using the same content you have on the page, I'm unable to get any matches with "incised streambanks", "stream", or "banks". Might have something to do with MySQL settings (I'm using mostly default settings) but anyway, in my experience this behaviour is so flaky that I really can't be bothered with it. "%=" may not find results in "wrong" order etc. but at least it won't miss direct hits. And as for performance... well, I've never run into a use case where I would've observed any noticeable difference ? (Enough with the off-topic!) I'm not entirely sure about this one yet. Let's see if this makes sense once I grasp the "non-consecutive autodesc" thing.

That's a good point. Version 0.3.0 reverts field settings during uninstall. Seems that altering data is not necessary: even if the field contains multiple values (in database), only one is returned with the new settings. I'm not 100% certain that this won't cause any unexpected side effects, but for the time being it seems to work fine... ?

No worries and thanks for letting me know ?

I have to disagree with this, to an extent. If I did client projects of my own I'd very much appreciate the option of off-loading the hosting and day-to-day maintenance of said sites to someone else. Sure, most of the time a "general purpose" hosting plan is good enough and ProcessWire is great in that it has very rarely really "required" updates, but I could imagine a plan dedicated to ProcessWire providing some extra services that a general purpose one won't and can't ? At the same time I don't really see why this wouldn't work for business clients as well. We host the sites we build in-house, and I can say that a lot of time and effort has gone to tweaking that setup, and maintaining the platform and the sites on it is an ongoing process. If hosting wasn't an important part of what we do, or we weren't quite as familiar with the inner workings of ProcessWire, it would make plenty of sense to subcontract that service from someone who actually specializes in it. Many companies that work on other platforms, such as WordPress, choose external hosting — not because they can't do the hosting, but rather because it's not their core business. There are also numerous "developer oriented" hosting platforms out there.

I've tried, but so far have been unable to reproduce this. Any additional pointers would be welcome ? Glad to hear you got it solved. Just for the record, with latest release 0.29.6 $query->results is also available. It's otherwise the same as getResults(), but adds additional check in case there were no results (in which case it will return null instead). I believe my initial idea was to avoid multiple ways to access the same data, but this is more in line with other features ?

You and me both. From the outside it seemed like a very nice idea and the numbers initially posted seemed to indicate a decent level of interest. Hard to say — could be any number of reasons: technical issues, problems with the business model, or simply the classic "moved on to other projects". The service was quietly taken down, and the Twitter account or support board were never updated to even mention this ?‍♂️

At the moment tab labels can be customized by hooking into Renderer::renderTabLabel — does that seem feasible to you? Could also have a setting for this, but I'm not yet sure about that; it would get a bit complicated, particularly if I end up adding more group_by options. My initial impression is that current approach might be better, especially considering accessibility: users should get some kind of "summary" before the tabs, so that they know what's going on. Solving this with a "tabs first layout" could mean a) visible order that is not the same as real order, or b) visually hidden heading above tabs and then a visible heading hidden from screen readers below them. (Loosely related note: accessibility is not "perfectly" handled right now, I'll likely make some tweaks in this area soon.) I'll have to think about this a bit more. At the moment you have a couple of options: The module currently outputs a heading above the tabs and a summary below them. You could modify that first heading so that it's visually hidden and then hook into results rendering and inject your own "heading" above the summary element. This is a bit tricky right now, but I can make the heading rendering part hookable separately, I think that'd make sense anyway. Modify the order with JS. (Yes, this is a bit ugly... ?) So no real answer here, just some ideas, but I think that this level of control will likely require some sort of hook based solution anyway.

So you are looking into querying data from an external service (Shopify?) that uses GraphQL? Simply put, GraphQL is a query language: a client sends a query (defined using the GraphQL language) to the server, which then responds with a GraphQL object. WireHttp is a class you can use to send HTTP requests from ProcessWire. You could send a GraphQL request with WireHttp — so no, GraphQL is not a replacement for WireHttp ? I'm not saying that you should use it, but here's a very simple GraphQL client implementation: https://gist.github.com/dunglas/05d901cb7560d2667d999875322e690a. Here's an example of querying GraphQL API with Guzzle (which, by the way, is something you could use as a replacement for WireHttp): https://dev.to/jakedohm_34/how-to-make-a-graphql-query-or-mutation-in-php-with-guzzle-359o. Or you could use something a bit more sophisticated, perhaps https://github.com/mghoneimy/php-graphql-client. I'm not an expert on this topic, so perhaps someone with more GraphQL expertise can chime in. Just thought I'd drop some pointers ?

Your approach seems fine to me. If there were a lot of templates then it would result in multiple queries, but for most use cases I'd assume the performance impact to be extremely small. On the other hand the approach I've taken (modifying the DatabaseQuerySelect object on the fly) should result in just a single query, but is also potentially more fragile... ? Thanks — this is now fixed in the latest release.