szabesz

Currently I stick to 3.0.138, looks like that is the last DEV version safe to update to.

Hello @kongondo Any news on this issue? I also run into it when trying to export a textarea field via the standard field export feature of the admin. I don't really need Runtime Markup, maybe you can give me a quick guide on how to remove it manually (inluding how to clean up the db if needed?). Has this version been version published yet? Thanks in advance.

Thaks Ryan, for the new features and also for the entertainment, which was just as great as the one and only "youtuber's" channel I regularly watch. His similar topic: https://youtu.be/Q6emWqJOTkY?t=1017

While I also mostly use the alternative syntax for the very same reason, it is also worth noting that (at least on the frontend) Tracy Debugger's Validator panel is quite handy. I keep using it all the time.

Fast software on the web, anyone? ?

I'm no expert either but there seems to be a consensus that GDPR does not require a one-fits-all approach for everything but quite the contrary. For example on a simple PW site where cookies are only used for their default purposes by the system and only editors and superusers login, I usually just state some "required for security purposes" blah-blah on the Imprint page linked form the footer or even form the main menu, and that is all there is to it. What you should do depends on lots of factors, including the local law. That's the "beauty" of regulations like this...

I do the opposite: I tend to use != and == when it is necessary, eg. when we are expecting multiple types and coercing can be harvested as a lazy programmer's tool ? Remebering what != and == do can be a challenge: https://dorey.github.io/JavaScript-Equality-Table/

Yes. Partial entries also have their own URL (unique query string) that can be bookmarked or returned to if someone doesn't want to complete it all in one setting or their session expires, etc. @ryan Will the user be notified of this possibility? I mean, it is great that using the URL the entire process can be completed later on, but if it is not evident then probably no one will use it, being unaware of this possibility.

I'm not that impressed. letsenhance.io vs Photoshop: Original: downscaled to upscale ? 4x upscale letsenhance.io – it took about 10 minutes! 4x upscale Photoshop - under 1 second: letsenhance.io is not better just different is some ways. Certianly was not worth the wait of about 10 minutes, especially as its algorithm tends to distort geometric lines. We can argue that letsenhance.io is better at photos, but Photoshop is good at those too... Looks like letsenhance.io is only impressive at painting like squiggles when its own added squiggles fit the bill, maybe?

Hello fellow Devs, Pluralsight free weekend: "Your free Pluralsight access will expire Sunday, September 8 at 11.59 p.m. MT." https://www.pluralsight.com/offer/2019/september-free-weekend "We’re unlocking our technology skills platform and making our 6,500+ expert-led video courses and 40+ interactive courses free for one weekend only." I do not know what they exactly mean by that (regarding the way of access), whether one needs to register or not. For signing up to get notified they require a phone number, so they do not seem to be in a real giving mood... We'll see.

Hmm, I'm not convinced that just because something used to be artificially defined as standard that means it is necessarily "ideal". I've seen so many people not knowing that the browser has a back button/feature (let alone the history...), getting confused by navigating away from the site, using Google just to find it again. But these individuals in question are aware of the tabs feature of the browser – and they do use it – as tabs are promptly visible (at least on desktop) and such users only use what they see right in front of them. Menus and shortcuts? Alien to them. The article is certainly subjective yet tries to look objective. The article's points certainly have merits, but just as our main topic, I think requirements vary and so do implementations based on that...

It was not that much necessary for sure, I put it there because the actual external link points to a partner institution and they might change their mind regrading "to be blank, or not to be blank, that is the question :)". Sure, I could change it for them should they ever change their mind, but I also wanted PW look professional as this is the first time they see/use it and the editor of the site is a former programmer... Motivations vary too, not just requirements ?

I also use different ways for implementing menus, depending on what I find appropriate. Here is a repeater based, one level customizable menu, where hiding fields on conditions makes it possible to switch between "custom" and page picker options:

In addition to it, there are modules with no config but some sort of "action" which can optionally be applied, like in the case of the core Page Reference module. Either way, there should be a cog icon next to module names like these, which are the "Configurable Modules". You can list them by clicking on the Configure tab. Note that in the case of updating configureable modules it is a good idea to perform a module refresh first then click the submit button so that possible configuration changes are applied. Non-configurable modules are the ones you ask about. No, it doesn't. It's just a bit of a neglected UX design that the submit button is there to click even though the only option – which is the Uninstall checkbox – is not selected.

Any chance you have some hooks with baked in default superuser id (41) checks preventing something they should not do?

