szabesz

Couple of other notes: Quote: "All $config->ajax does is checking for the request header "X-Requested-With", which is not even a real standard. It is included in jquery's ajax tools by default, but most modern ajax libraries don't do that anymore. There's nothing more to it." Quotes: "Make sure your post url ends with a slash." "Otherwise the .htaccess (or php not sure) will do a redirect, which essentially strips all the headers sent with the request." Also, use $this->halt() instead of exit() or die(), read more on it here. (such as: note that return $this->halt(); must be called from directly within the template file, outside of any function or class scope) Use Tracy Debugger to ease the pain ? https://processwire.com/talk/topic/12208-tracy-debugger/page/31/?tab=comments#comment-135558

@MoritzLost "Don't Panic Ipsum" is pretty cool. Nice work!

More about the "happy" side of coding ?

WTF this actually works! I've been hit by this bug the very first time, also in Firefox (v78.0.1 in my case) which I rarely use for working in the admin, so properly that is why I have not yet experienced this issue before, though as far as I understand others experienced this in Chrome too. I can confirm that opening a new admin page in Firefox does indeed fixed the issue.

@MadeMyDay Thanks for the showcase. Note that the contact form in the English version is 404.

That sounds like a powerful feature for sure. Thanks four these nice additions anyway.

Hello, I do not have much experience with site profile exports, I tried it out when I first started using ProcessWire but I have not used it ever since. So I cannot help you in that regard but you might want to consider different approaches as well, see: https://processwire.com/talk/topic/17302-working-on-a-webproject-with-pw/ I hope this helps.

+1 ?

Note that currently there is a know issue with image custom fieds: Custom fields for files/images – does not save in repeater context

Hi devs, Only personal annual plans are eligible. Details: https://blog.jetbrains.com/phpstorm/2020/06/php-turns-25/ And don't foget: https://sales.jetbrains.com/hc/en-gb/articles/207240845-What-is-a-perpetual-fallback-license-

@Peter Falkenberg Brown Thank you Peter, personally I appreciate that you shared your script and experience.

Alpine.js & Vue.js & Tabulator but it would also be a use case for any other JSON powered solution out there, of course.

@ryan Thank you for your insight, it was an interesting read to learn more about your current refactoring efforts. I am wondering if it is the right time for you to also start working on the Javascript API perhaps? I don't remember since when it is on the roadmap, but in this post from 2017 you wrote: "...so I'm going to continue to keep this in our roadmap."

If you pick ProcessWire as the bases of your PHP CMS based sites, you get the best tool for "easy" introduction to this world for sure!

Kongondo is right, of course. Sounds like there is some sort of "custom code" implemented for your site which cannot run in the new server environment, or even worse, your host might have screwed up something which they just never confess. For example, once I had a clear clue in the logs that the hosting company ran their custom script to scan(?) the site for some sort of WordPress thingy and the script modified things it should not have. The support denied the fact that the scrip had been run, but the error message in the logs told me a different story...

Cool men ? Thanks in advance guys!

Hello @Peter Falkenberg Brown, Thanks for sharing your script, I appreciate that. Still, they are kinda long so could you please "hide" them in a spoiler (by using the eye icon in the toolbar). That would make this thread readable and the browser responsive.

