Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


szabesz last won the day on March 1

szabesz had the most liked content!

Community Reputation

2,683 Excellent

About szabesz

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

6,285 profile views
  1. 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.
  2. 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.
  3. I'm a PhpStorm user but I starred it anyway 🙂
  4. 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();
  5. @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.
  6. 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."
  7. +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.
  8. 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.
  9. Hello, Recommend @teppo's module:
  10. @bernhard Thanks for this discussion, it is great that you raised this issue this way. I've found another one: https://github.com/rlanvin/php-rrule this one does not seem too have to many issues but it is hard to tell... I think supporting recurrence out of the box might be a good idea as adding it later might generate unnecessary refactoring work. I am just guessing though... As for time zones, most projects can do without it, so if I were Bernhard I would not deal with it.
  11. Thanks for working on FieldsTableTools, supporting uniqueness at the DB level is an important addition to the system for sure! However, while you are at it, please also consider this HIGHLY POPULAR request: https://github.com/processwire/processwire-requests/issues/126 Looks like this is the right moment for you to also implement a decimal fieldtype for the core.
  12. Yes I do. I thought there is "custom data" related to each order but if not, then that is a different story.
  13. Now I know why those emails often ended up in the spam folder... Thanks for the improvement!
  14. Each pw order page could store the data of the related extra order fields. Order pages could be saved under Admin (page id 2) > Snipcart Orders > [order#n] similar to the way PW saves repeaters "hidden" under the Admin page.
  15. What do you mean by saying "start with"? Is the example above a prefix or the complete fieldname? Why not? 🙂
  • Create New...