Jan Romero

Tbh, I find this whole “virtual field” business somewhat unfortunate… The announcement of custom image fields filled me with joy, and I thought the idea of using templates seemed pretty ingenious (although I don’t like how it introduces magic strings into template names, and generally restricts their naming, and doesn’t allow multiple image fields to share a template. Feels icky to me. Why not have a template selector in the field settings?). However, I was disappointed to find that values are just serialized and dumped into the image-field table. Seems like this data is treated as some kind of second-class citizen. If the custom fields were stored in their own database columns, as suggested by using templates and fields, it would have been a trivial INSERT to migrate from the ImageExtra module. Now I needed to use the PW API to move values from one field to the next, which involves all kinds of voodoo behind the scenes. Wouldn’t it be much less work to just store a page reference with each image and have the custom image fields stored in their respective field-tables? Surely that way it would be easier to make everything play nicely with selectors and everything? Of course, I have to admit I don’t have a lot of MySQL experience. Maybe there are easy and performant and reliable ways to query serialized fields like this and I just need to read up a little 🙂

@webhoes yeah, your javascript wants to put the search results into the element #content, and you don’t have one. If you add id="content" to your container div, it works. The search is doing something weird though. It will only find whole words, so if I look for guitars, the “g” gives me “Marshall MG 10 G Combo”, then everything disappears until I finish “guitar”.

In accordance with the gist identified by Kongondo, I’ll comment that I figure most of the complexity will probably lie in your envisioned front-end. I’m certain that PW will work just fine as far as it is concerned, but it won’t help you any displaying a zoomable map and all that. This is an ambitious project if you’re really going to involve native mobile apps and payment processing. I would probably suggest keeping it simple for now, and just worry about getting your data from the user to your database and back. Working with data and users is pretty much a breeze with PW. While there may be more suitable products for your particular use case (you’d have to ask someone more broadly versed), I wouldn’t worry about the ProcessWire side of things too much. It’ll probably the part you’ll need the least help with. My tip would be to look into front-end people if you really are looking to hire. I should mention that my personal MO online is Hemingway-inspired, i.e. post drunk, browse sober, and right now I’m, like, really posting.

Indeed. I just upgraded an old site from 2.7.2, *cough*, and MySQL complained about some query on the edit page. Turns out this module failed to get the name of the path history table, and then it just goes “from where pages_id”. The problem appears to be that it uses constant() to get PagePathHistory::dbTableName, but that has long since moved into the namespace ProcessWire. It seems to work fine once you remove line 74 here and replace it with: $this->dbTableName = $this->wire('modules')->getModule($moduleName)::dbTableName; At least, that’s the quickest fix. Sorry for unearthing this old thread…

I don’t know your site, but wouldn’t you want to count only the siblings whose templates are also in $preventTpls?

Well, uh, FWIW I’ve encountered a problem today that may or may not be similar. My backend sessions were working as fine as ever, but users on the frontend would get logged out immediately after logging in. Basically, they would get their welcome page but their next request would fail. After disabling Session Handler Database sessions would persist nicely. Now when I saw you mention the Multilanguage setup, I had a look at my prepend file, where for some reason I can’t really remember I had put this: $session->language = $user->language; I’m sure once upon a time this fixed something about Language settings getting lost in between requests or something, but apparently it doesn’t play nice with the Session Handler Database module. So after removing that line everything is back to normal, DB sessions enabled and all. I have no idea about the mechanics behind the effects I’m observing here, unfortunately, but I thought I’d throw it out there, I guess.

Actually, I just experienced this “problem” where I’m saving an image field using $page->save('images') and even in non-quiet mode it didn’t invalidate the one-week template cache. That’s on a 2.7.2 installation. So the answer to your question seems to be Yes, it does prevent the cache from being cleared. I’m putting “problem” in quotes because I don’t really care one way or the other in this particular instance, but my user got confused (as always with caching).

Am I the only one who got turned into a spice girl by the upgrade? Somehow it didn’t migrate my latest pic but the one I had up until a couple of weeks ago?

Sweet site! From https://processwire.com/api/selectors/: ProcessWire 3 contains a workaround for this, but you should be able to build it into your search code by checking for such short words and handling them with a the %= operator.

Why don’t you do the three database finds after building the selector? I would imagine that to speed things up, because you won’t be loading as many pages just to throw them out later. Instead of slicing the PageArray you can also put limit and start into the selector like so "start={$start}, limit={$limit}". Edit: Actually, maybe I’m missing something, but it looks like you’re getting ALL horse-notes in $notes_other. I’m also pretty sure that PageArrays automatically filter out duplicates, so when you prepend the other two PageArrays, you’re not really doing anything.

