szabesz

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?

@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...