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,780 Excellent

About szabesz

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location

Recent Profile Visitors

6,660 profile views
  1. +1 🙂 I have not used it yet because currently I do not have to implement payment for sites in Europe, but living there it can easily happen and it is good to know that we have a ready made solution. Thank you so much!
  2. Hello, Related topics that should give you ideas on how to implement such a thing: https://processwire.com/talk/topic/14273-can-processwire-do-this-user-management-profiles-search/ https://processwire.com/talk/topic/1755-users-login-to-separate-project-areas/ https://processwire.com/talk/topic/18395-user-admin-on-front-end/ https://processwire.com/talk/topic/16401-is-it-possible-to-login-to-a-user-from-the-frontend/ https://processwire.com/talk/topic/9811-frontenduser-login-logout-and-register-users-members/ https://processwire.com/talk/topic/13399-frontend-forms-for-users-to-input-and-update-data/
  3. Relatively recently released: https://github.com/LINCnil/GDPR-Developer-Guide (GDPR guide for developers, v1.0)
  4. Unless I want to save the value of a page object's property in the database, I would not change a page object's property because it is reasonable to expect that a property corresponds to a value in the database. If I change the property but do not save it to the database, then from that point on it is "confusing" to keep track of the actual value of the property as its value is no longer "in sync" with the database (as long as we are talking about the same request being executed, of course). To tell the truth, I do not really get what you are trying to solve. I was just trying to point out a few things that might – but not necessarily – cause issues.
  5. I presume that $product is a ProcessWire page object, so you should not overwrite its $title property anyway. You should be able to compose the breadcrumb's html block in advance and store it in a variable to be outputted ("rendered") later on. If you render the breadcrumb on almost all pages, the simplest solution is to compose it _main.php's opening <?php namespace ProcessWire; block. I am not saying this is the best place, you should be able to do it in _init.php too. For example, in one of my sites I use Ryan's ukBreadcrumb() function: https://github.com/ryancramerdesign/regular/blob/master/site-regular/templates/_uikit.php Which is included like this in _init-php: include_once('pages/shared/utils/uikit.php'); // UIkit 3 library of Regular Blog Site Profile I do not even store its returned value in a variable, I just output it like this where it needs to be: <?= ukBreadcrumb() ?> Hope this helps.
  6. Additionally, Ryan is usually very busy on weekdays so he might miss some messages sometimes. He usually addresses issues from Friday to Sunday, but this is a just a general guideline for you not a "rule" or something like that. For this reason, if you buy one of his modules, I recommend that you place the order before or on a Friday and make sure you will have enough time to test it so that you don't run out of the 7 day timeframe of the refund option in case you need it: https://processwire.com/store/pro-cache/ see: Terms and Conditions: "...If you find ProCache does not meet your needs and that you won't be able to use it, let us know within 7 days of purchase and we will refund your money in full...."
  7. Hello, in line 3 and 4 you simply overwrite the values you assigned to the properties in line 1 and 2. In other words: your _init.php and _main.php do not get prepended/appended because what you added afterwards is to instruct ProcessWire to prepend/append _head.php/_foot.php instead. I recommend removing the two lines you added and use _main.php to define the placeholders for your header and footer. Something like this: In this linked example of @Pixrael <header> and <footer> are not defined as regions but you are free to do it if you need to change them on page-by-page cases.
  8. PHP Notices are not something to fix immediately but one should deal with them as soon as time permits. It is because they signal some unintended behavior and naturally, we are not aiming for such a thing. Specifically, "Trying to get property 'XYZ' of non-object" is a common issue, which means that – for example – in the $page->id->int expression the ID property is an integer and as such has no properties because it is not an object (aka "non-object"). Therefore trying to access ->int results in this notice. This also means that if ($article->int == $page->id->int) will not work as intended. This is the way engineering works 🙂 However, sometimes just take a break and learn form professionally crafted tutorials, such as this one: https://www.youtube.com/watch?v=D8ZcKqevECY&list=PLLQuc_7jk__WTMT4U1qhDkhqd2bOAdxSo&index=1 The hard part is to find good tutorials, of course.
  9. The funny thing is that you do not have to! I mean, you don't have to learn too much about PHP in order to develop sites with ProcessWire. I recommend installing and studying Ryan's Skyscrapers 2 site profile (https://github.com/dadish/pw-skyscrapers-profile) and some other more recent ones which look interesting to you: https://modules.processwire.com/categories/site-profile/?sort=-created
  10. As @Robin S explained, there is no reason to echo anything in a context like that. If you just put any other PHP code there, that will not be executed twice (at least it should not do that for sure). Only echo() is what gets executed twice but it should not even happen once, meaning not calling echo() is the "solution". I have sites with various code being executed in that context, none of them runs twice.
  11. Hello, No, it's not. Probably something else is behind the cause of this. I do not think simply using Markup Regions should result in such a behavior.
  12. By using the best upcoming, still in the works but already pretty awesome front-end framework: https://www.gethalfmoon.com/docs/introduction/ 😉 Anyway, I recommend Markup Regions.Docs and useful tips: https://processwire.com/docs/front-end/output/markup-regions/ https://processwire.com/blog/posts/pw-3.0.70/ (Markup Region hints section) https://processwire.com/talk/topic/19025-friday-update/?tab=comments#comment-165581 https://processwire.com/talk/topic/23641-markup-regions-pw-vs-data-pw-different-behavior/ https://processwire.com/talk/topic/24031-helpful-tips-for-markup-regions-and-ids/
  13. I see. In that case if you want to learn a PHP framework then depending on your needs I would recommend: Codeigniter 4. Pros: if you are seeking something easy to learn. Small file base. Cons: when looking for a job opportunity, you are less likely to find one needing Codeigniter 4 knowledge. You need to implement your own Login/Registration, even an admin interface must be "built", eg: https://github.com/PemaRekdenDorjee/ci_admin Symfony: Pros: probably the framework used by most "professionals", so job opportunities are abundant when you reach that level. Also, it is reusable PHP components based, so those parts of the system you do not need must not be downloaded/used. PrestaShop core developers already started to refactor PrestaShop by using Symfony. Cons: you get sort of "bare-bone" components and you need to implement your own Login/Registration, for example, even an admin interface must be "built". Laravel: Pros: also widely used but not as part of other frameworks, instead, mostly as the bases of custom sites/applications. It this sense it is "similar" to ProcessWire. You can also find ecommerce, admin, forum and other open source "addon-on solutions" for it. Cons: huge(!) file base, for a small site – for example – it is big overkill to use Laravel, see: https://www.google.com/search?q=Laravel+is+huge CakePHP: Pros: relaitively speaking it is not based on a lot of files, but with 30k+ files it is not "slim". Easy to learn and in this sense similar to Codeigniter. Cons: a bit of a system of the past. Yii: Pros: widely used framework by "professionals", good for job opportunity seeking. You can find admin/ecoomerce extensions for it, or ecommerce systems are based on it. Cons: file base is not small, though it is usually smaller than Laravel. The others: you can also investigate them, similar to what I did above. As for PrestaShop: it is probably the most versatile PHP based ecommerce solution out there, but it takes a lot of effort to learn it, especially if you want to implement modules for it. Basic module development is easy tough, but the hard thing comes when you need to study the internals of this complex system which is being rewritten, so you need to keep up with all the changes, too. Cons of PrestaShop: some things like displaying prices on the frontend cannot be customized enough. If you are lucky it suits your needs, if you are not, then you cannot set it up the way you want. Similar issues are present in other areas of PrestaShop. While it is highly configurable, it is easy to find that there is no way to configure things the way you require. Also, instead of "hooks", it provides overrides to customize the inner workings, which is a limited method compared to a system with a well defined hooking system. The very best thing about ProcessWire is that what you have learned about it years ago can still be used almost 100% today. This cannot be said about most PHP framwworks out there, includnig the ones I picked above.
  14. Hello, some random thoughts, hoping that they will help you. If you can wait, then wait for Padloper 2. I cannot tell you how much waiting it means but think of months, I guess. I would not recommend trying to merge them with ProcessWire if you are thinking of doing it. Also, if you are not a PHP expert (just yet...) then if you decide to use any of those to build complex sites, well, then after you have implemented a few of them based on such frameworks you will definitely become a PHP expert. But doing so will take a few years for sure. If you want quick results with ProcessWire, I would recommend Ryan's modules. He also provides invaluable help for his customers. As for Buddypress and such, there is no clear winner to recommend for using it along with ProcessWire. However, if you purchase LoginRegisterPro, you can ask Ryan about help and tips on how to integrate something like that into a PW site, if you need such a thing.
  15. Hello, your assumptions are correct. ProcessWire should delete all images along with their variations when a page is deleted (trash emptied / skipped). However, cleaning up no longer used variations is a different matter (meaning you still have the page but not all image variations are actually in use): https://processwire.com/talk/topic/20472-pw-30121-– core-updates-and-more/ https://www.google.hu/search?q=orphaned+variations+site%3Aprocesswire.com Also, if ProcessWire have already generated a given image variation, it will not regenerate it on each page request, of course. Forum topics exist on how to regenerate them "forcefully": https://www.google.hu/search?q=regenerate+image+variations+site%3Aprocesswire.com Hope that helps.
  • Create New...