szabesz

I have become famous! ?

I'm only interested in models with a great "view": https://www.google.com/search?q=models&tbm=isch Don't even try to control them, youl'll fail!

https://stackoverflow.com/questions/28278705/always-populate-raw-post-data-trouble-accessing-request-payload-from-backbone?answertab=votes#tab-top I guess you are on PHP 5.6. Can't you upgrade to at least to 7.0.x?

https://github.com/rolandtoth/AdminOnSteroids/wiki/AddNewChildFirst

Also worth noting that there is a 7 page book related to the rejection craze of jQuery and other libraries: https://www.oreilly.com/programming/free/native-javascript-apis.csp Quotes: "If you’re using native APIs in your application logic, you can’t help but know what browser is being used because you need to account for browser differences. That means your application logic will always need to be updated as new browsers and new browser versions are released. That’s a recipe for disaster. ... You should absolutely be using a JavaScript library to abstract away browser differences for you. ... Libraries like jQuery, YUI, and Dojo abstract away browser differences behind facades, which allow you to focus on building your application logic in a browser-agnostic way. ... So, keep using your favorite JavaScript library. Don’t be tempted by the draw of native APIs simply because you can avoid downloading an external library. Using native APIs comes with a high cost of maintainability down the road." People write spaghetti code because they do not know JavaScript well enough and/or do not use appropriate design patterns, which is not jQuery's or other libraries' fault. One can just as well produce unmaintainable code by using any framework out there. Here is the case of UIkit 3 which relies on its own 132k JS library which is only partially documented: https://github.com/uikit/uikit-site/blob/feature/js-utils/docs/pages/javascript-utilities.md They say: "...allow you to write simplified Vanilla JavaScript and replace the most common functions of jQuery" So they got rid of jQuery by partially re-implementing its features. Good to know... Now if I add jQuery I have overlapping feature sets and the visitor of the site has to download more assets ? Is it an improvement? At the same time the current full version of jQuery (3.3.1) is 87k and one can use versions leaving out features not needed (say AJAX or effects if not used on a site), so it can further be trimmed if the projects allows. Introducing a mature and maintained JS library called JsViews: Currently, I have started to build upon a library which can either be used along with jQuery or without it: https://www.jsviews.com/ It is from one of the jQuery authors. Worth checking out the examples, eg.: https://www.jsviews.com/#samples/computed/team-manager JsViews can be used without precompiled JS templating – so it is easy to get started – and it is still very performant that way. One can also use a builder to precompile the templates if needed (think of the needs of overly complex JS apps and NOT websites). By using JsViews one can rely on declarative programming and build upon design patterns built in. By adding jQuery to it, code becomes shorter, easier to read and maintain.

Thanks for sharing! It is also worth noting the existence of something similar: http://modules.pw/

I told you Vivaldi a is good browser ? I wonder how you picked it, did you spot it on this nice tree? ?

+1 for Tabulator. I have not yet used it though but this is the one I like by reading the docs and seeing all those examples, so as soon as the needs arises I will surely use Tabulator as I could not find a better alternative for my usual needs.

260 pixel versions are generated by the admin, you need these there. 1024 versions must come from another source you somehow added to the system, so if you can identify its source, you can get rid of these. Here is a recent discussion you might be interested in:

Hello, do you need something like this: https://processwire.com/blog/posts/processwire-3.0.63-adds-client-side-image-resizing/ ? Or are you after something else? Can you please explain what you are referring to?

The relevant rules are explained in .htaccess: https://github.com/processwire/processwire/blob/master/htaccess.txt#L145 I recommend keeping these rules and pick a location which is not protected bye the default .htaccess file.

@Robin S has already provided us with hundrends of goodies, one of them this deals with it: https://github.com/processwire/processwire-issues/issues/70#issuecomment-258023285 same in the forum: https://processwire.com/talk/topic/1674-sorting-repeater/?do=findComment&comment=131713

All this issue is still muddy (as ususal....): https://www.i-programmer.info/news/81-web-general/12643-eu-copyright-directive-approved.html "This has been picked up by Florian Mueller on his Foss Patents site. In a post with the title, Even after today's EU Parliament vote, we can still kill Article 13 through pressure on German government to prevent formal adoption by EU Council,..." also: "As we've previously pointed out these concessions are very much open to interpretation leading to uncertainly that will undermine the Internet."

Have you tried this: https://processwire.com/talk/topic/45-url-schema/?do=findComment&comment=150 "ProcessWire will support .html extensions. You just have to make them your page names, i.e. "about.html" rather than "about", or look for them in urlSegments. I've actually done this before, though for specific pages (like /sitemap.xml), not on a site-wide basis. But I don't see any problem with it conceptually."

It is worth noting that in the music industry only the most popular artists gain money (and a lot), anyone else is left in the dust as no one cares when their creative work is "stolen". Probably the same mechanism will be put in practice in this case too. Copyright fee on blank CDs, tapes and such? These guys work hard to rip us off.

