Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 07/09/2020 in all areas

  1. 1 point
    This is where postgresql outshines mysql by far. It can do stemming and accent support for multiple languages out of the box, ranking, fuzzy search, … which are the things you found missing. Many people/resources seem to suggest not bothering with mysql for advanced full text search needs, but directly going to purpose built external technologies for that, while postgresql provides a stepping stone, before needing to go that route.
  2. 1 point
    I can replicate here. There must be something wrong with the image, as it opens in FF and other deskop image viewers on windows. I recreated webp from your original jpg (using online jpg to webp converter) and this time Chronme shows the image. I have no idea what could be wrong, possible Chrome issue?
  3. 1 point
    @LostKobrakai thanks for the explanation! very helpful. Actually I created a second datetime field now, where I store the walltime of the user when the post is created. I just use this field then to display the time on frontend, instead of created. Messing with the actual created date could really make problems - thanks for the insights - especially because you still want to keep the real "order" (dependend on UTC or a universal time) of posts, even tho individual local time is different.
  4. 1 point
    Updated to 1.0.1 (Stable), mainly reducing hook priority < 200 so it runs before ProCache.
  5. 1 point
    If you're dealing with multiple timezones I'd strongly suggest not involving the db in it. There are two types of datetimes: absolute time (times you want to compare with each other even across timezones) and wall time (11 o'clock stays 11 o'clock for your user). Because timezone defintions can potentially change for future datetimes it's not always as easy to keep both properties as one might think. If only the first one is important to you you should keep everything in UTC. If only the last one is important you could use a datetime in the timezone of the user, but it's rarely the case you don't compare timestamps or it doesn't become a requirement (e.g. for ordering). For past datetimes it's enough to store a utc timestamp and the timezone of the user to get to both the absolute time and the wall time as timezone defintions rarely change in retrospect. For future datetimes you'd need to make sure to save enough information so you can detect changes in the timezone definition when they happen. Then you or your user can decide if absolute time or wall time was meant to be consistent.
  6. 1 point
    It's not only the same error in the log, but you're also doing the same thing wrong. You can't use $pages in functions because of variable scope. ProcessWire makes these object automatically available for the scope of the templatefiles, but inside a function is a new scope, so you need to either redefine the variable itself or use a function to get the object. // Template scope $id = 15; // simple variable, defined by you $pages = $pages; // the pages object, defined automatically by processwire function something(){ // this is now a new variable scope // neither $pages nor $id are available here. // the api variables are not a special global variable $pages = wire('pages'); $pages->find(""); // OR just wire('pages')->find(""); } It's the same reason, why you can't use $pages in modules. $page/$pages and the other variables are just convenient to use in templates. Everywhere else you need to call them differently.
×
×
  • Create New...