Leaderboard

Hello @ all Today I want to share an inputfield/fieldtype to store 2 or 3 dimensions of an object. This fieldtype was inspired by the amazing fieldtype "Fieldtype Dimensions" from SOMA. This fieldtype was introduced in 2013 - so its time for a relaunch. This new fieldtype offers more possibilities than the old one. This inputfield/fieldtype let you enter max. 3 dimensions (width/height/depth) of an object (fe a product), but you can select if you want to display inputs for 2 or 3 dimensions. 2 dimension can be used fe for wallpapers or photos, 3 dimensions fe for furnitures or other objects. There are several configuration options for this fieldtype in the backend. set type (2 or 3 dimensional) set size unit as suffix after each inputfield (default is cm) set max number of decimals (default is 2) show/hide a hint to the user how much decimals are allowed If the number of decimals will be changed, the database schema for each dimension column will also change after saving the field in the backend. For example: If the schema for each dimension field in the DB is f.e. decimal(65,2) and you will set the number of decimals in the configuration to 3, then the schema in the DB will also change to decimal(65,3) after saving the inputfield. You can download this inputfield at https://github.com/juergenweb/FieldtypeObjectDimensions There you will find more detailed information and explanation too. If you find any bugs or you have an idea to improve it (also code improvements) please report it on Github. Have a nice day! UPDATE 14.06.23 / VERSION 1.2.2 I have re-written the complete fieldtype to be compatible with PHP 8.2 and refactored some of the methods and the database scheme. If you have downloaded the fieldtype before, please deinstall the old one and make a new install. I have added this fieldtype to the Processwire module directory. After it has been published, please download it from there.

This week I'm not bumping the version number just yet because I've got lots of work in progress. The biggest thing so far is something I hinted at last week. Basically, I like what the addition of the MySQL query expansion operators have brought (per posts last week and week before), but they also reveal what's lacking: something as simple as a search for "books" still can't directly match the word "book". But that's the most basic example. It's not a limitation of ProcessWire, but just the type of database indexes in general. I think it'd be amazing if ProcessWire had the ability of being really smart about this stuff, able to interpolate not just plurals vs. singulars but related words. In a perfect world, this is what query expansion would do (in addition to what it already does). But the reality is that it involves all kinds of complicated logic, rules and dictionaries; well beyond the scope of even a database. And it can be vastly different depending on the language. So this isn't something we can just add to the core and have it work. On the other hand, I figured maybe we should just put in a hookable method that just pretends the ability was there. Then people could hook it and make it respond with variations of words, according to their needs. The searches that use query expansion could then call this method and use whatever it returns... for when someday the ability is there. So I went ahead and added that hook — WireTextTools::wordAlternates(). And our database-searching class (DatabaseQuerySelectFulltext) now calls upon it, just in case an implementation is available. Well, after getting that hook added and having our class call it, naturally I wanted to test it out. So I got to work on it and came up with this module: WireWordTools. The WireWordTools module provides an API for English word inflection and lemmatisation. And it hooks that new method mentioned above, so that you can install it and immediately have it bring your searches to the next level. While it only helps for English-language searches, maybe we'll be able to add more languages to it, or maybe it'll lead to other modules that do the same thing for other languages. The expanded/alternate words are only used for searches that use the new query expansion operators, which are the ones that have a "+" in them: ~+=, ~|+=, *+=, **+=. They all can return similar results, but are weighted differently. Unlike most operators, where the logic is direct and you can expect them to always behave the same way, these query expansion operators are more subjective, and ones I think we should intend to keep tweaking and improving over time to continually improve the quality of the results they return. Basically, they are geared towards building site search engines, so I think it makes sense for us to pursue anything that makes them better at that, rather than aiming to always have them return the same thing. I am currently testing out the ~|+= operator ("contains any words expand") on our main site search engine here, along with the WireWordTools module. Finally, searching for "books" does match "book" too, and a lot more. More to be done here, but it's a good start hopefully.

Thank you Ryan. Have a great weekend.

