BitPoet

That would probably the relevant part that we would need to see to make an educated guess. Does the script perchance replace the Pageimage object assigned to sku_image with an empty one?

Looks like you need to include jquery in your page (see point 4 in the lightbox2 getting started docs).

Is your include file namespaced? If not, throw new \ProcessWire\PageNotFoundException(); should do the trick. Or adding "namespace ProcessWire;" at the top, obviously.

Perhaps PW's core PagesExportImport fits the bill there. The result is quite verbose and more nested though since it includes everything needed to recreate a page. $myPages = $pages->find('template=catalog-item'); $PEI = new PagesExportImport(); export $PEI->exportJSON($mypages); To get array data instead of a JSON string, call pagesToArray instead of exportJSON.

Nginx' performance advantages over Apache were built on three factors: modern-day multiprocessing in the server, a lot less overhead due to reduced functionality and memory caching. Over the last five years, Apache has greatly reduced that gap by adapting Nginx' multiprocessing approach (one keyword there is the event MPM module), so Apache isn't spending most of its time spinning up and tearing down whole server instances anymore. File system access has greatly improved with solid state disks, too. Apache still has a lot more functionality, and its distributed config file approach, most prominently the ability to make configuration changes with a .htaccess file inside the web directories, hurts performance. Its dynamic module loading approach and the dozens of pre-installed modules most distributions ship also take up processing time and memory. Nowadays, Apache can be stripped down a lot and compiled to be head to head with Nginx, though few actually care to do that, since it also means removing functionality one might need in the future. A stock Apache is usually still quite a bit slower and reaches its limits faster (about the factor 2). This becomes an issue under heavy load or on slow machines. Where Nginx still shines brightly is load balancing. Apache can do it too, but with Nginx it is straight forward and well documented, having been there for a long time. For those interested in a bit of (highly subjective) history: for a long time (speak eighties and nineties), the classic forking mechanism that was common on *nix OSes was the way to do multiprocessing in network servers, and therefore in Apache too. This meant spawning a full copy of the server process and initializing it, then tearing it down when the request was done. Apache brought a small revolution to that approach by implementing preforking, meaning to keep spare server instances around to fulfill requests with little delay. After a while, there were other approaches too when faster multiprocessing approaches become part of common operating systems, like multi threading, which is supported by Apache's "worker" multiprocessing module (MPM). There were, however, big caveats with using other MPMs. Since file systems used to be slow, sometimes awfully so, in the old days, and since the classic CGI approach of starting an executable from the file system, supplying it with information through environment variables and standard input and capturing its standard output was a security nightmare - even without thinking about shared hosting - nifty programmers included full languages interpreters inside Apache modules. mod_perl and mod_php became the big thing, the latter coming to dominate the web after a few years. These interpreters, though, often had memory leaks and issues with thread isolation, meaning at best that an error in one thread tore down numerous other sessions and at worst that the server had a propensity for information leaks, remote code execution and privilege escalation attacks, the former security nightmare squared. Thus, these tightly integrated interpreters more or less locked their users into the classic prefork approach where every instance is its own, basically independent process. With PHP as the market leader not evolving in that regard, things were frozen for quite some time. This was when Nginx conquered the market, first by serving static HTML and associated resources with lightning speed (CMSes generating static HTML were still a big thing for a while), but soon by taking care of all the static stuff while handling the dynamic things off to Apache and caching parts of its responses in memory. Finally, though, PHP finally got a fresh boost and grew stable enough for its engine to re-use interpreter instances. It was easier to contain things inside an interpreter-only process instead of dealing with all the server peculiarities, so FastCGI daemons finally became stable, known and used, and suddenly the need to have the language interpreter contained in the web server fell away. Apache got leaner and Nginx more flexible. Caching servers like Varnish became popular since it suddenly was relatively easy to build a fast, nice, layered caching solution with a combination of Nginx, Varnish and a full fledged web server like Apache or IIS, able to serve thousands of highly dynamic and media rich pages per minute. About that time, SSL grew in importance too, and hosting providers learned to love Nginx as a means to route domains to changing backends and provide fast and easily configurable SSL endpoint termination. Over the last years, Nginx got other features like generic TCP protocol load balancing that offset it from other servers and make it more into a one-stop solution for modern web applications. It does boost its popularity that Nginx is often the first (or the first major) web server to ship evolving technologies, making the front pages and pulling in early adopters, http/2 being one of the most prominent examples there.

