Leaderboard

https://flaviocopes.com/page/ebooks/ I am in the middle of reading his The JavaScript Handbook which is great to get up to speed in the additions of the language added in the last few years. This is a no-nonsense, easy to understand, from-a-programmer-to-programmers book, highly recommended ? All six titles: The JavaScript Handbook (171 pages) JavaScript from ES5 to ESNext (84 pages) The React Handbook (220 pages) The Node.js Handbook (189 pages) The Express.js Handbook (61 pages) The Vue.js Handbook (122 pages) Happy coding ?

Hi, With the introduction of GDPR regulations, many of our clients with "webuser" systems we've developed need a way to email users that haven't logged-in in a while (18 months seems to be the standard) to ask them if they still want their user account. For most of the systems we've developed, we've added a field to the user template which records the time when the user logs in, so we'll be able to develop this functionality. It got me thinking, would this be a welcome addition to the core, accessed in a similar way to created/modified dates e.g. $user->lastlogin? Were it to be implemented, it would be useful to be able to 'silently login' if using $session->login($username, $pass) or $session->forceLogin($username), in the same way you can bypass save hooks by passing in an option to $pages->save(). Cheers, Chris - NB Communication

I agree. Let's put it in the meta group. ? There is also no need to setup default values for the canonical url, it always equals the page's url unless overridden.

I am not the right person to really comment on this given that the only abilities I have in a second language is a smattering of travel Spanish, but this does seem pretty cool and makes you sound a lot less silly ? DeepL Google So, a DeepL module sounds like a pretty cool idea to me.

Aha, great that you have found the source of the issue. In terms of a bug report, I don't expect anything can be done to guarantee to always successfully remove the temp status in all circumstances - I guess there can always be upload glitches of one sort or another. But what would be helpful is to make sure that files with temp status are removed when a page is (re)loaded in Page Edit, so you are not scratching your head wondering why you can see an image in the field that isn't accessible from the API. The thing is, I thought this already happened, which is why if you upload an image then refresh without saving the image is removed from the field. So I suppose it could be a matter of working out why an image with temp status is remaining in the field and is not removed.

Ok, so I've done some tracing to see what is going on and it's because the files are being tagged as temporary. This is the key line: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Fieldtype/FieldtypeFile.module#L411 that is causing it to return null. When a file is added, it is initially set to temp: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/core/Pagefiles.php#L347 so I guess for some reason the file upload process didn't complete properly so the temp status (timestamp) wasn't updated. Thing is that the files are fully uploaded and there is nothing wrong with them. I just manually changed the created dates in the database, via Adminer of course ?, and now everything works as expected. @Robin S - you seem to be the expert in issue reporting these days - any thoughts on the best way to handle this to explain best to Ryan?

Since I'm a software guy myself, I prefer reporting only if I am able to provide steps to replicate the issue. Since I couldn't find any rules for this one yet, so decided to stay quiet. Maybe not the best choice... Regarding the multi-language feature I probably can check If I had this on one of my single-language sites (easy, just check for single file fields set to return an array).

Wow... good to see there is someone else who needs this as well. My personal preference would be: right in the meta group after keywords. By now I think creating a new group seems to be kind of an overhead. We could argue about semantics and meanings but having this option almost above the fold seems to be a much nicer user experience.

"Deepl" is an unbelievably good (paid) text translation service, that mops the floor with Google Translate. They have an API and it would be awesome, if there would be a module, that would integrate it for easy content translation. It could be a right-click context menu on the language tab: It should ask from which of available other language it shall take translate from. What do you think?

If the page you are loading in the iframe is on the same domain as your site you can get the title by finding it within jQuery contents() - google it for details. If the page is not on the same domain then you cannot get the iframe contents (and therefore the title) via Javascript. You could get the page contents via PHP (e.g. PW WireHttp) and use DOMDocument or similar to find the title, but the simplest thing might be to use an external API like http://textance.herokuapp.com/index.html Would be smart to cache the title for a while with WireCache.