Yes, that would be very un-databasey. You basically have three entities you care about: Chairs, Brands and Adapters. At first glance (I may be wrong about this) it looks like each Chair has exactly one Brand and exactly one Adapter. For each Brand there are multiple Chairs and multiple Adapters, and for each Adapter there are multiple Brands and multiple Chairs. Make three templates, Chair, Brand and Adapter. The Chair template has one page field for a Brand page and one page field for an Adapter page. Now you can structure your page tree any way you like. If you want your URLs to look like http://example.com/e-drive/netti-i/, put Chairs under their Adapters as children. Now you can drop the Adapter page field and just use the Chair’s parent instead. If you want your URLs to look like http://example.com/alu-rhab/netti-i/, put Chairs under their respective Brands as children. Now you don’t need the Brand page field. Assuming the latter, finding all Alu-Rhab Chairs is easy: $pages->find("template=chair, parent.name=alu-rhab"). Finding all E-Drive Chairs: $pages->find("template=chair, adapter.name=e-drive"). Finding all E-Drive Brands: $pages->find("template=brand, children.adapter.name=e-drive"). Not sure about finding all Alu-Rhab Adapters, but if it comes to it, you can just get the page ids with SQL and do $pages->findIDs() on them. Or loop over all Adapters and check if there is at least one Alu-Rhab Chair for each one.

UPDATE 2020-07-03 SnipWire 0.8.7 (beta) released! This update fixes some small bugs and adds an indicator for TEST mode: Added ProcessWire notice to flag SnipWire TEST mode Updated exchangerates API to handle unsupported currencies All modules and class files are now using ProcessWire's classLoader Fixed badges display when no refunds possible (in order details - refunds form) Fixed a page select problem with custom cart fields

I’m guessing header and footer come from prepend and append files. You’ll have to figure out a way to disable those in Ajax requests. For example, if you use $config->prependTemplateFile, just condition that with $config->ajax. //in site/config.php if (!$config->ajax) { $config->prependTemplateFile = 'head.inc'; $config->appendTemplateFile = 'foot.inc'; } You may need to set request.setRequestHeader('X-Requested-With', 'XMLHttpRequest') on your Ajax request for ProcessWire to automatically detect it as Ajax.

Hi @gornycreative this could work, yes. But I guess there would be 1000 edge cases that could make that setup fragile. I've used Kickstart on almost all installations for the last couple of months years ? and had no problems, but for example on my new live server I get a 500 (though the installation works afterwards, but I have to clean some files manually... likely a permissions issue). What I'd really like to have is some kind of simple and solid kickstart that installs RockMigrations and can then do whatever you want. Yeah, you always get the latest versions of PW and all the modules and you stay flexible in the setup (just comment out unneeded modules).

First of all: I definitely agree with your first point. I need to do some testing and probably add additional configurability to the SearchEngine module after these updates. Some pretty interesting options we've got now! In the past I've steered away from the full-text index because it has resulted in way too many "oddities", i.e. some queries just don't work either due to stopwords or something else, and it seems to be (in my experience) particularly problematic if the site is authored in some other language than English. You've given me a reason to revisit this, though ? As for plurals, it sure is an issue with other languages as well. I have no idea what you've got planned in that regard, but one problem here is that it gets pretty complex if you want to support other languages than just English (which is, actually, one of the easiest languages in this regard). And then there's of course the bigger issue of stemming — considering your goose example, if a client was searching for "hanhi" (goose in Finnish), it's true that they would likely expect it to also match "hanhet" (plural), but if that works then why not other forms such as "hanhia", "hanhen", "hanhien", "hanhesta", "hanheen", etc. Anyway, very much looking forward to what you've got planned! Just wanted to point out that this can be a pretty big issue to tackle, at least unless limited to English only, or perhaps made so modular that each language can have its own set of rules. Also it's a slippery slope, and once things like stemming come into play we're in really deep waters ?

That's just the collation, but not the charset. You need to change at least the latter one. https://dev.mysql.com/doc/refman/8.0/en/charset-general.html Edit: I'm also kinda wondering about the "but for title and descriptions" part. Why not use utf8mb4 for everything, which is the way to actually use utf8 text in mysql. The "utf8" charset is just plain not utf8 at all, but rather a mysql abomination.