"Markup Regions pw vs data-pw different behavior" I have not yet experienced such a behavior. Maybe you are mixing up "Boolean action attributes (inner HTML)" with "Action attributes with value (outer HTML)"? Regarding the differences between these two, see my explanation below. +1 Here is my simplified docs for markup regions, we can also call it "cheat sheet". I wrote it some time ago: Defining markup regions Basic region Wrapping tags do appear in the final markup. Children tags are preserved if not explicitly replaced. <div id="hello"> OR <div data-pw-id="hello"> data-pw-... They are removed from the final output and thus not visible to front-end markup, while id="..." is not removed! Placeholder region Only the inner HTML will be used and the wrapping tags won't appear in the final markup. <pw-region id="hello">...</pw-region> Good for groupping tags in the <head> eg.: <pw-region id="site_scripts"> Optional region It will be automatically removed from the document markup if nothing populates it, so it is a region which should be empty by default. <div id='hello' data-pw-optional></div> Examples: an <ul>, which [according to HTML5 specs] is required to have one or more <li> elements within it, otherwise it's invalid HTML. a sidebar which is only needed on pages populated with widgets /* -------------------------------------------------------------------------------------------------- */ Populating markup regions Available action attributes: data-pw-replace: replaces a region’s markup data-pw-append: appends markup to a region data-pw-prepend: prepends markup to a region data-pw-before: inserts markup before a region data-pw-after: inserts markup after a region Boolean action attributes (inner HTML) Only applies the inner HTML to the region. TARGET CODE: <div id='hello'> <h2> Hello World </h2> </div> <p data-pw-id="hello" data-pw-append> This text will APPEND to div#hello </p> <p data-pw-id="hello" data-pw-prepend> This text will PREPEND to div#hello </p> <p data-pw-id="hello" data-pw-before> This will insert this text BEFORE div#hello </p> <p data-pw-id="hello" data-pw-after> This will insert this text AFTER div#hello. </p> RESULTS: This will insert this text BEFORE div#hello <div id='hello'> This text will PREPEND to div#hello <h2> Hello World </h2> This text will APPEND to div#hello </div> This will insert this text AFTER div#hello Action attributes with value (outer HTML) All of the markup that you specify (the outer HTML) becomes part of the final document markup (except for the pw-* attributes): TARGET CODE: <div id='hello'> <h2> Hello World </h2> </div> <p data-pw-append="hello"> This paragraph will APPEND to div#hello </p> <p data-pw-prepend="hello"> This paragraph will PREPEND to div#hello </p> <p data-pw-before="hello"> This will insert this paragraph BEFORE div#hello </p> <p data-pw-after="hello" class="world"> This will insert this paragraph with class "world" AFTER div#hello. </p> RESULTS: <p> This will insert this paragraph BEFORE div#hello </p> <div id='hello'> <p> This paragraph will PREPEND to div#hello </p> <h2> Hello World </h2> <p> This paragraph will APPEND to div#hello </p> </div> <p class="world"> This will insert this paragraph with class "world" AFTER div#hello. </p> /* ------------------------------------------------ ------------------------------------------------ */ Adding HTML attributes Any HTML attribute you add to the action tag that does not begin with pw- or data-pw- will be added to the originally defined region tag. TARGET CODE: <ul id="foo" class="bar"> <li> First item </li> </ul> ACTION CODE: <ul data-pw-append="foo" title="Hello"> <li> Second item </li> </ul> RESULTS: <ul id="foo" class="bar" title="Hello"> <li> First item </li> <li> Second item </li> </ul> Adding and removing classes Classes from the action tag and the region tag are merged by default. To remove a class by the region action: prepend a minus sign to the class to be removed, eg: class="-foo bar" will result in class="bar"

There seems to be a different opinion, see: https://processwire.com/talk/topic/21534-how-to-change-the-default-language-in-processwire-cms/?tab=comments#comment-185533 Still, I also use the setup Horst suggests and I have not found any drawbacks of it so far.

Folks not in the US are only allowed to download outdated US technology ?

Strange indeed! In Chrome it is 155 too, but in Firefox and Vivaldi it is still 153 on my Mac.

Unfortunatelly it is a long standing issue, which dates back to years. There is some sort of automation which should update it (as Ryan explained in the past), but it works rather hackticly (as it turns out).

Done too. I also added: PRO – Easy to maintain, no need to update the system frequently. The only driving force to update a ProcessWire system is the end-of-life policy of PHP. Because of the lack of security issues, updates are not required but can be performed easily if one wants to add new features. And to be fair, I also added this (since the list we are dealing with has systems like that): CON – This CMS is not for those who just want to download a frontend theme. ProcessWire has no concept of frontend themes like other CMSes have. Instead, you can customize some free frontends if you have basic HTML/CSS/PHP knowledge or hire a developer to implement a complete custom frontend according to your own needs. Another option is to learn the basics of web development and you can implement your own frontend easily because that is one of the main strengths of the system: makes it easy to get into complex web development if you have the time to learn.

Hello, Welcome to the Forums! Regarding your topic, you might want to checkout sites (stats) like: https://2019.stateofjs.com/javascript-flavors/typescript/ Looks like the popularity of TypeScript is declining, and I've also learned this from other sources. JavaScript is becoming more and more feature rich, so if you are really into it, I recommend getting into: https://babeljs.io/ We have a forum topic with more resource links: https://processwire.com/talk/topic/14444-state-of-js-2016/

Welcome to the forums! "What about for things that are module-specific?" Lots of old modules still work on current ProcessWire versions, but it is recommended to do a forum search in the related forum topic where you can also ask the developer. "Related to the core stuff?" The core is constantly being refactored by Ryan but normally we should use the API anyway. So most of the time this shouldn't be of anyone's concerns. "Related to templating?" Generally speaking any old code based on the API should still work as expected. Depreciation is rare if any, and Ryan is trying not to introduce changes that break old code. "Related to the API specifically?" See my previous answer above ? Others might join in and shed more lights on things, but this is what came to my mind ? EDIT: Probably PHP deprecations can cause more issues than changes introduced in ProcessWire.