szabesz

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

I do not need it ? but my client does so I had to find a way not to upload the "same" image twice, once for the client and once for the site. The client also needs those PNGs to be as small as possible, so that is where crushing them comes into play. Anyway, if you could revert the change, that would be great for the time being. Maybe a note in the source code about the issue could help to decide when to add it again to the supported filetypes is feasible. (A few years from now on, maybe?)

? I know the theory, however, saving space can be important on some servers. Also, in this particular case form a 3000x3000 PNG8 a 1000x1000 JPG is generated, and I do not think anyone can tell what the source was just by looking at it.

I see! Yes, those PNGs are indeed PNG8 in my case. Tracy on MAMP Pro reports :IMAGICK SETTINGS Version: 6.9.6 Whereas in production: IMAGICK SETTINGS Version: 6.7.8 It seems like it is a bug in older verions of Imagick which are still quite common, I guess.

Hi @tpr I have z-index issue with UIkit Sticky header being on. input.InputfieldDatetimeDatepicker has a higher z-index than the header. I quick fixed it with #pw-mastheads {z-index:11 !important;} but I'm not quite sure what to do.