$c = 0; foreach($item->images as $photo){ echo "<li uk-slideshow-item='$c'><a href='#'><img src='{$photo->size(150,100)->url}' alt=''></a></li>"; $c++; } just use a good old counter var instead ?

@Robin S - actually, I think you might be correct in this case. That was my initial thought, but some recent changes I made to Tracy should have actually prevented that error, so it threw me off. So I think it might be a combination of an older version of Tracy and the disabled in modal option. I agree that the defaults should be for Tracy to be on in all those modals/panels/iframes - I have made this change in the latest version.

You would need to exclude by ID withing the children selector or else the first page of $news_archive would be an unequal quantity (or empty depending on the value of feed_count_full) because pages would be filtered out after they are found. $news_archive = $page->children("template=news, id!=$news_full, limit=50"); If all of the results are appearing on the same page (no pagination is used) then you can achieve it without needing a second DB query... $news = $page->children("template=news"); $news_full = $news->slice(0, $page->feed_count_full); $news_archive = $news->slice($page->feed_count_full);

It wasn't working when I checked shortly after the OP posted - the "/about/" portion of the URL was missing IIRC. Must have been fixed since then.

@bluellyr, your screenshot shows a modal. Make sure you do not have the Tracy debug bar disabled for modals in the module config: @adrian, I wonder if it would be better to not have Tracy disabled for modals by default, and people can disable it if they are finding the debug bar annoying. And perhaps spell it out that no debug bar = errors if you try and use a dump method.

Use $item->images instead of $product_gallery->images in your inner foreach loop.

Hi there! Backup your database and try changing database table collations to utf8_swedish_ci. In addition this solves some sorting issues with words starting with Å, Ä or Ö.

The changes Ryan made were to ensure that Tracy is always the first "site" module loaded. This means you can always debug other site modules. Getting Tracy to load earlier is problematic. init.php won't help - it already loads on init. I would like to be able to load Tracy earlier, but I don't see Ryan being keen on doing what is required to make that happen. You have got me thinking though about figuring out how we might be able to at least get bd() working earlier - this wouldn't include all of Tracy's other error capturing / reporting abilities, but I think it would still be helpful. I'll have a think about it.

