dotnetic

I do it with a hook, like described here

Here is what I did to pre-fill fields with a default value: // in ready.php or a module add a hook $this->wire->addHookBefore( "ProcessPageEdit::buildFormContent", $this, "addDefaultTexts" ); public function addDefaultTexts(HookEvent $event) { $form = $event->return; $page = $event->process->getPage(); bd('editForm, pre-fill fields'); if ($page->nameofthefield == "") { $page->nameofthefield = "my default text"; } }

Just released the updated version of the german language pack for the just released stable core version 3.0.210 Download ZIP (github.com) @ryan @teppo

I also brought this up before as a wishlist request UX improvements · Issue #392 · processwire/processwire-requests (github.com), because I use these features of AoS in EVERY PW instance. But there are also always voices against integrating useful things into the core, to keep it "lean". For example integrating migrations into the core, which I see as crucial, but others say that migrations are not needed for everyone, and so they should stay out of the core. One feature might be useful for one person, but not for the others, so I am always in favor of "providing options" (turning features on or off). I'm also at a point where I find the admin or UIkit theme stale and not really functional. There are a lot of things missing for me. Reactivity like vue.js or alpinejs or react offer. Better usability of dropdowns in the main menu and other things, but I digress. Several times I started to develop a new admin theme based on vuejs, but also noticed how complicated for example the pagetree is built and moreover I lacked the time. Furthermore, with such a big undertaking, it's also always a question of how many people would really use it, or if I (or WE) are just developing it for fun. Because I don't want to develop anything for &>/dev/null. Back to AdminOnSteroids: Right now it's not modular and uses jQuery under the hood. It's not a bad thing because the PW core also relies on jQuery, but would rather suggest a rewrite here where every feature is a javascript module. These modules could be loaded on demand (conditionally based if a specific DOM element exists or not) at runtime. This keeps the core lean, and also the javascript load and execution time and memory consumption low. Maybe such an update (or the integration into the core) could be developed by crowdfunding. I am also in favor of ditching support for Default or Reno theme, because I think that most people would use AdminThemeUikit, but I might be wrong? Upgrading the PHP part, would not be that difficult, if we drop support for PHP versions < 8.

You could achieve this if you are using your own custom CSS animation: Take a look at my Codepen example Uikit scrollspy animation different on viewport width (codepen.io) You can see, that I use a media query to trigger the different directions of the animation @keyframes my-animation { 0% { transform: translateX(-100%) } 100% { transform: translateX(0) } } @media(min-width: 768px){ @keyframes my-animation { 0% { transform: translateY(100%) } 100% { transform: translateY(0) } } } <div class="uk-child-width-1-3@m" id="animateMe" uk-grid uk-scrollspy="cls: uk-animation-slide-bottom; target: .uk-card; delay: 300; repeat: true"> <div> <div class="uk-card uk-card-default uk-card-body" uk-scrollspy-class="my-animation"> <h3 class="uk-card-title">Animation based on viewport width</h3> <p>On a small viewport I slide into your DMs from the left.</p> <p>On a large viewport I sneak in from the bottom.</p> <p>Resize the window and click on me me to trigger the animation again. </div> </div> </div>

Why would you even do that? What you mean when you are talking about "device"? Do you mean resolution? Then use media queries. Do you mean specific features? Then use feature detection. What is the specific use case, that can't be handled via normal media queries or window.matchMedia and feature queries? Maybe that is the problem, because the application has grown over time and now you can not easily change it to use best practices. I work in this industry since 1999 and know that browser detection is a thing of the past and preached by webexperts (I count myself to that, not in all areas, but many) everywhere not to use it. Even if many companies should still use it (which I believe is not true, or they might have legacy websites), that doesn't make it right. I also worked on over 100+ projects (international and national) and my company moved from using browser detection very long ago. Never had something that we couldn't do without it. Exactly, thats why you would load scripts conditionally via the import() expression via JS modules (all evergreen browsers support this). Stylesheets can be loaded depending on a media query to target specific media. I think the main problem what we talking about here is, that you have a legacy webpage/application, which could not be easily transformed to use best practices. The second one is the definition of "mobile" or "device" and what should be possible or not with that device. I neither wouldn't do that, because it is a bad practice. You can do this via JavaScript with the matchMedia method, if we are talking about viewport width. If you have specific questions how you might tackle your problem, we might give you suggestions here.

