szabesz

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?

@Sergio Could you put your long code sample into a "spoiler" please? Anyway, thanks for sharing ?

Hello, Will you please share a code snippet for future reference so that others can clearly see what to watch out for?

No, it's still not an exaggeration (and probably never will be...). If one can get be paid for maintenance works, then WP is a "perfect" platform; a great time killer in this area.

Hello, It all depends on your experience, but naturally I would recommend ProcessWire ? If you pick PW, ProDrafts is worth considering: https://processwire.com/store/pro-drafts/ Quote: "With ProDrafts installed, such users can now edit a draft of the published page, even if they can't publish the draft. This provides some very useful workflow potential for sites having multiple editors and access levels." There are some (one or two, perhaps?) basic free modules for basic analytics, and they can be used as the bases of further development, or you can integrate Matomo with PW, for example. Until you get more answers to this question, you might want to browse these sources: https://processwire.com/talk/forum/9-showcase/ https://processwire.com/talk/forum/16-case-studies/ https://processwire.com/sites/ Hope this helps.

Because of this I either move the name filed to the content tab (which is OK for a non multilanguage site, but for more than one language it is wasting a lot of valuable space at the top of the edit page) or display the name right under the Title field's label, which is not editable but at least not so hidden as the Setting tab. There is room for improvement is this area for sure. WP's solution is very good, except that it is single language and I've never seen their(?) multilanguage solution.

If you try to create some sort of page-builder featureset this way, than this is not what you are looking for as fields and templates are for developers (and most of the time they are the only superusers in the system...). People usually use RepeaterMatrix or sometimes the PageTree to implement page-building functionalities. There are plenty of examples in the forum demonstrating these. Some devs used custom coding too, again, they showcased their work in the forums.

In addition to what @teppo said above, some sample snippets to get you sarted:

Related: MDN Now Built With React https://www.i-programmer.info/news/87-web-development/12972-mdn-now-built-with-react.html

People should boycott FB - and any other similar sites for that matter - for their own good anyway.

Hello folks, Your voice can also be heard: https://hacks.mozilla.org/2019/07/mdn-web-developer-designer-survey/ "The survey results will be published on MDN Web Docs (MDN) as an annual report. In addition, we’ll include a prioritized list of needs, with an analysis of priorities by geographic region."

Hi, It looks like you are right: https://processwire.com/docs/tutorials/but-what-if-i-dont-know-how-to-code/

In my case the solution was to install a clean system and set up all the apps I use. No wifi issues ever since.

Simply hooking into Page:viewable might not be enough, see: Meaning $pages->find() works independent of Page::viewable ?

Also worth noting: https://stackoverflow.com/questions/5943149/rebase-array-keys-after-unsetting-elements

