Jump to content

androbey

Members
  • Content Count

    49
  • Joined

  • Last visited

Community Reputation

15 Good

About androbey

  • Rank
    Jr. Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @kongondo Wow, thank you for your effort! I would agree that user education is indeed a valid point, but also they sometimes don't behave like should do. Also giving the users some freedom is usually a good idea (if they do use the system as intended). @Robin S solution is of course really nice. Both solutions have some minor drawback for me (language page variants are disabled by default) and I thought it may be better to let the user edit the page name after all. That's why I changed Robin's solution to hide multi language title field on page creation: $this->addHookAfter('ProcessPageAdd::buildForm', function(HookEvent $event) { $restrictedTemplates = ['test-template']; $restrictedTemplatesIds = wire('templates')->find("name=". join('|', $restrictedTemplates))->explode('id'); $form = $event->return; $template = $form->template; if($template && in_array($template->value, $restrictedTemplatesIds)){ $form->title->useLanguages = false; $form->_pw_page_name->collapsed = Inputfield::collapsedYes; } }); This way I have the best of both aproaches (for me): Page has no multi language title, but page has nevertheless all languages enabled. Could probably be improved but it does its job for me. Thank you again!
  2. You described almost exactly what I found out so far. However, the trick with duplicating "PageTitleLanguage" was new. I did duplicate that and manually changed type of this field in the database. Obviously I can hook on page creation to fill the duplicated title field with data from page name. So that would work in theory. Also, I would have to keep the "original" title field in sync, when I whant to keep that field. But I also obviously missed another point: page name is also unnecessary in multi language. So that would be another "problem", which I (as I assume) can not solve with the duplicate trick.
  3. Hi @kongondo, thank you for your reply. Although I did not see it before, it does not solve my problem. This setting would disable multi language for entire template. However I am only interested in disabling multi language for page title field. I hope it's understandable.
  4. Hi all, I am currently playing with a site using multi language support, including "PageTitleLanguage". Now, for one template multi language title is not needed, but the rest of fields should still support multi lanuage. When creating a page a user is now halted to add a title in all enabled languages. I did not come up with a solution and frankly don't even know what hook to look at. What would be a could way to disable multi language support for page title field (or to hide input for non-default languages)?
  5. Hi @Mats thank you for this module! I noticed an issue when trying to crop images which where downloaded via this module on saving. The error said that the image could not be found. I assume this has to do with the page file name, which has a "." in its name, which seems to be a problem. I replaced the renaming with following line, which solves this problem for me. Maybe it's helpful for someone else coming accross this. $pagefile->rename(str_replace('.', '-', $pagefile) . ".jpg");
  6. Yeah, I thought of that and that is why I was asking. I once ran into a similiar problem, unrelated to ProcessWire. But maybe it helps when you have a look into "BOOLEAN MODE" on InnoDB, when trying to select with an "@" symbol.
  7. Hi @Pixrael, do you have some more information about the query which causes the error? Is it a 'SELECT' query?
  8. Hi @Markus (Blue Tomato), thank you for the update. I tested the new version and the generation and storage of the blurhashs works fine! On a side node, I find it still strange that the custom SQL did not (always) work. After upgrading my issue with "undefinded offset" was still present. I checked the used PHP Blurhash library and your code and I adjusted lines 108 and 109 and replaced $height and $width with $calcHeight and $calcWidth. This solves the issue (no more notices), but I don't know if it has any drawbacks..
  9. Hi @Markus (Blue Tomato), thanks for your reply. I tried again with an image found on the web, but no luck. createBlurhash for this particular image returns "LdLx}oxdzpwN}tNHNsbI#laxS}f*" (so at least seems to work?), but is not stored in the db. Image for this test: https://pixabay.com/get/53e2d14b4b5aaf14f6da8c7dda35367b1c3ddce05152774a_1280.jpg Maybe I can check tomorrow with a different test setup.
  10. Hi @Markus (Blue Tomato), I also think this is awesome! I wanted to try it, but I have some strange problems getting in running. I don't know if it is only me, but nevertheless I wanted to post here. Maybe someone can help. One strange issue at first: When an image is saved, the hash is not stored in the db table (although the "insertBlurhash" function returns true). And the second issue comes when calling the "getBlurhashDataUri" function. (I manually inserted the hash string to the database, because of the before mentioned issue). Then I'll get based on the image up to several 100-thousands warnings like "PHP Notice: Undefined offset: 208 in .../ImageBlurhash/ImageBlurhash.module.php:122". Maybe there is some config issue on my side or anything else I missed. But maybe someone has an idea. Btw. I checked it both on Windows and Linux with PHP 7.2 and latest ProcessWire dev version.
  11. Ok I found the reason why my modal does not really look like it should but I don't know why the condition is not met: https://github.com/processwire/processwire/blob/master/wire/modules/Jquery/JqueryUI/JqueryUI.module#L44 $adminTheme obviously does not evaluate to true, hence the vex theme is not set. But as I am in admin backend, it should evaluate to true, shouldn't it?
  12. This is strange. "vex" is defined and trying "ProcessWire.alert('test');" leads to a similiar result as in my screenshot above.
  13. Hi everybody, I am currently developing a configurable module (no ProcessModule). Some time ago I stumbled upon a forum post about using the VEX library in the backend. Now, I wanted to try this in my module. But with the example code I get an almost useless dialog: <?php //in init method $this->modules->get('JqueryUI')->use('vex'); //javascript ProcessWire.confirm('Are you sure you want to continue?', function() { //ok },function() { // canceled }); leads to following screen: There are no erros in console. I am using ProcessWire 3.0.148. Did I miss something or doing something wrong?
  14. @ro-bo, I tried it with ProcessWire version 3.0.148, hook code placed in ready.php and it works without any problems. Maybe a good idea is to use Tracy debugger, to get a hint where the problem lies.
  15. Hi Robert, on first look I didn't look to close to your code. Please try the following: wire()->addHookAfter("Pages::saveReady", function (HookEvent $event) { $page = $event->arguments("page"); if ( $page->hasField('my_repeater') ) { $repeater = $page->my_repeater; foreach ( $repeater as $item ) { $dateStart = $item->date_start; $dateEnd = $item->date_end; if ( $dateStart && $dateEnd && $dateStart >= $dateEnd ) { $item->date_end = ''; $item->save(); throw new WireException('start date must be earlier than end date'); }//endif }//endforeach }//endif }); Hope it helps.
×
×
  • Create New...