You can do that in an onchange handler for your number input. The limit is stored in the data-multiplier-limit of a hidden input with an ID of "Inputfield_" plus the name of the fieldset and "__multiplier_rows". If, for example, your "No Of Users" field is named "usercount", adding this snipped at the bottom of your template should do the trick: <script> $('#Inputfield_usercount').on('change', function(evt) { var newlimit = $(this).val(); $('Inputfield_myinputs__multiplier_rows').data('multiplier-limit', newlimit); }); </script> This is untested, though. I'm heading out in a minute, but I'll take a closer look tomorrow. Did you add the "myinputs__multiplier_rows" label yourself? If not, then I missed to include the code to properly hide InputfieldHiddens in the module and need to fix that.

Unfortunately, I didn't have enough time to really brush up the module, but I have nontheless pushed it to GitHub and created a topic for my SlidingToggle Inputfield (and Fieldtype) in the modules section.

As threatened in Ryan's announcement for 3.0.139, I built a little module for sliding toggles as a replacement for checkboxes. Styling of the input is CSS3 only (with all the usual caveats about older browsers), no JS necessary, and may still be a bit "rough around the edges", so to speak, since I didn't have much time for testing on different devices or brushing things up enough so I'd feel comfortable pushing it to the module directory. But here's the link to the GitHub repo for now: InputfieldSlideToggle Fieldtype and Inputfield that implements smartphone-style toggles as replacement for checkbox inputs. The visualization is CSS-only, no additional JS necessary. Status Beta, use with caution Features / Field Settings Size You can render the toggles in four different sizes: small, medium, large and extra large. Off Color Currently, "unchecked" toggles can be displayed either in grey (default) or red. On Color "Checked" toggles can be rendered in one of these colors: blue (default), black, green, grey, orange or red. Screenshots Some examples with checkbox label View all Size and Color Combinations Small toggles Medium toggles Big toggles Extra big toggles

Not "easier", but fun to dive into: if you have MySQL >= 5.7.8, you could convert the page data into JSON and store that string in the database in an InnoDB table with a JSON column when you save the page. Then use MySQL's JSON_SEARCH function to get the hits and fields (paths). This only works with exact or LIKE queries, though, and you will have a little additional work to convert the returned paths to field names. Of course, you will probably still have to write the nested loops to get the data into the database. Not sure how much FieldtypeRepeater->exportValue() can help you avoid that. Table create statement example: CREATE TABLE jsonsearch ( pages_id INT NOT NULL, pagedata JSON, PRIMARY KEY(pages_id) ) Engine=InnoDB; Hypothetical page data for equally hypothetical page 1013 as stored in JSON: { "name": "vehicles", "title": "Our Vehicles", "data": [ { "type": "motorbike", "color": "blue" }, { "type": "car", "specs": { "colors": [ "red", "green" ], "subtype": "motorbike" } }, { "type": "bike", "color": "black" } ] } Query example: /* Get page id and fields where any field's value equals "motorbike" */ select id, json_search(jsondata, 'all', 'motorbike') as paths from testjson where json_search(jsondata, 'all', 'motorbike') is not null; /* Output: id paths 1013 ["$.data[0].type", "$.data[1].specs.subtype"] */ /* Get page id and fields where field's value contains "bike" */ select id, json_search(jsondata, 'all', '%bike%') as paths from testjson where json_search(jsondata, 'all', '%bike%') is not null; /* Output: id paths 1013 ["$.data[0].type", "$.data[1].specs.subtype", "$.data[2].type"] */ It also allows searching by a field name and by full and partial paths. /** * Search all "type" fields in the page's "data" array (repeater) for the string "bike". * This would find results with bike contained in a field data.type but not in * data.relatedvehicles.type */ select id, json_search(jsondata, 'all', '%bike%', NULL, "$.data[*].type") as paths from testjson where json_search(jsondata, 'all', '%bike%', NULL, "$.data[*].type") is not null; /* Output: id paths 1013 ["$.data[0].type", "$.data[2].type"] */ /** * Search all "type" fields at any level for the string "bike". * This would find results with bike contained both in data.type AND in * data.relatedvehicles.type */ select id, json_search(jsondata, 'all', '%bike%', NULL, "$**.type") as paths from testjson where json_search(jsondata, 'all', '%bike%', NULL, "$**.type") is not null; /* Output: id paths 1013 ["$.data[0].type", "$.data[2].type"] */ Converting the JSON path syntax back to something that makes sense for PW would just mean to json_decode() the paths value, cut off the first two chars and remove the digits within curly braces (though the numeric value are of course the index number for calling eq() on a Repeater/PageArray to get the individual item).