Buying ProFields for this reason only should be enough ? After all, without Ryan there is no ProcessWire so we need to support him. Anyway, I think ProFields really shines when one needs it for Repeater Matrix. The other modules can also come in handy sometimes but with other free modules and/or other built in modules similar functionalities can also be implemented mostly without too much effort. What I find not powerful enough is Table. The features of Table are quite limited. I understand that implementing such an inputfield is quite time consuming, so developing a much more powerful ProTable module as an independent paid module would make sense. For example, @bernhard has been working on his on his modules (#1 and #2 and maybe more?) and we also have the not-really-worked-on-anymore ProFields: Page Table with lots of lucking features as well (eg.: pagination). All this development effort towards an independent Pro module based on tabulator.info would be welcome. I imagine a "ProFields: Page Table" based on Tabulator which would be a big hit...

Sounds like this issue is sowewhat related to this one: https://processwire.com/talk/topic/21716-processwire-profiles-whats-missing/?do=findComment&comment=186721 Maybe @Jonathan Lahijani has already come up with his "solution"? Quote: "...I don't know what term would accurately describe it, but its a ProcessWire module that's an opinionated, update-able starting point, oriented towards developers..."

In the case of order numbers - for example - it is common not to start counting form 0 and not to increment by 1. This is a practice to make it harder for the customer to realize that a brand new webshop has just started selling... So as the comment says: @param int $change (optional) The amount to change the counter by. Must be non-zero integer. Defaults to 1. @param null|int $min (optional) If specified, the returned value will be greater or equal to this value. "If specified, the returned value will be greater or equal to this value." actually means: initial starting value.

Hi all, Stumbled upon this recently: https://frontendmasters.com/books/front-end-handbook/2019/ ( https://github.com/FrontendMasters/front-end-handbook-2019 ) Quote: "This is a guide that anyone could use to learn about the practice of front-end development. It broadly outlines and discusses the practice of front-end engineering: how to learn it and what tools are used when practicing it in 2019. It is specifically written with the intention of being a professional resource for potential and currently practicing front-end developers to equip themselves with learning materials and development tools. Secondarily, it can be used by managers, CTOs, instructors, and head hunters to gain insights into the practice of front-end development." Plenty to explore! I've warned you ?

Yes. I'd rather give you access to the site (as it is not yet live anyway) so that you can also use Tracy's file editor to poke around. What do you think? BTW, I could not really uninstall the module, it was just FieldtypeRuntimeMarkup which seemingly went through the uninstall process, but PW – as expected – kept complaining about InputfieldRuntimeMarkup being used when I also clicked the uninstall button of that one. However, if I delete the RuntimeMarkup filed, I am back where I started.

Hello @kongondo I updated a site to v.0.0.6 and now when trying to edit a – seemingly unrelated – TextareaLanguage field by using the field overwrite editor modal of a template I get this: Fatal Error: Uncaught Error: Class 'ProcessWire\RuntimeMarkupUtilities' not found in .../site/modules/FieldtypeRuntimeMarkup/InputfieldRuntimeMarkup.module:68 Stack trace: #0 .../wire/core/Modules.php(624): ProcessWire\InputfieldRuntimeMarkup->init() #1 .../wire/core/Modules.php(1336): ProcessWire\Modules->initModule(Object(ProcessWire\InputfieldRuntimeMarkup), Array) #2 .../wire/core/Modules.php(1193): ProcessWire\Modules->getModule('InputfieldRunti...') #3 .../wire/core/Modules.php(1566): ProcessWire\Modules->get('InputfieldRunti...') #4 .../wire/modules/Fieldtype/FieldtypeTextareaHelper.php(40): ProcessWire\Modules->find('className^=Inpu...') #5 .../wire/modules/Fieldtype/FieldtypeTextarea.module(338): ProcessWire\FieldtypeTextareaHelper->getConfigInputfields(Object(Proce (line 68 of .../site/modules/FieldtypeRuntimeMarkup/InputfieldRuntimeMarkup.module) This error message was shown because: site is in debug mode. ($config->debug = true; => /site/config.php). Administrator has been notified. Error has been logged. I tried uninstalling the module (because the site does not use it yet anyway, meaning there is no field using RuntimeMarkup) and when I click on the uninstall button I also get: Class 'ProcessWire\RuntimeMarkupUtilities' not found However, if I create a RuntimeMarkup field then the error goes away in both cases described above. It looks like the case when there is no RuntimeMarkup filed in the system is not taken into account. So with a RuntimeMarkup field created, I could uninstall the module as the fatal error did not crop up in that case. Also note that I find it strange that both FieldtypeRuntimeMarkup and InputfieldRuntimeMarkup show up as RuntimeMarkup in the module list, see the screenshots:

Just want to add for anyone reading this post, that while in the admin this cannot be done, it is doable via code. By putting something like this into init.php,: $templates->get('home')->filename = $config->paths->templates . 'views/home/home.php'; it is possible to store a template file wherever you want. Read more about this in this topic: https://processwire.com/talk/topic/2676-configuring-template-path/