Normally I create more than that under home anyway, such as custom assets, tags, categories, etc... Normally I create a page under home called something like "Internal" – and move it to be the last one – to signal that pages under that do not directly map to public pages, and I explain it to the client. As it is a simple concept, even the less technically minded had no issues understanding it so far.

Something like this? $classname = $event->arguments[0]; $thisClassname = $this->wire('modules')->getModuleClass($this); if ($classname !== $thisClassname) return; // Only continue if settings of this module are being saved.

I have started to familiarize myself with the codebase and later on I will take a closer look at all the issues mentioned here and at GitHub. I am not planning to update nor fork the module in any way though, I am thinking of refactoring it completely, and in the end release it under a new name. The first version of this "new" module should be "compatible" with MarkupActivityLog, meaing it is going to rely on the very same database table in the very same manner. However, this first version should tackle the most important issues and it will be PW 3+ and PHP 7.1+ only. Also, being refactored, it is going to use more up-to-date PW features under the hood. In short, I will be working on a successor module to MarkupActivityLog. Note: there is no time-frame for this project at the moment ?

Thanks for informing us! I do not have too much spare time either but I will take a closer look and see how much effort is needed to bring it at least up-to-date (the module also has issues with the UIkit admin theme). In the meantime, if anyone else is planning to do something similar, then don't be afraid to share your thoughts and/or work ?

Hello @renobird, Any chance you can work on it? Can we help somehow? Thanks in advance!

I have just run into – probably – the same issue, although I did not mixed up any children. I have a parent-child template relationship set up as usual, for the parent only the given children are allowed, for the child only a the given parent. When clicking on "new page" in the admin, two children are created at once, instead of one. I also added an unrelated template to the "Allowed template(s) for Children" of the parent template as you did to "solve" the issue, but I think it is just a workaround as this behavior looks like a bug to me.

https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ After reading this article highlighting the utility-first approach, a couple of things popped into my mind: This utility-first approach is mainly for large frameworks and/or for pre-made high-level component libraries where spending the time on all the extra work this approach introduces is worth it. For the frontend of brochure sites and even for classic retail webshops strictly sticking to this approach can be overkill and limiting in terms of "custom design", even though it is supposed to be able to deliver some sort of freedom in customization. If there is only one or two developers working on a not so big website, the advantages of this atomic utility-first approach fade away. My issues with this atomic style utility-first approach: - Memorizing the classes takes a lot of time as one has to learn a brand new language, translating a lot, eg: .flex-no-wrap means flex-wrap: nowrap; .flex-wrap-reverse means flex-wrap: wrap-reverse; .min-h-full means min-height: 100%; .min-h-screen means min-height: 100vh; And the list goes on... One has to spend quite a lot of time using the library in order to learn all this mapping. - Even though the CSS library is there, one has to start from scratch in terms of implementing "building blocks"/"components" for the site. Not having pre-made high-level components means that there is no help in this regard, it's very much like building the frontend based on SASS/LESS only (except for the utilities out-of-the-box, of course, but still...) - The approach of limiting text sizes, colors and similar to a few can be limiting for custom frontend design. By only using statistics to judge a particular design is short-sighted, I think. The Author lists some stats on popular massive sites out there, listing data like: Stripe: 189 text colors, 90 background colors, 35 font sizes purely based on some simple counting of the number of property values being used. By not knowing why those colors are used, stats do not mean too much, see for example: https://stripe.com/blog/connect-front-end-experience Being armed with some experience in working with colors one knows that – for example – bright text on dark background looks thinner than dark text on bright background and for this reason the trick of making bright text on dark background just a tiny bit brighter than its counterpart on bright background can be used to make text more readable. Also, properly matching colors is not always possible by picking colors form a small color palette, as our brain can observe them differently depending on the context. I understand that using hundreds of colors is most probably unnecessary, but relying on a fixed number of a few dozen can be limiting at times. The Author also states: "I don't think you should build things out of utilities only." and I agree ? For small and mid-range frontend projects I think UIkit 3 is a better choice as it provides high-level components based on low-level ones which can be mixed in lots of clever ways. I usually add the BEM-like approach to my code too, so that any deviation from the otherwise LESS customized UIkit can be applied in a maintainable manner.

Thanks for sharing! I will surely check it out sooner or later.

https://github.com/processwire/processwire-issues/issues/252#issuecomment-467473684 Quote: "If a page is saved (in the admin) and errors are generated by the page editor form, the page receives a Page::statusIncomplete status, indicating something may be missing on the page. When the page is saved without error, this status is removed." There is more about it in the GitHub issue.

Hello, Are you aware of this project?