Ah, now I see. The script is missing the JQuery library (which is present in the backend). For a short term solution, it should be sufficient to add the following lines within the <head> section of your template: <?php $jq = $modules->get('JqueryCore'); ?> <script src='<?php echo $config->urls->JqueryCore . "JqueryCore.js" ?>'></script> I'll see about either making sure that jquery gets loaded by my module or rewriting the module script so it works without jquery in the long run.

What FormBuilder version do you use? I'll try to set up a test environment to see if I can replicate the issue. Meanwhile, do you see any errors in the browser's developer console?

Thanks for the quick feedback,the template embed method should work. Is your module, by any chance, installed in a directory named differently than FormBuilderMultiplier inside site/modules? If yes, updating to the latest dev version should solve the issue.

Sounds like the FormBuilderMultiplier.js script isn't loaded. Which embed method do you use for your form?

It's a breaking change in MySQL 8.0.16 that Oracle developers are refusing to list as such, as documented here. I guess Ryan will have to adapt the fieldtype's getMatchQuery code to keep things compatible. I have taken the liberty and opened an issue since this is going to bite me too soon. In the mean time, you could try replacing the line in question in FieldtypeDatetime::getMatchQuery, changing it from else $value = ''; to else $value = '0000-00-00 00:00:00'; and see if that works.

? for the width adjustment, this is a really nice feature that makes setting up new templates and changing them much more convenient! Funnily, I just implemented a toggle inputfield myself and thought, oh bummer, I could have saved myself the work! Turns out, you weren't talking about a sliding toggle like I am working on, and the core toggle field type is a nice addition for cases where the choices need to be more verbose than a simple yes/no and on/off. It'll come in handy for some of the forms I have in the queue. I will have to rename my module, though ? It'll be CSS only. I still need to add color and size options, and it'll hopefully hit the module repo at the end of next week.

You could employ PHP's flock function both in the code that updates your JSON file and the lazy cron script, though you have to at least consider how it will affect execution time for concurrent requests that have to wait until existing locks have been released. Rule of thumb: lock late, release early, i.e. try to perform all processing before you lock the file, then lock, update, release.

Use $event->arguments(0);

Didn't think of image variations (which you get when you resize/edit the image in CKEditor's image dialog), so that's the likely reason. @Robin S' solution should catch these too.

The first one is template syntax, the second one plain PHP. echo "<li><a href='{$parent->get('url_redirect|url')}'>{$parent->title}</a></li>"; // or: echo "<li><a href='" . $parent->get('url_redirect|url') . ">{$parent->title}</a></li>";

Also quite helpful in such scenarios is PW's page-edit-created permission that prevents editors from editing each others articles.

Here's a quick&dirty snippet: // Make sure to adapt the name to your image field here: $baseUrl = $page->images->url; $match = []; preg_match_all( '~<img[^>]+src=([\'"])(' . $baseUrl .'[^\'"]+)\\1~is', $page->body, // Adapt the name of your richtext field if not "body" $match ); $seen = $match[2]; // Again, adapt the image field name foreach($page->images as $img) { if(! in_array($img->url, $seen)) { // Output image } }

Doesn't the "~=" operator do what you want?

No "clean" way. The only, and not 100% reliable, way I can come up with would be to set the version number of the "local" version much higher than the official one.

Are your PHP script and the CSV file both in UTF8?

To me it looks like it should definitely be Spreadsheetname!1:2 since the API complains that it doesn't like writing outside of the given range. It likely behaves differently depending on whether overwrite is true or false, so it might not have popped up in practice (FormBuilder entries will be passed through appendRows). I'm going to run a few tests.