Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by szabesz

  1. @Peter Falkenberg Brown Thank you Peter, personally I appreciate that you shared your script and experience.
  2. Alpine.js & Vue.js & Tabulator but it would also be a use case for any other JSON powered solution out there, of course.
  3. @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."
  4. 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!
  5. 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...
  6. 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.
  7. "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"
  8. 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.
  9. Folks not in the US are only allowed to download outdated US technology 😛
  10. Strange indeed! In Chrome it is 155 too, but in Firefox and Vivaldi it is still 153 on my Mac.
  11. 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).
  12. szabesz

    ProcessWire on the web

    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.
  13. 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/
  14. 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.
  15. https://www.pluralsight.com/ "#FREEapril Stay home. Skill up. Build in-demand tech skills without leaving your house. Get free access to 7,000+ expert-led video courses and more all month long." Note: last September's free week was OK, it WAS free of charge, really.
  16. Hello, Welcome to the forum! 404 for the admin can be caused by various issues. You can start by reading https://processwire.com/docs/start/install/troubleshooting and you can also use google to target this forum, something like: https://www.google.hu/search?q=404+admin+site%3Aprocesswire.com%2Ftalk There are just too many possible causes but if you skim through the similar topics, then you will find pointers on how to proceed, debug and what to look for.
  17. I have never found the time to dig into it, so I do not use it, but: https://blog.jetbrains.com/webstorm/2018/01/using-and-creating-code-snippets/ https://www.jetbrains.com/help/phpstorm/using-live-templates.html https://www.jetbrains.com/help/phpstorm/tutorial-creating-live-templates.html Maybe others can shed more light on it.
  18. I'm a PhpStorm user but I starred it anyway 🙂
  19. I forgot to post here that I could uninstall the module by commenting out this line (as far as I can remember): https://github.com/kongondo/FieldtypeRuntimeMarkup/blob/148626c7d3e9dc16cb9303c96b6f4c5b9ee96a75/InputfieldRuntimeMarkup.module#L68 // $this->rtmUtilities = new RuntimeMarkupUtilities();
  20. @ryan Thanx for your help and explanation! I understand that from the OOP point of view this is preferable, for example organizing the classes of ProcessWire as a system. However, we are dealing with frontend code in this case, which is not so often requires complex OOP implementation, at least in the case of my projects. Instead, I am seeking "portability", that is – for example – copy/pasting just one "articles" folder to another site in order to use it as the bases for the blog post section of that site. Features implemented in these files are somewhat different – but mostly similar – from project to project anyway, so I do not want to generalize anything in this regard. When generalization is needed, a custom helper module is a good choice, I think. Sure, everyone has her/his own way of organizing, so having options to do things the way one prefers is great. This can be solved by using cache – I guess – which might also be required for other reasons as well.
  21. Thanks for the tip! Do you maybe have a similar tip for how to specify a custom folder for field rendering files? Or a tip on how to shorten $article->render('article_lead', '/articles/fields/lead') ? I dislike the idea of scattering related files in all these directories: /site/classes/ /site/templates/ /site/templates/fields/ It is not just me who thinks that the old-school way of organizing files exclusively by type is not the smartest idea of all. I know that lots of developers have long been promoting it by using and recommending folders like "js", "css", "inc", "images", etc. in one parent folder to store them all, which is kinda ok for a small site, but storing logically related files is preferable right at beginning, because – when the need arises – refactoring for no other reason than to reorganize files is just a waste of time. The worst example I've ever encountered was Magento 1 with its frontend-theme's files scattered all over the place, making it hard to remember where to look for. Some related articles to show that I'm not alone: The project/file structure should represent its architecture. Group files by features. Simplifying Projects with a Folder-by-Feature Structure. Quote: "Unfortunately, as your project grows the traditional structure falls apart. Over time code becomes harder to find, the project is harder to maintain, and there is a lot of scrolling around the project to change code for a single feature. This is where the concept of feature folders come in handy."
  22. +1 🙂 @ryan Thanks for these great new features! However, I am wondering if it is (or will be) possible to define where to store the files of custom classes. Some time ago, I started to organize files belonging to a given parent/children template relationship into their own dedicated directory. I explained it in a bit more detail here: https://processwire.com/talk/topic/23193-mvc-architecture-and-processwire/?do=findComment&comment=198246 For example: I put this in /site/init.php for each template that needs code: $templates->get('article')->filename = $config->paths->templates . 'pages/articles/article.php'; I even put the files of field rendering under /site/templates/pages/articles/fields/ and render them like this (note: it is not seen in the screenshot above...): <?= $article->render('article_lead', '/articles/fields/lead') ?> I am asking for something similar so that I do not have to put class files into /site/classes/ , instead, I would like to store them alongside all the other related files, eg. in /site/templates/pages/articles/ or somewhere else when applicable (as it can bee seen in the screenshot, I also have a "global" folder for files not tied to a given parent/children template relation). I find it particularly useful that I do not have to hunt for files when working on a given parent/children template relationship. By sticking to my simple naming conventions, files are are always just a click away and they are also easily "portable" form project to project.
  23. I treat things similar to this, except that the separation between "view" and "controller" is created by PW's "Prepend file" feature possible via the template settings. The procedural code of the "controller" is placed into a file article-control.php, for example, while the "view" is in article.php, which is the standard template file with PHP's "alternative" syntax, just as originally intended by Rasmus Lerdorf. To keep files organized, I put this into /site/init.php for each template that needs code: $templates->get('article')->filename = $config->paths->templates . 'pages/articles/article.php'; While the location of the prepended "controller" is set in the admin like this: pages/articles/article-control.php This way I can put any article/articles related files into the pages/articles/ directory, and not just these two ones but files like included template partials, JavaScript files only required by article pages, etc.
  24. Hello, Recommend @teppo's module:
  • Create New...