ProcessWire trims and escapes selector values, so this doesn’t seem possible with pure PW selectors. You may try something like this… $query = wire('database')->prepare('SELECT pages_id FROM field_postcode WHERE data like concat(:areacode, " %")'); $query->bindValue(':areacode', 'A1', PDO::PARAM_STR); $pages->executeQuery($query); $results = $query->fetchAll(PDO::FETCH_COLUMN); $pages_matching_ = $pages->getById($results);

I’m not on 3.0, but I figured I’d just swap out the function and it’s working fine. Users still won’t show up even if you’re allowed to edit them, but that seems to be a separate issue I opened on GitHub.

The redirection is probably the most problematic part of this plan, because the new page load will interrupt the visitor’s typing. What you would want to do is keep the search box and simply change the rest of the page using javascript. If the browser supports it, you can use history.pushState() to do manipulate the address bar, so visitors can have bookmarkable links to their search results. Here is a crude solution using jQuery. As you can see, JavaScript does most of the work: Normal page looks somewhat like this. There is a search box and some unrelated content. <body> <form id="searchform" method="GET"> <input type="text" name="s" value="purple unicorns" /> </form> <div id="content"> <!-- Your regular content stuff goes here. If the user starts typing, we replace all of this with a placeholder, do the search, then replace it with the results. Of course you would want to do something a bit more sophisticated and pretty in real life. --> </div> </body> Some JavaScript that runs on the above page and requires jQuery. $(document).ready(function() { $('#searchform :input').on('input', function() { $("#content").html('<h2>Loading…</h2>'); loadSearchResults(function(result) { if (result === false){ result = '<h2>An error occurred.</h2>'; } if (result == '') result = '<h2>No results found.</h2>'; $("#content").html(result); }); }); function loadSearchResults(callback) { var form = $('#searchform :input[value!=""]'); var serialized_form = form.serialize(); //if your search field is named “s” this will be “s=search words” if (serialized_form !== '') { var new_url = '/search/?'+serialized_form; //consequently, this will be „/search/?s=search words“ if (/* IE9 needs this check */ history.pushState) history.pushState({}, '', new_url); //your address bar now shows www.example.com/search/?s=search words $.ajax({ type: form.attr('method'), url: '/search/', data: serialized_form, success: function(result) { if (callback && typeof(callback) === 'function') { callback(result); } }, error: function() { if (callback && typeof(callback) === 'function') { callback(false); } } }); } } } The search page /search/ handles a GET parameter called s and either serves a full results page, or just the markup necessary to inject it into existing pages. <?php $s = $input->get->text('s'); $results = $pages->find("title%={$s}, limit=100"); $results_markup = "<h2>{$results->count} results found for “{$s}”:</h2>"; $results_markup .= "<ul>"; foreach($results as $r) { $results_markup .= "<li><a href='{$r->url}'>{$r->title}</a></li>"; } $results_markup .= "</ul>"; //if we’re live-searching, output only the results markup, //without <html>, <body> etc. if($config->ajax) { echo results_markup; return $this->halt(); } //now do your regular markup include('head.inc'); echo $results_markup; include('foot.inc'); ?> IRL you would probably serve JSON instead of full markup, but this keeps the JavaScript part short. You would also want to handle cases where users use the live search and then hit their browser’s back button.

I don’t see why not, although I have no experience with the Custom Files module. You could just hook into ProcessPageEdit from your admin.php. Here is a more complete example: $wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) { $tableField = 'product_features'; $changeColumn = 'feature_value'; $disableColumn = 'custom_value'; $event->return .= ("<script> $(document).ready(function() { $('#wrap_Inputfield_{$tableField} input[name$=_{$changeColumn}]').on('change', disable_my_field); function disable_my_field() { //probably not the best way of finding our target field… var disableThis = $(this).parent().parent().find(':input[name$=_{$disableColumn}]'); if ($(this).val() == '') { disableThis.prop('disabled', false); disableThis.parent().css('background', '#f0a'); //color just for better visibility } else { disableThis.prop('disabled', true); disableThis.val(''); //clear field disableThis.parent().css('background', '#ff0'); } }; //call the function once to affect existing rows //can’t get this to work for some reason disable_my_field.call($('#wrap_Inputfield_{$tableField} input[name$=_{$changeColumn}]')); }); </script>"); }); It’s not quite there yet, but it works pretty well. Seems quite useful actually. I might use this myself sometime. You can of course use the same principle to pre-select options based on another column. You may want to look into this thread: https://processwire.com/talk/topic/2331-doing-additional-logic-after-saving-a-new-page/. It’s a bit old, though.

I think Profield Table is still your best bet for this functionality. In order to conditionally disable the third row you would inject a bit of jQuery into the edit page. Per ejemplo: $('#wrap_Inputfield_features input').on("change", function() { if ($(this).val() == '') { $(this).parent().next().css('background', '#f0a'); $(this).parent().next().children('input').prop('disabled', false); } else { $(this).parent().next().css('background', '#ff0'); $(this).parent().next().children('input').prop('disabled', true); } });