dotnetic

Do it now! It is easy to setup, and once you have it, you will never want to touch something other again.

You are welcome. Thank you very much for your continued work on RockMigrations.

I think maybe both variants should be in the same recipe. I am talking about the recipe creating a page via api. The published method is still viable, but there is also pages->new with a much simpler one argument syntax. So neither is right or wrong, better or badder, but a matter of choice.

The reason why I am asking for the release of v008 is because as the initial select I want to display a list of images instead of the title. Is this possible with v007?

@wbmnfktr Here are some thoughts for improvement and a question: A search function is missing. Would be great if it could be integrated. There are search functions that work with html elements, like Search, sort, filters, flexibility to tables, list and more! - List.js (listjs.com) but this solution would only work if all recipes are on one page, as it is right now. Going forth and back to see different recipes is not good for the eyes, because of the steady switch of backgrounds. I think it is better if you remove the blue background on the homepage and maybe add some shadows to the recipe cards then. It would be nice, if you can quickly navigate from one recipe to others. There are several ways this could be done. A search function would be one option, or an iframe as a sidebar with all recipes. How can I improve a recipe because there are better (newer) methods to accomplish the same? Create a PR for that recipe? Or create a new recipe with the same title with the improved method? There should be a ProcessWire version field, so someone knows that one method only works with a specific version of PW.

Was version 008 ever released? I bought this module some days ago, and received version 007 (codename James Bond).

Thank you @bernhard for this extensive post. I use RockMigrations every day and love it, as I stated often before. It isn't as hard as it looks at first. Just try it out and if you should stumble over something, then just ask for support here in the forum. RockMigrations saves much time and makes it easy to develop features in your dev environment and then when the feature is finished push the changes to the live server with migrations being executed automatically, which creates all fields, templates and even pages and contents. Could live without it, but that would be a sad life. So.... start using it now!

Did you find a solution yet? Depending on your host it could be that you can not make changes to your php.ini. The size of the setting could also be limitted by your web package that you bought. Some other hosters like Domain Factory use a user.ini instead of a php.ini in the root of your webspace, where you can make adjustments.

Just fixed 3 small issues, grab the fresh release: Releases · jmartsch/pw-lang-de (github.com)

This is already the case, just tested it with a fresh import into an existing project. That was a request, maybe even from you 3 years ago. Since then it is "verschieben". You can see it in here pw-lang-de/wire--modules--process--processpagelist--processpagelistrender-php.json at 647a7d40d3b933f2c43bde859401a4f7d6cc2a7d · jmartsch/pw-lang-de (github.com)

Outline is always on all four sides, and you can not set properties like width or color indiviually

Yes, that would be what I expect too

Yes, it is used for many things in the admin panel. On the frontend you are free to choose whatever you like. I think you are talking about the frontend. IMHO you should avoid using a CDN to integrate jQuery into your site, because of GDPR regulations in the EU (if you reside in the EU) and also I experienced times, where the CDNs failed or took a long time, so the whole site was blocked because it could not load jQuery. Nowadays I don't use jQuery anymore and try to write everything as vanilla JavaScript. jQuery has a simpler syntax sometimes, but adds additional Kilobytes to the load and execution time of your website. It was great some years ago, to overcome browser inconsistencies, but that is not needed any more. You might read You Might Not Need jQuery To avoid discussion: This is MY opinion and everyone can decide for themselves what to use.

$pages->findRaw is the way to go if you want many results and only specific fields. I reduced the load time of a json file for 22000 pages querying 14 fields of the page from around 7 seconds to 1.5 to 2.0 seconds. My client is more than happy because he reloads the page with this data very often on one day.

Yes I think thats faster, because for example FilamentPHP has the option to build the admin panel from scratch and add only the navigation entries you need (permission controlled). It also has migrations out of the box (because of Laravel), and I also said the same thing as you above: Yes, that is a priority for me (in some cases) and why should I use PW for this, if others bring better functionality out of the box? Did you try out other Frameworks or CMS like Laravel or Statamic? Some have a similar API like ProcessWire, it seems like Laravel and PW inspired each other. For example in the Statamic CMS (which is file based) you can use very simple queries to loop over a collection of objects (even in templates and even with separated entry types) like so: {{ collection:articles limit="5" }} {{ partial src="blog/blogteaser" }} {{ /collection:articles }} So, that nobody misunderstands me. I ❤️ProcessWire, but for some things there might be better alternatives out there.

It might be possible, but I agree that it may not be the best option for this kind of stuff (depending on how extensive it is to become). I developed several big applications with ProcessWire (a room furniture management system, an applicant management system) with it's own workflow, but had to fight around many things in ProcessWire to modify the navigation, create a custom approval process with different rights and levels. First big issue was to remove all navigation entries and restrict them according to user roles. Another big issue of ProcessWire for me is (when it used as a software framework) that everything is a page and these pages in the database are not separated in different tables by the type (for example a client, an invoice, a project, a room). That makes it hard to create or restore a database backup just to get the entries of a specific type. This is also a problem with a shop based on padloper 1 that I use. For new projects that are some kind of management system I personally would not use ProcessWire anymore. Instead I use Laravel or some other frameworks like FilamentPHP (which is based on Laravel). Also there are many good Open Source or free CRM's out there.

Same for me. Encounter a problem. Search the forum, and find an answer that I provided myself 😄

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