That's currently the way it is implemented. If there's no limit given, then PW ignores the offset (for the curios, it's implemented in PageFinder::getQueryStartLimit). It makes sense from a database point of view since MySQL's LIMIT keyword always needs a row count. So your approach is the correct one. You could perhaps use a reasonably high number (like MySQL's maximum unsigned integer, 18446744073709551615) for your limit. If you don't want to have to remember the value, just put it intosite/config.php like "$config->maxDbLimit = 18446744073709551615;" and then use "limit={$config->maxDbLimit}" in your selector.

It often happens to me too. I know Ryan made some adjustments in the core so that Tracy is loaded earlier (if I remember correctly), but is there really nothing that could be done in that regard? Could we have some sort of bd() function always available? Independent of the modules load order? Something that we put in init.php, even index.php? Yes, I do use $log methods, but Tracy is very handsome and good looking ?

@szabesz - that is the temp status we are talking about. Given that @Robin S has started an issue on this, I will let him follow up.

@Roberts R - that WYSIWYG card links to: https://processwire.com/about/what/#comprehensive and it works fine for me. Can you explain a little more about what doesn't work?

Thank you, for the explanation and for the alternative. All the best

I don't see any such link. pw.com belongs to PricewaterhouseCoopers LLP anyway o_O

Regarding the temporary state, are we talking about this bunch of issues? https://github.com/processwire/processwire-issues/issues/650 https://github.com/processwire/processwire-issues/issues/42 https://github.com/processwire/processwire-issues/issues/41 If so, then this part of the core might need some refactoring.

Without steps to reproduce I doubt Ryan could/would do anything about it. Might be best to wait until you notice it again in a situation where Custom Upload Names is not involved and raise an issue then. I do think it's odd that the formatted/unformatted value should be different with regard to temp files - I'll open an issue for this. Edit: issue is here.

Good find, thanks. Needed to upgrade my javascript coding.

I know how this feels. I'm sure there is some core issue with the admin login that semi-regularly gives me CSRF errors when I attempt to log in but I haven't been able to isolate the conditions to reproduce it - my gut feeling is that it's something to do with an expired cookie. I'm always in a hurry when it happens so I just back button and resubmit the form. To get to the bottom of your issue I expect it could be traced by dumping within the chain of methods that get the data from the database and ultimately deliver the formatted value. But who has time for that when you're on a deadline?

Thanks for the report - looks like the new Tracy core is forcing strict rules in JS which is affecting some sloppiness in my code. I have fixed this one, but I think we'll need to lookout for issues like this.

For my project I need an implementation of Basic Auth, so I added a new option 'Basic Auth' available in the module config : and then, in the Router.php file, method handle(), I added the following code : // Basic HTTP Authentication if($authMethod === 'basic' && $routeNeedsAuth) { $authHeader = self::getAuthorizationHeader(); if(!$authHeader) { self::displayError('Bad Request', 400); } $hash = base64_decode(substr($_SERVER["HTTP_AUTHORIZATION"], 6)) ; $authHeader = explode(':', $hash, 2); if(!isset($authHeader[0]) || !isset($authHeader[1])) { self::displayError('No Authorization Header found', 400); } $credentials = new \StdClass(); $credentials->user = $authHeader[0]; $credentials->pass = $authHeader[1]; RestApiHelper::checkAndSanitizeRequiredParameters($credentials, ['user|selectorValue', 'pass|text']); $loggedin = wire('session')->login($credentials->user, $credentials->pass); if(!$loggedin) { self::displayError('user does not have authorization', 401); } } and in the method getAuthorizationHeader() I added : if(array_key_exists('php_auth_user', $headers)) return ['user' => $headers['php_auth_user'], 'pass' => $headers['php_auth_pw']]; It works, but does it make sense ? Edit: Pull Request : https://github.com/thomasaull/RestApi/pull/3

@bernhard nice! I'll update the tutorial (done now) and point to this module. I haven't had much time at ll to work on that site, been so busy trying to learn enough skills to call myself a dev one day...

Sorry for bumping and old topic... but it seems there is still no language-module features for swapping languages with the default? I had this issue and found that dealing with PW databases was the fastest route for me: To swap language strings repeat this SQL for each multilanguage field: UPDATE field_FIELDNAME s1, field_FIELDNAME s2 SET s1.data = s1.data123, s1.data123 = s2.data WHERE s1.pages_id = s2.pages_id; FIELDNAME is your fieldname in PW and data123 is the column name for the language your are swapping the default for. Just check any multilanguage field table to see the correct column name. Finally to swap page names run this SQL: UPDATE pages s1, pages s2 SET s1.name = s1.name123, s1.name123 = s2.name WHERE s1.id = s2.id AND s1.name123 IS NOT NULL Obviously it is risky to tamper with databases, but this approach saved me lots of work with a big site with reasonably few fields. The language-module should have this sort of swappery built-in.

I upgraded jQuery from 1.8.3 to 1.12.1, jQuery UI from 1.10.4 to 1.12.1, datepicker.js from 1.6.1 to 1.6.3 and updated longclick.js from 0.3.2 to 0.4.0 and it works just fine (after few quick tests). Then I tried jQuery 3.2.1 and jQuery Migrate 1.4.1 and it's working too (Migrate is required). jQuery 1.8.3 is released in november 2012. It's nothing wrong with that old version, but it just doesn't fit in the incoming new stable version of PW...

When your requirements exceed what native modules can offer, then, yes you need to implement an Inputfield too. Just use an inputfieldtextarea and show a json of your field data until you start developing your specialized Inputfield.

u.can removal this lines >>> Header always append X-Frame-Options SAMEORIGIN