Jan Romero
-
Content count
196 -
Joined
-
Last visited
-
Days Won
2
-
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); } });
-
I would like to take issue with this as well. It’s awkward for non-superusers not to find pages (or other users) they can otherwise reach, and I don’t really see why this restriction is in place by default. It is also not easy to implement a hook to change this behavior, which would be trivial to do the other way around. I.e. if the “include” parameter weren’t overridden by the Process function, that feature could be retrofitted like so: wire()->addHookBefore('ProcessPageSearch::executeFor', function($event) { if(!$this->user->isSuperuser()) wire()->input->get->include = 'hidden'; }); As well as any other custom restrictions one might need to respect custom roles and permissions. However, as it is now the restriction is hardcoded into the function and I’m not sure how to modify it in a non-destructive manner. Are there security reasons for the way it’s currently done?
-
That UI is fricken genius. I love it. Very convenient that I can like it twice now lol
-
For your autoload scenario I’ve been doing something similar, but I execute the job via Ajax. That way it doesn’t impact the page load. It’s an extra request, but should go unnoticed by your visitors since you don’t need to wait for a response. Sorry this doesn’t answer your question specifically, but I thought it might be applicable to your scenario. With regards to caching, ProcessWire will always execute even if it only serves a cached page. That is unless you use ProCache, which allows you to serve cached HTML without invoking PW.
-
You don’t need to call size() at all if you don’t want to resize the image. Also you don’t seem to be entirely familiar with PHP’s control flow syntax. Try this inside your foreach: if ($image->width <= 800) { //width is simply a property of type integer, in pixels $imgurl = $image->url; //use url of source image } else { $imgurl = $image->size(800)->url; //create a variation 800px wide and use its url } $images .= "<img src='{$imgurl}' />"; You may also be interested to know that there is a config option that prevents images from being upscaled. Have a look around in config.php’s image options. I don’t know if it’s some kind of special syntax you’re using for your if-condition, but here is the PHP manual just in case: http://php.net/manual/en/control-structures.if.php Sorry, I would format more nicely, but I’m on mobile :/