That is very counterproductive. Google might derank your page based on this (Don't know if it is still the case, but it was). Also it is never a good thing to optimize something to specific devices or resolutions. Design for EVERY device. Use progressive enhancement instead of using the user agent string or some other detection for the browser. User agent strings can be manipulated and are not reliable! Also future browsers wouldn't be taken into account. Browser detection is a thing of the past and should be abandoned, as there is no need for it. If you want different images for different resolutions or landscape and portrait view modes, there are media queries for this purpose. Thats exactly what media queries are for. You can even do art direction (display different images on different viewports) with different display modes depending on the display. DO NOT USE BROWSER DETECTION. PERIOD!

Please look in your ddev config.yml file, if apache-fmp is defined under webserver_type

deleted

Just like I would normally get the image url via the pages API. I just need one image in my case and so the output of a request like $result = $this->pages->findRaw( 'template=shop' . $filters, [ "id", "title", "myImage.httpUrl", ], ['flat' => true] ); should include the path to the image. Or if I just reference the image file as "mo_image" in the query, I get this result: There is much information about the file, so why not include the url in it? Also I don't understand why the results are always arrays, as they are normally just single values. This problem also exists for page reference fields which can be seen in Add $pages->findRaw() option to return "single" Page Reference field values directly · Issue #458 · processwire/processwire-requests (github.com) (please vote for it to be fixed). I know that in RockFinder you can get the image url via the callback approach, which I like. But this again queries the page with all it's fields and so the speed improvement of findRaw is gone.

Thanks for the workaround idea, but it requires to re-save all pages that have an image. But still I would love to support for getting pageImages in the core findRaw.

I am also wanting a solution for this, or at least get the path to to the image url. I want to use this data in a data grid to render the image. Normal pages->find operator is slow with many pages, so it is no fit for me. I also tried findJoin, but it also seem it does not work for images? We should open a request at processwire/processwire-requests: ProcessWire feature requests. (github.com). Are you doing it, @MSP01?

You made me laugh ?

Another thing is, you can re-use custom page classes in new projects and have their fields/templates created automatically. Develop them only once, copy them over to a fresh PW install, and there you go.

What do you struggle with @Ivan Gretsky? I use RockMigrations for every project right now. You got version control for your fields and templates, and even more. So if you are using git and develop new features, it is of great use because it adds the needed fields/templates when switching branches. Also in conjunction with RockFrontends livereload feature, this is a lot of fun. You add a field in the migrate.php (or somewhere else where you need it, like a custom page class) and the page in the admin autmatically shows the newly added field. This made my workflow so much quicker. I don't use the deploy feature (github actions) because I got my own github actions, so I can not say anything about that.

Very nice addition. Was also hoping for support for adding it via composer.

Thanks @bernhard for adding what we discussed earlier. Works fine ?

You can import the attached file into your IDE. See instructions here https://www.jetbrains.com/help/phpstorm/sharing-your-ide-settings.html#import-settings-from-a-zip-archive I don't have much time atm and so I can not provide full instructions and the file not in a repo. Please note, that if you use settings sync, the import will not work and you have to put the "template" folder of the zip file into your PHPStorm settings folder which is depending on your OS somewhat like C:\Users\username\AppData\Roaming\JetBrains\PhpStorm2022.2 (Windows) paste it here! settings.zip

Until we might have a native method for migrations, I encourage you to checkout the great RockMigrations module. With the module you can have one or multiple migration files, that handle all the stuff mentioned above, like adding fields, adding templates, creating pages with content and setting roles. As the migrations are file-based they are also version-controllable. It is also a hassle-free setup and very easy. This makes it easy to work on a feature in a different branch which requires to have other fields/template than in the main branch. Now you can switch between branches and always have the required fields and templates. This is a huge time and workflow improvement. @bernhard steadily improves his module, and me and other contributors try to enhance it, or give feedback.

Did it, because I need the same Please make InputfieldPage::getPageLabel hookable · Issue #460 · processwire/processwire-requests (github.com)

Any javascript errors in the Dev Tools console? Install Tracy Debugger and see if errors occur there

Just the ProcessWire Code, I have to transform everything manually. Sadly IntelliJ has a weird format for the live templates which are stored in an XML file. Sharing and importing isn't also as easy as copying the files to the root directory. Instead you have to import them as settings for the IDE and restart the IDE afterwards. Live templates are a native function of PHPStorm, I think they were a thing before they existed in VSCode. It is somewhat similar to snippets in VSCode. You have your code and then enter $myvariable$ for inserting user text, or things like $boolean$ or $enum$ and can define values for that.

Coming to an IntelliJ IDE (like PHPStorm) near you soon. Live Templates or snippets provide a short way to write repeating code. You enter an abbrevitation and the editor completes the code for you. Here is one example when I want to setup a new module: phpstorm64_aT7Nj2gxSv.mp4 @bernhard Has snippets for VSCode in his great RockMigrations module also, be sure to check them out, if you use VSCode. As I use RockMigrations in every PW installation I also add snippets for migrations: phpstorm64_fAD9MoUJLE.mp4

RockMigrations is the best tool to do migrations with ProcessWire. It saves me so much time when creating new projects or extending older projects. Once you use it and understand it, you don't want to live without it! Thank you very much, @bernhard. Also a good video. I think you explained it very well, hopefully even for beginners. What personally nags me most in every module demonstration video out there (not only from you) is how to install a module. That is annoying to me, but might be useful for others. Gladly I can skip that part and you also added timemarks, sections to the video. Keep up the great work.

I love that quote.