Leaderboard

You will need to unlearn jQuery ?. There's a difference between an "error" and an "exception". I am guessing uikit is probably using fetch() internally? If using vanilla JS... TL;DR From the fetch() docs: To the solutions Handling Failed HTTP Responses With fetch() How to handle HTTP code 4xx responses in fetch api

Hi, Anyone who wants to upgrade his coding skills, udemy has a big discount going https://www.udemy.com/course/the-complete-web-development-bootcamp

Thx @kongondo that helped a lot ? Also thx @elabx this is what seems to work for me: util.ajax('/data/newsletter/', { responseType: 'json', method: 'POST', data: JSON.stringify({ mail:mail, sms:sms, msg:msg, cmt:cmt, }), }) .then(function(response) { // show success message }).catch(function(error) { UIkit.modal.alert('Es ist leider ein Fehler aufgetreten!<pre style="margin-top:5px;">'+error+'</pre>'); util.removeClass(button, 'loading'); }); No idea how exactly I was using the catch statement before, but it somehow did not fire. Now everything seems to be fine, but I'll have to do more testing ? Probably not the best idea for a PW developer ?

Hi, I'm trying to send an ajax request on my new site via UIkit's built in little JavaScript framework: https://github.com/uikit/uikit-site/blob/feature/js-utils/docs/pages/javascript-utilities.md#ajax util.ajax('/data/newsletter/', { responseType: 'json', method: 'POST', data: JSON.stringify({ mail:mail, sms:sms, msg:msg, cmt:cmt, }), }) .then(function(xhr) { console.log(xhr); if(xhr.status !== 200) { UIkit.modal.alert('error xyz'); } }); The backend throws a WireException because the form is not filled correctly and that's totally fine. try { $gg->subscribe(); } catch(Throwable $th) { http_response_code(400); die($th->getMessage()); } But I'd like to catch this error and show a message to the user. In jQuery this is easy: $.post('status.ajax.php', {deviceId: id}) .done( function(msg) { ... } ) .fail( function(xhr, textStatus, errorThrown) { alert(xhr.responseText); }); But how do I do that with the uikit framework or vanilla javascript? I've done some research and tried several try/catch variants but I always end up in the error message in the console. This is the source of the uikit ajax function: https://github.com/uikit/uikit/blob/ea4453b1a71bfebb8ac43d81757071cfc5c7cca0/src/js/util/ajax.js#L5-L62 It seems that they have thought about "network error" and "network timeout". But how do I catch them? Thx for your help ? PS I think @Tom. you are quite experienced with JS and Uikit?

@Christophe - did you see the options for this that I posted above: https://processwire.com/talk/topic/1536-module-video-embed-for-youtubevimeo-textformattervideoembed/?do=findComment&comment=206840 ?

That's awesome @MoritzLost! This will help a lot. I'll dig deeper into the problem today and let you know the results.

Yes, I just subscribed for the complete webdev pack the discount is a very good deal. I see you guys back full stack ?

At first: Please look at the settings for this CKE field(s). There are checkboxes for showing or removing images without view access for guests. Second: check the access rights for (repeater)templates and its containing image fields!

I've been running MariaDB 10.4 with InnoDB engine on multiple sites since more than a year without any issues.

After trying other CMS, I finally decided to use Processwire, because it provides exactly what I needed for this project and even more (I'm still discovering some features). The project needed a Multilanguage site, and Processwire provided this feature very smoothly. I did not want to use any framework, so the website is made up with just HTML and CSS. I decided to implement Google AMP, so the page will load faster and for future mobile possibilities. This project is still under development. https://www.alval.cl/

Hi everybody. I refresh this old thread because I had also the same issue. For the solution I have found (don't remember where*): echo $option->getTitle(); For me it works fine, hope to be helpful. *found here, thanks @schwarzdesign :

Back in 2005/6, I built a SSG/CMS combination application, based on a Perl Framework that I had written. The magazines' editors input their stories via a CMS login, and then, when they were done, they clicked a button that sent a special secure command to the server to run a script that generated all of the pages as static HTML files. It generated thousands of pages blazingly quickly. Having done that, I think ProcessWire with ProCache accomplishes the same thing, since it also writes HTML files. But... ProcessWire is SO much better than my application ever was, for so many reasons. ProcessWire with ProCache gives us the best of both worlds. Peter

When I started working professionally on web projects... (don't you just love when folks start with that? "oh man, it's going to be another rant!") ... some of the first CMS' I had the pleasure to work with were kind of "static site generators": they generated static HTML files when you saved the content, and if your site had subdirectories, those were literal directories on the disk with more HTML files in them. I believe this was in part because server-side rendering back then was pretty darn slow and clunky, but also because it was easier to build a clean site structure with actual directories filled with static HTML files. "Dynamic" features, comment forms, polls, and whatnot were not quite as important back then, mind you. Now, I get that modern SSG's are a different beast in many ways, and I think they're actually pretty rad. What bugs me, though, is the amount of marketing bullsh... uhm, opinionated information floating around. Things like this gem from the staticgen.com website (emphasis added): I mean... how is this what a "typical CMS driven website" looks like? Any half-decent CMS has built-in caching support, at least to some extent, and caching plugins regularly pop up amongst those lists of most popular plugins for platform X. You don't need to be a rocket scientist to figure out that running a server-side rendered, CMS generated website with no caching whatsoever is a Very Bad Idea™. Comparisons like this may make the SSG approach sound good, but they've also got little to do with how things actually work. Without hopefully being too blunt, I don't think this is necessarily the best question to ask. If you define SSG as an application that reads markdown files from disk and generates a static site from those (that's one of the first definitions that comes up if you search for the term) then I don't see this as a solution most of us could push to our clients. At least not unless the site in question is a static one that doesn't need to update too often, and/or you can convince the client to pay you for each modification on a case-by-case basis. On the other hand if you think of an SSG as something that generates static site from dynamic content managed by some piece of software, well... that software you use to generate the content for the SSG? That's a CMS. It may be a headless CMS, but a CMS nevertheless ? I'm also going to agree with @MoritzLost on the point that ProcessWire + ProCache is indeed a kind of an SSG. Keeping a few potential pitfalls in mind one could definitely use this combination to build a setup that pre-renders the whole site and thus doesn't depend on request time server-side rendering. The web is full of interesting tech: headless CMS', static site generators, APIs, and whatnot. While the "best" choice depends on the use case — you would have to consider the pros vs. cons and figure out what's best for each particular project, client, and team — in my opinion it's also rarely all that important. Websites are created for end users and end users don't care what you're running the site on — as long as it works, serves their needs, is fast (enough), etc. ... and you can get that with any platform ? Sorry, that last part was a bit off-topic. Overall the SSG market is well worth keeping tabs on. Personally I tend to lean on the "dynamic CMS generated content rendered server-side with efficient caching policy" approach, but that's mostly because I feel it makes sense for the kind of projects and clients I tend to work with. Pros and cons ?‍♂️

I went "crazy" quite a few times over all frontend churn as well, FOMO, etc. At the end of the day, use the best tool for the job. Right now, practically all of my needs are met with the following stack: ProcessWire UIkit3 (it's so good; but, but the horror of using UIkits classes in your HTML!) Some PW premium modules: ListerPro ProCache (it's become my build process tool; you can build UIkit3 with it perfectly fine; I'm dumping Node, Webpack, and whatever the "latest" way to do things is) FormBuilder Pulling in whatever packages I need via composer VueJS if needed (loading it via CDN, oh my god the horror!) Digital Ocean for hosting (manually configuring their Ubuntu LAMP 16.04 droplet... takes only a few minutes) If your clients want to use some crappy shared host, switch them to DigitalOcean; it's practically the same price. I develop all my sites on Windows (but technically it's Linux thanks to WSL). No VMs, no Docker (again, the horror of what happens if my server ends up being PHP v7.0.23 and my local machine is 7.0.22!). Simple and reliable 99.99999999999999% of the time. I deploy with a simple shell script (horror! not using Capistrano, Ansible, whatever the latest tool is). Sure, your site won't be able to handle all of earth's traffic if everyone were to visit your site at the same moment, but it'll be fine for 85.7% of the sites you most likely take on. I've built very complex sites with just those tools and I move extremely rapidly while keeping the site client-maintainable! Even if you became Mr. Expert on the latest frontend tools, it's going to change significantly by this time next year and the year after that. Perhaps sit on the sidelines for a bit. End rant.