Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/27/2020 in Posts

  1. 13 points
    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.
  2. 10 points
    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 (https://modules.processwire.com/modules/fieldtype-dimension/). This fieldtype was introduced in 2013 - so its time for a relaunch. This new fieldtype offers more possibilities than the old one from SOMA. 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 width attribute for the inputfield in px (default is 100px) set size unit as suffix after each inputfield (default is cm) set max number of digits that can be entered in each field (default is 10) set max number of decimals (default is 2) show/hide a hint to the user how much digits/decimals are allowed If the number of decimals or digits 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(10,2) and you will set the number of digits in the configuration to 12 and the number of decimals to 1, then the schema in the DB will also change to decimal(12,1) 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!
  3. 9 points
    Hello @ all! I want to share a simple fieldtype and inputfield to store address data with you. I have created this inputfield for learning purposes and it has no fancy functionality. It is simply for storing address data such as street, number, postalcode and so on in one table. As an addition you can store latitude and longitude too, so you can use them in maps. Here is a screenshot of what it looks like: You can select which fields are mandatory and you can choose if the inputs for longitude and latitude should be displayed. These settings can be configured in the field configuration. If you find this inputfield useful you can download it at https://github.com/juergenweb/FieldtypeSimpleAddress There you will find a detailed explanation. If you have an idea of an usefull feature that can be added or you have detected a bug, please report it in my github account.
  4. 9 points
    Version 3.0.161 on the dev branch continues with the updates optimizing our support for the new selector operators introduced in last week's blog post for 3.0.160. Last week I was still kind of figuring it out and the code still needed some refactoring and optimization. This week several parts have been rewritten and it's been improved quite a bit. Though the end result is still very similar to what was demonstrated last week, but now it's a lot more performant and solid. One thing new this week that's also kind of fun: you can now use more than one operator in any "field=value" selector expression, at least from the API side. And it works anywhere that you might use a selector, whether querying the database or something in memory. I think the best way to explain it is with an example. Let's say that you want to find all pages with a title containing the phrase "hello world" — you'd do this using the "contains text/phrase" operator: *= $pages->find("title*=hello world"); But let's also say that if you don't find any matches, you want to fallback to find any pages that contain the words "hello" and "world" anywhere in the title, in any order. We'd use the "contains all words" operator "~=" to do that. So now you can add that operator to the existing one, and it'll fallback to it if the first operator fails to match. So we'll append the "contains all words" operator to the previous one: ~= $pages->find("title*=~=hello world"); Cool huh? But maybe we still aren't finding any matches, so we want to fallback to something even broader. So if the phrase match fails, and the words match fails, now we want to fallback to find any pages that contain the world "hello" OR "world", rather than requiring them both. For that we can use our new "contains any words" operator: ~|= $pages->find("title*=~=~|=hello world"); This example is getting a bit contrived now, but let's say that if we still haven't found a match, we want it to find any pages that have any words starting with "hello" or "world", so it would find pages with words like "helloes", "worlds", "worldwide", etc. That's a job for our new "contains any partial words" operator: ~|*= $pages->find("title*=~=~|=~|*=hello world"); Okay last one I promise—you probably wouldn't stack this many in real life, but stay with me here. Let's say the query still didn't find anything, and as a final fallback, we want it to find any words LIKE "hello" or "world", so that those terms can match anywhere in words, enabling us to find pages with words like in the previous example, but also words like "phellogen", "othello", "underworld", "otherworldly", etc., and that's a job for our new "contains any words like" operator: ~|%= $pages->find("title*=~=~|=~|*=~|%=hello world"); So that looks like a pretty complex operator there, but as you've seen by following the example, it's just these 5 appended operators to each other: *= Contains phrase ~= Contains all whole words ~|= Contains any whole words ~|*= Contains any partial words ~|%= Contains any words like I think a more likely scenario in a site search is that you might stack two operators, such as the *= followed by the ~|*=, or whatever combination suits your need. By the way, you can do this with any operators, not just the text searching ones. But if you didn't read the blog post last week, also be sure to check out the other new operators in addition to those above: *+=, **=, **+=, ~*=, ~+=, ~~=, ~%=, #=. I think these new operators help out quite a bit with ProcessWire's text searching abilities. But there's one thing that's kind of a common need in search engines that's not easily solved, and that's the handling of singular vs. plural. At least, that's a common issue when it comes to English (I'm assuming so for other languages, but not positive?) MySQL fulltext indexes can't differentiate between singular and plural versions of words, so they index and match them independently as completely different words. This can be unexpected as clients might type in "goose" and expect it's also going to match pages with "geese". I've already got something in the works for this, so stay tuned. Thanks for reading and hope you have a great weekend!
  5. 7 points
    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 😄
  6. 5 points
    Check this out: https://processwire.com/blog/posts/pw-3.0.137/#on-demand-mirroring-of-remote-web-server-files-to-your-dev-environment
  7. 4 points
  8. 4 points
    Hi there, another one finished, up and running. https://bots4you.de/ The website informs about bots4you which is a German based Chatbot creator. Special with this chatbot is its b2b purpose, that means it is pretty decent in "knowing" what customers of several industries (real estate, insurances etc.) want to know and describe their efficiency with nearly 80% of success for common customer inquiries. From the ProcessWire perspective I mainly use Repeater Matrix with which I only have one template (even for home) but 8 content modules that can be arranged like the customer wants to create different pages. Other than that I used TailwindCSS for the first time, but I am not convinced, at least in a PW environment. Downsides where: build time when in dev mode (hot reload takes up to 6 seconds) purge of my php files was less than reliable. I ended up putting most of the classes on an allow list in the tailwind config. Could be my fault, but the overall experience wasn't that great. Anyway, client is happy, and I am, too: 😉
  9. 4 points
    Got to agree with Kongondo here. In my case the dev hot reload takes < 2s, and that's with some recent slowdowns (not sure what's going on in my system, but it used to be < 1s). Of course this also depends a lot on what you're doing at dev stage: are you running purge here as well, what else are you running on each rebuild (pre- or postprocessors and whatnot), which files are you watching, etc. Depending on your setup there may be steps you can take to get it down considerably. In our gulp based workflow, for an example, one major bottleneck was solved by adding gulp-cached — on a moderately large site this took dev build time down from what was originally probably 6-10s to 1-2s. Never had this issue either. There could be something else wrong, but usually this would mean either that you're actually not going through all those PHP files in the purge step, or you're using some sort of "constructed" class names (px-<?= $x ? 1 : 2 ?>). Not saying that you're doing something wrong, but again: this has been working perfectly for us. Note: I've got some beefs with Tailwind myself, but those are all about the general methodology. Tech wise it's been really, really slick 🙂
  10. 3 points
    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
  11. 3 points
    v1.0.8 improves the readme (had no section about getRows() 😮 ) and adds a nice shortcut $finder->groupBy(): https://github.com/baumrock/rockfinder3#getting-data Getting data When using a regular $pages->find() you get a PageArray as result. When working with RockFinder we don't want to get the PageArray to be more efficient. We usually want plain PHP arrays that we can then use in our PHP code or that we can send to other libraries as data source (for example as rows for a table library). getRows() This returns an array of the result having the id as key for every array item: $finder = $rockfinder ->find("template=cat") ->addColumns(['title', 'owner']); $rows = $finder->getRows(); db($rows); Having the id as item key can be very handy and efficient to get one single array item via its id, eg db($rows[1071]): getRowArray() Sometimes having custom ids as array item keys is a drawback, though. For example tabulator needs a plain PHP array with auto-increment keys. In such cases you can use getRowArray(): https://github.com/baumrock/rockfinder3#predefined-methods Predefined Methods At the moment there is one shortcut using the string modification technique for grouping a result by one column: $finder = $rockfinder ->find("template=cat") ->addColumns(['title', 'owner']); $cats_by_owner = $finder->groupBy('owner', [ 'GROUP_CONCAT(title) as title', ]); db($cats_by_owner); Another example could be getting averages: $finder = $rockfinder ->find("template=cat") ->addColumns(['title', 'owner', 'weight']); $cat_weight_by_owner = $finder->groupBy('owner', [ 'AVG(weight) as weight', ]); db($cat_weight_by_owner); Of course you can combine both: $finder = $rockfinder ->find("template=cat") ->addColumns(['title', 'owner', 'weight']); $combined = $finder->groupBy('owner', [ 'GROUP_CONCAT(title) as title', 'AVG(weight) as weight', ]); db($combined);
  12. 3 points
    What I've done is write a php script that I run from the command line to avoid memory/execution timeout issues. I also always use PHP League's CSV library which iterates the CSV without loading it all into memory.
  13. 3 points
  14. 3 points
    So yes, the credentials are shown on the terminal of the VM at the end of the install : credentials in yellow
  15. 3 points
    Well, this depends on if the stored value for the inputfield has been set as a property of the class. There are multiple different places you might use an inputfield and it's up to you to get the value you want to set to it. How you get it doesn't have anything to with InputfieldCheckboxes per se - you just need to make sure you are setting an array as the value. If the inputfield is used in the getModuleConfigInputfields() method of a module then the value stored in the module config is automatically set as a property of the module class. Alternatively, if you have a config field for an Inputfield module (in the getConfigInputfields() method) that is used with a PW field then this config data is stored on the field, because only the field has a record in the database. In other words there is a "fields" table but no "inputfields" table. So you can get the stored value from the $field object as you are doing, but arguably it's better to make use of the features that PW has built in to automatically populate Inputfield properties from the corresponding Field. The Field class has this code in the getInputfield() method: // custom field settings foreach($this->data as $key => $value) { if($inputfield instanceof InputfieldWrapper) { $has = $inputfield->hasSetting($key) || $inputfield->hasAttribute($key); } else { $has = $inputfield->has($key); } if($has) { if(is_array($this->trackGets)) $this->trackGets($key); $inputfield->set($key, $value); } } What this boils down to is: "For every data property set on this Field object, check to see if a property of that name exists on the Inputfield object used by this field. If it does, set the value stored on this Field object as a property of the Inputfield object". So to make use of this you just need to set a property name in your Inputfield module's init() method, so that the property can be seen to exist when Field::getInputfield() is called. And typically you would set a default value for this property when appropriate. You can see how this is done in InputfieldRadios for example: public function init() { $this->set('optionColumns', 0); parent::init(); } By doing this: 1. A default value of 0 is set for optionColumns 2. Any value for optionColumns that is stored on a corresponding Field object automatically becomes available in the InputfieldRadios class as $this->optionColumns.
  16. 3 points
    Have you thought of writing a Textformatter module? They're really very straightforward - you don't even need to use hooks. There are good examples to copy in wire > modules > Textformatter (for instance, TextformatterNewlineBR.module is a nice starting point). Once you've put your module in the site > modules and installed, apply the Textformatter on the Details tab of the fields where it's needed.
  17. 3 points
    I had to take a closer look, and it's actually mostly related to our PHP task, which runs PHP_CodeSniffer (which can be very time-consuming). You can use this with any files, though — check out https://www.npmjs.com/package/gulp-cached. It's really easy to add, basically just require the package and add a single line to your gulp task. The basic idea is that gulp-cached keeps track of files, and makes sure that files are only passed downstream if they've changed since last run. What this means in practice is that when using watch, the initial build may still be slow (none of the files being watched are cached) while subsequent ones are going to be much, much more performant, as all files that didn't change will be skipped over. Other differences I can see with our setups: You seem to be running sourcemaps on every build. If this is really the dev/watch process, then I don't really see a reason to do that, and it's definitely going to slow things down. We're using gulp-if to check for env and only setting sourcemaps up if it's a production build (basically gulp build vs. gulp watch). I'm not seeing anything related to purge here. If you're using the purge setting in Tailwind config, this is a relatively new thing and I really can't say anything about that — for me it seems easier to just run purge as a part of the gulp task: // Tailwind extractor for purgeCSS const tailwindExtractor = (content) => { return content.match(/[A-z0-9-:\/]+/g) || [] } ... .pipe(gulpif(argv.prod, purgecss({ content: [ config.paths.base + '**/*.php', config.paths.base + '**/*.js', config.paths.site + 'modules/InputfieldCKEditor/*.js', ], extractors: [ { extractor: tailwindExtractor, extensions: ['php', 'html', 'js'] } ] }))) ... Actually it shouldn't — just having something like px-3 in a file with nothing else should be enough. Again this is based on the code I've posted above, so if the native feature is using some sort of "advanced" matching algorithm, it could be a major problem for a lot of code. Weird. Note also that unless Tailwind has a mechanism for disabling purge on dev builds, you're going to be doing a lot of work that you probably don't need there. That could be another bottleneck. I'd probably just stick to a manual purge declaration in gulpfile. There's good documentation for that here, in case you need more details: https://tailwindcss.com/docs/controlling-file-size/.
  18. 3 points
    /** @var InputfieldCheckboxes $f */ $f = $modules->get('InputfieldCheckboxes'); $f->name = 'foo'; $f->label = 'Foo'; $f->addOptions([ 'red' => 'Red', 'green' => 'Green', 'blue' => 'Blue', ]); // The value will be an array e.g. ['red', 'blue'] $f->value = $this->foo; $inputfields->add($f);
  19. 2 points
    I was going through the Hanna Code "Readme" in Bitpoet's editorial blog based off kongondo's Blog module and this particular line caught my attention: $f = $modules->InputfieldCheckboxes; $f->name = 'vegetables'; // Set name to match attribute $f->id = 'vegetables'; // Set id to match attribute $f->label = 'Vegetables'; $f->description = 'Please select some vegetables.'; $f->notes = "If you don't eat your vegetables you can't have any pudding.";//<<<<<<<<<<<< $f->addOptions(['Carrot', 'Cabbage', 'Celery'], false); $form->add($f); Very funny... 😁
  20. 2 points
    Thank you Ryan. Have a great weekend.
  21. 2 points
    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.
  22. 2 points
    Your text is a string, not an object That's what the error is about. You can use PHP's DOMDocument Class and the method getElementsByTagName(). Here's a tutorial (with a h2 example :-)): https://codingreflections.com/php-parse-html/ I am not sure about performance issues with the class if it has to parse lots of text/HTML.
  23. 2 points
    @xportde, the ouput is trimmed of whitespace because the field render makes use of TemplateFile::render and by default the trim option is set to true. /** * Trim leading/trailing whitespace from rendered output? * * @var bool * */ protected $trim = true; There's no built-in way to change that setting in the render() call but you can change it with a hook if it's important: $wire->addHookBefore('TemplateFile::render', function(HookEvent $event) { $tpl = $event->object; if($tpl->field && $tpl->field->name === 'your_field_name') { $tpl->setTrim(false); } });
  24. 2 points
    Hi Robin - thank you for your improvement on that. I guess there is a typo in CustomInputfieldDependencies.module @Line 52, the comma breaks the installation… $this->hideInputfield($inputfield, $field,);
  25. 2 points
    @digitex, thanks for alerting me to this issue. I've made a change in v0.2.0 that should solve the issue. A note for all users of the module... Before v0.2.0 the Custom Inputfield Dependencies module did not render an inputfield in Page Edit if it determined that the inputfield should be hidden. But this creates problems if the inputfield and its neighbours have column widths of less than 100%. So from v0.2.0 onwards hidden fields will be rendered in Page Edit and hidden with CSS, so effectively the same type of hiding as occurs with the core inputfield dependencies feature.
  26. 2 points
    Could you share some code? This is a good guess. You need to keep track of your pagination somewhere and pass it to the selector like "text%=$q, start=$currentPage, limit=10"
  27. 2 points
    Hello fellow ProcessWire people! I published an article explaining how I migrated three years worth of running data from Garmin to ProcessWire: https://francescoschwarz.com/articles/running-on-my-own/ Have a great day! Cheers.
  28. 2 points
    Hi @AndZyk - please try the latest version just committed.
  29. 2 points
    My bet, it's spam, they are totally trying to extorque bitcoin. It look like an automated message. And from what we can read from there on Internet, they are sending this message to owners of google blogs 😂 and we know that for hacking a google blog, they require your google account, which I doubt it was hacked. Anyway, you can look at your file structure, DNS records, etc to see if something is weird but in every case, DO NOT PAY 👍🏼 I am quite confident to say that your are still safe 🙂 make your best poker face 😅
  30. 2 points
    Danke Bernhard 🙂 This Lighthouse score, built in in Chrome/Chromium. Look in DevTools -> Audit. Seems a very good idea. Will try that! well, I use/need sourcemaps in dev more than in production. But sourcemaps are not the bottleneck. The thing is: This is my standard gulp setup and it is usually so fast that I cannot even see the refresh in the browser because my eyes cannot switch so fast from editor to browser 😉 Purging is only done in production builds. And yes, I am using the purging in tailwinds config like this: module.exports = { purge: { content: ['./src/*.php', './src/**/*.php', './src/php/*.php', './src/fields/layout/**/*.php', './src/fields/layout/parts/*.php'], options: {...} } } In dev the whole tailwind declarations are used (2MB css file). BUT: This is it! Thinking about it it doesn't make sense to bundle everything (including Tailwind) up in development and distribute one (large) CSS file. It would be better to distribute the Tailwind CSS as it is in dev and only process my own css/stylus files like I always do. Will try that. Thanks for the rubber duck debugging 😬 yes, this is the other major problem. I really don't see why this just doesn't work. I already quoted the tailwind config above and you see I already tried to add more sources and be more specific, but somehow a lot of the classes just don't get recognized. Problem is the first time I purged or better tried to purge the project already was pretty complex. So I have no clue which classes are missing and why. I will try to set up a test case with an empty PW installation and then try to observe what the problem is. But thanks for pointing out that it should work even if the classes are not in a proper HTML syntax.
  31. 2 points
    And it's also unique AFAIK in being the only module in the directory that doesn't have a support thread, which isn't great because it causes questions to be scattered all across the PW forums. And potential users should probably interpret the absence of a support thread as meaning "you are on your own if you use this module".
  32. 2 points
    You can add support for Repeater Matrix Fieldtypes via custom third-party modules. Refer to documentation on how you can create one. https://github.com/dadish/ProcessGraphQL#third-party-fieldtypes-support
  33. 2 points
    In my humble opinion, that module is too broken to use and hasn't seen any updates since 2017 😞 Either use the new Pro version, or code something from scratch yourself.
  34. 2 points
    Quoting myself here, but just wanted to add that they do indeed have a solution for this 🙂 ... so if you're using purge as defined in the Tailwind config file you need to make sure that NODE_ENV is not production when you're doing your dev build.
  35. 2 points
    The modules directory issue is now fixed. @eydun, note that this is not a module support thread, so I've moved it to the General Support area of the forum. "Modules/Plugins" area is reserved for module-specific support threads, one per module.
  36. 2 points
    Man Ryan. This just phenomenal. Truly great job.
  37. 2 points
    $wire->addHookBefore('InputfieldFile::fileAdded', function($event) { /** @var InputfieldFile $inputfield */ $inputfield = $event->object; $page = $inputfield->hasPage; if($page && $page->template == 'your_template') { // ... } });
  38. 2 points
    @schwarzdesign, I agree with your suggestion in the GitHub issue, but in terms of working around it double-check that you have the HTML Entity Encoder textformatter applied to the title field (it is by default after installing PW, and should be applied to all plain text fields). Because with that applied I don't experience the issue on a clean PW installation:
  39. 2 points
    This is unusual. How does your setup look like?
  40. 1 point
    Thanks! I wanted to start small and simple. I like that a simple version of the charts also works without any JavaScript. As I want to also link to specific runs, this seems to be quite cumbersome with ChartJS. Working directly with SVG feels a lot more robust and simpler for me in that regard.
  41. 1 point
    @Patrik97 Welcome to the forum. RepeaterPageArray object represents the value of a repeater field, related to the page where the repeater lives in. A single item of this PageArray is an instance of class RepeaterPage. The class is set via FieldtypeRepeater::getPageClass(). This value is not changeable, the function not hookable. If you want to use a custom class for your repeater item objects with additional methods or properties, you need to create your own Fieldtype, derived from FieldtypeRepeater which includes your custom class and overwrites the getPageClass() function. Example where exactly this is done: FieldtypeRepeaterMatrix Maybe related: https://processwire.com/docs/tutorials/using-custom-page-types-in-processwire/ https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes https://processwire.com/talk/topic/20593-pageclasses-and-php-classes/
  42. 1 point
    Yes, but it's not streamlined and also not in the docs. Just grab the tabulator instance (open devtools and inspect RockTabulator variable) and do whatever you want with it 😉
  43. 1 point
    I just wanted to let you know I ran into an unusual error message with PW 161 revolving around selectors. I was getting a strange popup whenever page creation was operating - stating there was an invalid selector : | I uninstalled and then reinstalled the plugin and the problem went away. Not entirely sure why that would happen (I clear compiled files, cache etc) Just thought I would put a note here in case you were able to replicate the issue. I was upgrading from 160 to 161 and I know Ryan was doing a lot of selector work.
  44. 1 point
    Yes. The admin warns you about this when you define a "required if" condition for a field inside a Repeater: @ryan, it would be nice though if this limitation was mentioned in the relevant section of the inputfield dependency documention. More information: https://github.com/processwire/processwire-requests/issues/262
  45. 1 point
    Looks like @ryan just upgraded the modules site from PW 2.x to 3 and that has caused something to break. I no longer have access to the admin so I can't see what the cause of the error is, but hopefully he'll read this 🙂
  46. 1 point
    Hey, using the module for the first time. Great work! I don't know if there have been any requests, but is ist possible to make the module work with "Repeater Matrix Fieldtypes"?
  47. 1 point
    Right — looks like I skimmed too quickly over this part. Was also pretty sure that I had tested this before, but you're right that it doesn't seem to work at the moment. Thanks, I'll take a closer look soon!
  48. 1 point
    Actually it sounds like your search_index field could be single-value textarea, instead of textarea (multi-language). If so, you'll have to change the type of the field manually. Could you check if this is the case? Either way I should probably add some extra checks to make sure that this doesn't happen.
  49. 1 point
    Change Default Language to be None-English | Walk Trough When you start a new (single) language site and the default language shouldn't be English, you can change it this way: Go to the modules core section: Select the Language ones by the filter function: We have four language related modules here, but for a single language site in none english, we only need the base module, named "Languages Support". So go on and install it. After that, you can leave it, ... ... and switch to the newly created Language section under SETUP: Select the default language Enter your new language name or its Shortcut and save the page. I will use DE for a single language site in german here as example: Now I go to the ProcessWire online modules directory, down to the subsection for language packs and select and download my desired (german) one: After downloading a lang pack as ZIP, I go back into my SETUP > LANGUAGES > default language page in admin, select the downloaded lang pack ZIP and install it: After the ZIP is uploaded, the files are extracted and installed, most of my screen is already in the new default language. To get all fully switched, we save and leave that page, ... ... and completely logout from the admin. Now, of course, we directly login back, ... ... and see, that now also the cached parts of the admin have switched to the new default language. 🙂 That was it for a single language site in none english. If you want to have a multi language site, just add more languages to the SETUP > LANGUAGES section. When using a multi language site, I think you also want to use multi language input fields, and maybe different page names for your language page pendents. If so, you need to go into MODULES > CORE > filter LANGUAGE and install what you need or want to use of it, (if not already done). Thanks for reading and happy coding, 🙂
  50. 1 point
    Hi, With the deprecation of Instagram's API and therefore the end of the Instagram Feed module, I've developed a replacement module which uses the Instagram Basic Display API: https://github.com/nbcommunication/InstagramBasicDisplayApi To use this module you'll need: ProcessWire >= 2.7 A Facebook Developer account Access to the Instagram user account you wish to use Prior to installation, you'll need to create a Facebook app. The app you will create uses the User Token Generator for authentication - it does not need to be submitted for App Review (and therefore stays in Development mode). The README contains full instructions on how to create and set up the app and also how to use the module. The primary reason for this module's development was to retain functionality on existing websites that use the Instagram Feed module. To assist with upgrading, this module replicates some methods provided by Instagram Feed. I've already upgraded a couple of sites and it was quick and painless 🙂 Cheers, Chris
×
×
  • Create New...