@happywire I think in the foreseeable future we cannot expect Ryan to change the way ProcessWire manages images so it is up to us to implement it the way we want to. As it is an "advance topic" I do not think it will be documented in details, except if we do it ourselves. One good way of doing it is how @bernhard wrote a great tutorial, which was happily published by Ryan in the blog: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ If you have the time to do your own research regarding this issue and ask others for more info then you might want to sum it up for us to in a similar tutorial. Most of us have their own way of managing images but this should not bother you, just do it your own way and help others by publishing it you have the time. ProcessWire pages under processwire.com/docs/ cover most what is needed for developers to get started but the blog articles often highlight even more, it's just that they are buried in there. Forum and Githubs issues also have a lot of information, but those are even more buried. However, I do not think that it will be possible to organize it all, so doing our own research is a must. Most of us perform custom goggle searches in order to dig into all these sources. The goos thing is that under the hood of ProcessWire things rarely change, so most things you are going to read in these sources are still relevant and work. However, the there have been major upgrade to images field, just search like: https://www.google.hu/search?q=image+site%3Aprocesswire.com For example: "In the new images field, they are now 260 pixels in the smaller dimension, scaled to 130 pixels (for HiDPI/retina support). The actual size and HiDPI support can be adjusted in config.php settings in $config->adminThumbOptions, though we think most will likely want to keep the default settings." https://processwire.com/blog/posts/major-images-field-upgrade/ So using gridSize it is possible to set the dimensions: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/config.php#L636 I do not exactly know how it should work though. When I set 'gridSize' => 100 and 'scale' => 1.0 then "1.0=force non-hidpi" should kick in, and in my understanding with this setting I should get images no bigger than 100x100 pixels. However, with this setting I get 200x200 pixels or less. Maybe it's me who does not understand the comment in the code. Also, there is this part in the comment: "1=allow hidpi, 0.5=always hidpi" which does not make any difference at all. In my case not matter what is set to scale, the admin thumb will always be twice the value of gridSize. It's not that hard, just sart by reading https://processwire.com/docs/modules/ and Bernhard's article.

I have a site where I also take advantage of this. I implemented a custom image process algorithm, whereby I check the extension of the uploaded image, rename it and after that create predefined variations (using Imagick) based on the aspect ratio and/or the dimensions. I put all this into a custom module which hooks into InputfieldFile::fileAdded, something like: $this->addHookBefore('InputfieldFile::fileAdded', $this, 'hookRenamePng', array('priority' => 10)); $this->addHookAfter('InputfieldFile::fileAdded', $this, 'hookCreateJpgClones', array('priority' => 10)); BTW, have you read this Github issue? https://github.com/processwire/processwire-issues/issues/703 it is somewhat related.

Thank you! I myself actually like the idea that the custom indicator is always visible. Thanks for reminding me. Strange but I've never had the need of them, bd() and d() have just been enough. Maybe it is because I tend to prefer very targeted checks.

Thanks for this and all your work on the other issues. I think the current sate is just good enough!

Cleaning all local data storage features of the browser nor incognito mode did not make a difference either, all issues remain. I have no browser extensions installed, btw. I tested the scrollbar and the tiny icon issues on a clean and "latest" PW (last week's 3.0.127) and they are still there in Chrome, so these do not seem to be site specific. I can send you the whole site zipped up if you need it. See them in action: The scrollbar issue is kinda random. In the screen-grab it happens right after reload but not afterwards, but during my daily work I could not notice any pattern, most of the time the scrollbar gets in the way. However, the tracyHidden issue is indeed site specific so it does not happen on the clean install. I will need to spend more time on debugging this one. Oh, and the Tracy setting generated by your module: (from both clean and problematic sites) Thanks in advance

I have just remembered that yesterday – beside updating Tracy – I also enabled the "Hide debugbar by default" in an attempt to workaround the scrollbar issue, so that the debugbar on the right does not get in the way by default. I have just gone to the settings and turned off "Hide debugbar by default" and it partially solved the problem. With this setting, if I click the arrow to minimze the debugbar, tracyHidden class still gets applied to <body> but upon page reload it does not, so at least it is not "sticky" and I can see the admin.

I disabled AOS and it did not make any difference, the tracyHidden class gets applied to <body> when I click the arrow icon to minify the debug bur. Regarding scrollbar issue, it happens in both Firefox and Safari too. Chrome and Firefox are the latest. The tiny svg icon issue is a bit browser specific, as it does not happen in Firefox, but does happen in both Safari and Chrome. The hidden class issue emerged when I updated Tracy yesterday. I cannot see any connection to AOS, but I could not spend time on debugging.

An example: https://processwire.com/talk/topic/8343-access-page-and-pages-variables-from-inside-a-javascript-file/?do=findComment&comment=80823

Hello Adrain, Updating from 4.18.15 to 4.19.6 I've found that .tracyHidden { display: none; } is applied to <body> of the admin so yeah, when Tracy is hidden the whole admin is hidden too... Is that just me having this issue? (I did perform "Empty Cache and Hard Reload".) Also, two permanent issues have been bugging me for a while but I did not bother to report, and I guess now is the right time to force myself to do it ? 1. Hide icon + browser's scrollbar issue: As you can see, the browser's scrollbar covers the hide icon, making it impossible to click it. I have to be very fast in order to be able to click it or else Chrome kicks in, so I find myself spending a lot of time playing this reflex game. Also, I've been wondering if it is possible to have the dabugbar on the left? When a site has an off-canvas on the right, then having the debugbar also on the right is very problematic. Currently I'm working on such a site, so I keep the debugbar hidden most of the time when possible. 2. Icons without right dimensions Since I often have to keep the debugbar hidden because of the off-canvas element on the right, I often have to reload the page one extra time because these SVG icons do not have the correct dimensions right after "unhiding" the debugbar: I hope all this explanation makes sense ?

For not so complex ajaxified pages this is what I do. Something like: <?php if ($config->ajax) { echo wireRenderFile("./rendered-ajax-call-result.php", array('page' => $page)); return $this->halt(); } Page is the only variable passed to the template partial and if something else is needed I make sure it is already part of page so that I can access it in the partial. The halt method is the recommended way so that ProcessWire can tidy up before exiting the process.