Jump to content

horst

PW-Moderators
  • Posts

    4,049
  • Joined

  • Last visited

  • Days Won

    86

Everything posted by horst

  1. Hi, it is a choice of personal preferences, definetly! πŸ™‚ I would go with a parent page and sub pages. The parent page gets a template called concerts (NOTE the plural s at the end). The settings for that template includes a single page usage and a family setting like allowed parent is, for example, "home". And allowed sub templates are the yet non existent "concert" (NOTE: singular!) The sub pages get the template concert (NOTE singular), without count limitation, but family settings restricted to allowed parent(s) = concerts. (Children for concert are not allowed) The concert template gets all your fields: date, title, desc, link, ticket link This way it is faster in backend then opening a single page with hundred(s) of repeaters. More advantages can be better SEO URLs for each single concert, (think permalinks), or at least the native match of page tree and public URLs, without any abstraction layers like URL-Segments etc. Also a later implemented archiving is easier to realize with sub pages then with repeaters. But, as said above in this post and by @virtualgadjo, it depends A) on the number of concerts you will handle and B) on personal preferences. πŸ™‚ In your concerts template file, you can iterate over all sub pages with every filter and sorting selector you like: // $page is the single (parent) page with template concerts ! <?php foreach($page->children() as $concert) { ?> <ul> <li><?= $concert->date ?>/li> <li><?= $concert->title ?></li> <li><?= $concert->desc ?></li> </ul> <?php } ?> // optional selector is easily possible, e.g. show only current and future concerts <?php foreach($page->children("date>=today, sort=-date") as $concert) { ?> ...
  2. Your text field binding in the templates should need no code changes. PW does recognize in which language a page (field) currently is accessed from the actual $user, and passes the correct values to it, according to your page- and field- language settings. (Show active language content, on empty show nothing or default language content) The __() functions are only used and needed for hard coded strings in your template (view) files.
  3. @bernhard Maybe "admin" is somehow, (also maybe by accident), a reserved word? Whats about with a quick temporary test and renaming this role?
  4. have you checked if open_sll is enabled in PHP?
  5. Hey, it seems to me that there is a wrong thinking or understanding to the whole subject that leads to the confusion. (?) If your comparison are between the compressed image from a third party tool, e.g. photoshop or others, and ONLY the webP output from GD or imagick, then this is comparing apples with bananas. If that's the fact, please read on. If that's not true, please excuse my post and my misunderstanding and forget / don't read the rest of the post. πŸ™‚ EDIT: maybe of additional interest:
  6. @wbmnfktr, @kongondo I just want to throw in a thought about a point I read somewhere above, regarding (native) endpoints in PW based on templates. If you think about the possible different processes only upon the access methods of an URI, reflected by $config->ajax (true|false). You can define an output of text/html or application/json for an template. In PW, the default is text/html. Within a general hook you we can check for registered templates and then switch the output processing according to AJAX or FETCH access. Does this make any sense to you? Or have I missed the point? EDIT: also upon the access method, we dynamically can switch the processing filename of the templates, not only the output type.
  7. https://github.com/BitPoet/AdminDevModeColors The best is the configuration through the site/config.php !! 😁
  8. Outch! πŸ˜… EDIT: but, but, - uhm, - but I enclosed a "(hopefully)" already, ...
  9. That sounds good. And I think it should not be much work (hopefully) for @adrian to incorporate that. It needs just a separation of different PHP error and warning types through dedicated error_handler function(s). I think everything that belongs to the group of "best practices and deprecations" could go into the green bag, where as all other stays in the red one. πŸ™‚
  10. I wrote a tut for you guys πŸ™‚
  11. If you want, you can filter them out and focus more on your essentials. But first things first. There is a whole list of different PHP errors, warnings and hints (notices). The one we are interested in is E_DEPRECATED. These messages indicate that a used PHP function somewhere in the code is no longer supported in a future, i.e. higher PHP version, not the actual used one. Example: The days (February 2022) I have changed my developer machine to use the latest PHP version 8.1.2. The last PHP 7.4+ is still supported for 9 months from today on, PHP 8.0 still for 1 year + 9months, PHP 8.1 for 2 years+ 9 months, and all other PHP 8+ versions each plus one more year. So the point is clear now, right? It will be year(s) before PHP 9 is on the schedule. πŸ™‚ Currently in v8.1.2, depending on what code I run, I get notices that certain PHP functions will no longer be available starting with PHP 9. (PHP 9! see above). So currently these functions are safe and supported functions, as in past versions as well as in all further PHP 8+ versions(!). No matter how many additional PHP 8+ versions there will be. ProcessWire by default allows us to suppress ALL output, or show ALL output, by the boolean configuration variable "$config->debug". This is good and right, because on a production site you should always suppress all those outputs. On a developer machine it usually shouldn't bother you if there are also E_DEPRECATED hints included. But if it does, you can filter them out as follows, for example. In your site/config.php you can define a own error handler function and load / bind it on your developer machine only. As a proof of concept or simple example, I added the following function to my site/config.php /** OWN ERROR HANDLER FOR DEPRECATION NOTES **********************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { if(!isset($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } if(!is_array($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } $GLOBALS['DEPRECATION_WARNINGS_BAG'][] = [$errfile, $errline, $errstr]; return true; // true | false = suppress further processing } /** OWN ERROR HANDLER FOR DEPRECATION NOTES **********************************************/ With the following call, also located in my developer machines site/config.php file, I bind it to all raising E_DEPRECATED warnings ONLY! So we are sure and free from all other types of errors, warnings, hints, etc. // preceed the callback function name with the PW namespace, // and define the error types that should passed to the function set_error_handler('ProcessWire\myLocalDevDeprecationErrorHandler', E_DEPRECATED); (read more on php.net) Now you will not see any of the deprecated notices any more, cluttering your screen. Neither in the front end nor in the backend. But they are all collected in our bag. πŸ™‚ A simple loop in the site/templates/admin.php, before the controller.php is called, can display any of it, maybe to the superusers only, for example: <?php namespace ProcessWire; // IF WE HAVE CACHED PHP DEPRECATION WARNINGS, SHOW THEM IN THE ADMIN, FOR SUPERUSERS ONLY if(isset($GLOBALS['DEPRECATION_WARNINGS_BAG']) && is_array($GLOBALS['DEPRECATION_WARNINGS_BAG']) && 0 < count($GLOBALS['DEPRECATION_WARNINGS_BAG']) && $user->isSuperuser()) { foreach($GLOBALS['DEPRECATION_WARNINGS_BAG'] as $deprecatedMessageItem) { $deprecatedMessageItemMSG = "PHP DEPRECATED (v". PHP_VERSION .") = \n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"; $deprecatedMessageItemMSG .= "{$deprecatedMessageItem[0]} : [{$deprecatedMessageItem[1]}]\n&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;"; $deprecatedMessageItemMSG .= "{$deprecatedMessageItem[2]}"; $this->message($deprecatedMessageItemMSG); } } require($config->paths->adminTemplates . 'controller.php'); If you want to show them on the front end to, it belongs to how you have organized your output strategy. I use a delayed output with _init.php and _main.php, where I have a special function for adding all kind of debug messages, that gets displayed on the end of the site, after the footer. Simply adding the whole collected array is enough for my information: if(isset($GLOBALS['DEPRECATION_WARNINGS_BAG']) && is_array($GLOBALS['DEPRECATION_WARNINGS_BAG']) && 0 < count($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { mvdr(['DEPRECATED ('. PHP_VERSION .')' => $GLOBALS['DEPRECATION_WARNINGS_BAG']]); // add it to the debug output region var } The outputs in admin then may look like this Or the very basic info for me on front end
  12. As far as I understand, deprecation warnings are hints to developers that pops up when error level is set to E_ALL or likely, that tell devs that this particular feature will change in future PHP versions. So, this is not an issue! This is a hint to developers who wants to be informed (on their local dev machines). So, you can suppress E_DEPRECATED on your dev machine if you are not interested in such hints. Something like E_ALL & ~E_DEPRECATED https://www.php.net/manual/de/errorfunc.configuration.php#ini.error-reporting I definitely do not alter 3-party-code that is working as expected. πŸ˜‰ The lib is from phpclasses.org Manuel Lemos. He updated it last in January 2022. I think he has used and tested it with several PHP versions, at least with 7.4+. πŸ™‚
  13. what type of error or warning is it? deprecation warning or compile error, or something differend?
  14. The exact code snippet is this: if( ( GetType($size)=="integer" && strlen($body)>$size ) || ( function_exists("get_magic_quotes_runtime") && get_magic_quotes_runtime() ) ) ... When reading this, the "error" is wrong. If the function exists, it should be used. If it not exists, it get not called at all. I run it against PHP 8.1+ and do not get this "error" you have. Module version is 0.6.0
  15. @jploch Ok, seems to be fixed. I haven't bumped the modules version number in PWs modules system now. Please manually (FTP) update these two files: https://github.com/horst-n/PageImageManipulator/blob/master/PageImageManipulator02.module https://github.com/horst-n/PageImageManipulator/blob/master/ImageManipulator02.class.php If you can try it out and report back, this would be fine. Also on github was a issue report from @Craig with a fix! (Thanks πŸ™‚ ) Haven't seen this, as I train to use git from the command line for the last month. πŸ˜„
  16. I will check and update it when I have installed a local php 8 environment. So do not expect it in the next weeks. But definetly get updated to php 8.
  17. The hook to work with images on upload, before added to any image field, is this: https://processwire.com/talk/topic/13759-tagging-multiple-images/#comment-123851 (But its just an example for the hook, not for changing the svg issue.)
  18. @pwired She, (Natasha Marques), with her full name, seems to be "the brand". If you read the first sentence: "... with an international career". So, her name is already known in the target group(s). And to use ones own name is completly common usage. Seems to be right. πŸ™‚
  19. $child->template->name or basename($child->template->filename)
  20. We all have had those days already! πŸ™‚ Please, can you set your thread title to show [SOLVED]? (simply edit your first posts headline), TY
  21. There must be at least a log file called image-sizer with an entry for the admin thumbnail. And with a recent PW version (3.0.190) your original image is behaving fine here. So, it must have to do something with your setup, - settings for image field, modules that may interfere, etc. (!)
  22. What exactly have you found in the logs? Where is the decision made to declare it as invalid? On uploading / adding, resizing? Is there the correct thumbnail already in your screenshot? How does it come that this one is created?
  23. Ok, then MSPaint has generously corrected something in the original photo what GD is not able to tolerate. Do you can enable and use ImageMagick on that server? Maybe this is more tolerant then GD.(?)
Γ—
Γ—
  • Create New...