Jump to content

BitPoet

Members
  • Content Count

    1,086
  • Joined

  • Last visited

  • Days Won

    47

BitPoet last won the day on July 9 2020

BitPoet had the most liked content!

Community Reputation

2,542 Excellent

5 Followers

About BitPoet

  • Rank
    Hero Member

Profile Information

  • Gender
    Male
  • Location
    Near Munich / Germany
  • Interests
    programming, writing, scuba diving, long distance hiking

Recent Profile Visitors

7,085 profile views
  1. Just to add, if the points from @ryan and @horst aren't enough (they should boost import times quite noticeably) you could try dropping the FULLTEXT keys on the relevant fields' tables before the import and recreating them afterwards (ALTER TABLE `field_fieldname` DROP KEY `data` / ALTER TABLE `field_fieldname` ADD FULLTEXT KEY `data` (`data`)). Finally, a big part of MySQL performance depends on server tuning. The default size for the InnoDB buffer pool (the part of RAM where MySQL holds data and indexes) is rather small at 128MB. If you have a dedicated database server, you can up that to 80% of physical memory to avoid unnecessary disk access.
  2. @kongondo's FieldtypeRuntimeMarkup can do exactly that. You just need to add a snippet of code to retrieve and output the relevant messages.
  3. Does the dev console give no hints?
  4. Try renderPager() instead of renderPages(). And remove start=0, this prevents MarkupPageNav from increasing the offset. Only use it when you explicitly don't want to paginate your results. A number of times. I've put together a small example that works with the skyscraper demo since my original content is too specific. You can download the profile for that site here on GitHub and copy it into a (uninstalled) PW installation, then install PW with the skyscraper site profile (make sure to read up on the FieldtypeMapMarker issue in the README on GitHub). After installation, drop the template file from the attached zip into the templates folder, log into the backend and create a new template "paginated" for the file. In the template's URLs settings, enable page numbers and url segments. Then create a new page under home with the new template, give it a title and publish it. Voila, you should be ready to go. When you visit your new page, it should look like this: The pagination links should load the content through ajax. paginated.zip
  5. Have you switched section 16A for 16B in .htaccess?
  6. When you iterate over $single->zasvojenosti_select, you only get those page references that are select. You need to iterate over the possible choices like you do in the header instead. <?php foreach($pages->get(1067)->children() as $child) { if($single->zasvojenosti_select->has($child)): ?> <td>Yes</td> <?php else:?> <td>no</td> <?php endif;?> <?php } ?>
  7. The keyword ist multisite. Have a look at @Soma's MultiSite module. It's discussed here:
  8. TextformatterHannaCode is a nice multi-purpose tool for tasks like that. If manually addressing the correct files becomes an issue, then HannaCodeDialog is also worth a look. It integrates with CKEditor and lets you assemble small UIs for your Hanna codes.
  9. I meant the "Zulässige(s) Template(s) für Unterseiten" part, but that's apparently not it either. Are there any family restrictions set for the other templates that prevent them from showing up in the list?
  10. Make sure you haven't checked "Don't allow pages to change their template" on the Erweitert tab of your dummy template, and the user has page-template permissions. If that doesn't solve it, it could also be a family restriction on the template used by the parent page.
  11. Looks like I have. Found a classic case of shoot-your-foot in the affected installations where I generously added some JS in a ProcessPageEdit::execute hook, my InputfieldFile change was wholly innocent. What I did find was a race condition between the first few added files, so there was one upload more active than configured in the beginning. I believe I caught that with a setTimeout. I still have to tweak that timeout, run a few more test drives and meditate over reasonable defaults, inline documentation and such, but it's taking shape.
  12. Have you tried this: $regionEvents = $pages->find("template=veranstaltung,selectLocation.parent.parent=$reg,limit=$limit"); If this doesn't work, a subselector might be the tool of choice: $regionEvents = $pages->find("template=veranstaltung,selectLocation=[template=location,has_parent=$reg],limit=$limit");
  13. Yes, it looks like the new PHP version is missing the Ctype extension. Either the package needs to be installed or the entry in php.ini needs to be added/enabled.
  14. I'm not sure he will. Generally, a new feature needs to be used by an estimated 30% of users to be accepted into the core. There are, however, exceptions to the rule - especially where hosting issues are concerned. I'm not happy with my adaptions yet, though, since they work on some installations here but not on others. I'm still on the lookout for the issue there. However, once I work out the kinks, and if the change doesn't have to get more complicated, I think it could have a good chance to be accepted (adding a feature request at processwire-requests and finding others who vote for it would certainly help).
  15. This not really a deciding point, but about awareness that constants (as they are always static) are, just like static properties, subject to early binding. A lot of code (even mine, I have to admit) uses self:: to reference class constants and static properties, which is going to cause headache whenever such a class is extended and a constant or static property is changed. To be inheritance safe, any code that references such a value needs to use static:: instead of self:: (or address the property through the object instance). A short illustration: <?php class A { const one = 'ONE'; const two = 'TWO'; public static $three = 'THREE'; public static $four = 'FOUR'; public $five = 'FIVE'; const six = 'SIX'; function showMe() { echo self::one . PHP_EOL; echo static::two . PHP_EOL; echo self::$three . PHP_EOL; echo static::$four . PHP_EOL; echo $this->five . PHP_EOL; echo $this::six . PHP_EOL; } } class B extends A { const one = 'UNO'; const two = 'DUE'; public static $three = 'TRE'; public static $four = 'QUATTRO'; public $five = 'CINQUE'; const six = 'SEI'; } $b = new B(); $b->showMe(); That in mind, I guess the decision depends on a few questions: Is the code that is using the value executed often? In that case, constants have a small but perhaps noticeable performance advantage. If not, does my IDE of choice favor one over the other between constants and static properties? May the naming be changed at run time for an individual instance of the class? In that case, the actual value bearers have to be instance properties. For the later case, I like to use a mixed approach where my initial values are declared as constants (though a static property would be just as good) since they jump the eye: <?php class TestClass { const CLASS_PREFIX_DEFAULT = 'tpl_'; public function __construct() { $this->class_prefix = static::CLASS_PREFIX_DEFAULT; } //... } I try to avoid static access through $this:: (last line in the showMe() method above) as much as possible for my own sanity, as my head wants to make an immediate connection to instance access once it sees $this, and I'll likely end up with expressions like $this::$staticVariable, which to me looks too much like $class->$memberName, yet behaves differently.
×
×
  • Create New...