pine3ree

Hello, fellow developers! Same here! I changed my forum/talk password coz I didn't remember the old one, so I cannot check if that one still works for the developer directory. Kind regards, maks

Innodb tables supports a maximum of 767 bytes for indexes, so floor(767/3) == 255 for utf8(mb3) and floor(767/4) == 191 for utf8mb4. So the index length should be set to 191 max. https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html

I know it's an old topic, but I had the same issue...well, I was able to keep double hypens setting the page's name in the (before) `Pages::saveReady` hook. kind regards. for multilanguage fields other than the default language I had to use Page::setFieldValue() to preserve double-hypens

@LostKobrakai Hello, I don't even consider shared hosting without access outside the web-root. :-) Most of the companies I have experience with provide cpanel and offer high level of customization for php version and for enabling/disabling php modules (even if I am more a vps+terminal/console admin kind of guy). ....but I agree, it's not a high priority feature and it's targeted especially for developers. Most cms/cmf software put everything inside the web-root also because the installation process is much simpler and direct for less experience users. kind regards

@strandoo same (no issues) here....using pw 3 + php 7.0 with page load times from 27 to 66 ms and the memory usage ranges from 2 to 4 MB. Can You give some details (number of db queries, number of fields, templates, pages, installed modules)?. I also suggest to try a clean basic-profile install and see if the issue disappears. Then enable 1 module at a time and see what happens using a second browser (or a private navigation window) for visiting as guest user. kind regards.

@LostKobrakai Hello, I (respectfully) do not completely agree on that. .htaccess rules are implemented and forced by the web-server. If there is a security hole in a particular version of the webserver that is reflected onto the website. .htaccess rules do not always work as expected expecially if you are not the one controlling the web-server config (VPS setups or own server). More than one time I had issues with shared hosting. Even directory access protection (basic http auth) stopped working due to global rules invalidating/discarding some of my .htaccess rules that have been working (and still are) for years. And I am not talking about small hosting companies, but big and respectable/respected companies. .htaccess rules is a further layer of security you depend on, not relaying completely on it can be considered an improvement. Thus I always prefer having everything ("upload" folder included) outside the the web doc-root excluding the front script (index.php) and the static assets (or symbolic links to them). I also like to have a customizable directory structure to make things more difficult to guess from attackers. When possible (this does not depend on the cms/framework) I also like restricting php execution to the front script. Over the years (since year 2000 :-)) I've seen many kind of attacks, circumventing well programmed form handlers and uploading code as fake images. So in my opinion having only 1 php file and read-only static assets inside the webroot makes it a lot more difficult for bad guys. It's a feature that I'd like to see in PW and that I asked Ryan about a while ago. kind regards.

Hello MrSnoozles, in Processwire template files are not actually templates and You can actually use them as controllers (see the "delayed approach" in pw tutorials). In template files You can manage the request ($input), build forms (InputfieldForm module instances) and assign variables which are later used in the included view file(s). (btw, I use the ".phtml" extension for my views/partials to distinguish them from template/controller files ".php"). If you ever worked with Silverstripe you can actually think of template files code as Silverstripe's Page_Controller classes ' method code. You can leverage pw's urlSegment feature to add sub-routes for the current page/template. If you have a contact-page template (/contact-us/) You can use a "submit" segment ($input->urlSegment(1)) and use "/contact-us/submit" as the form action, the same way You can add any route segment in a Silverstripe (Page_)Controller class. I don't find it useful to add code used only by the "contact-page" template in a global function inside (_func.php). As in Silverstripe cmf the segment approach has the advantage that it continues to work even if you change the url (name) of the page using that template. Think of template files as controllers: while in other frameworks you have to assign controllers to routes, in PW a route (Page path/url) is automatically linked to a peculiar controller (template) by the fact that the Page with that route is using that template. kind regards, maks feltrin

The simpler solution is to always use: setlocale(LC_NUMERIC, 'C') after setting LC_ALL to custom locale. This helps avoiding a lot of issues as LC_NUMERIC tells the code parser how to output numeric expressions. For instance with: setlocale(LC_ALL, 'it_IT.UTF-8'); 1.234 will be written as 1,234 when used as string, like in string concatenation (as in db query builders) . But database and most other data endpoints still expect 1.234 for decimals. It is always better to use LC_NUMERIC 'C' and call numeric/monetary output formatting helpers explicitly in templates.

Thank You, hope you enjoied your vacation. It was a real quick port I needed up and running. I'm sure that you - not being new at pw as am I - will be able to port the idea in a better and more elegant way into your more known and tested module. kindly

Hello forum, a newbie question: having a multilingual setup, /sitemap.xml would be redirected to /en/sitemap.xml if language name is enableb for the default language (english in this example). I dont want to use the existing module because i don't want it loaded on each request and because i need more customization. So i decide to use the home page with urlSegments on, intercepting urlSegment(1) == 'sitemap.xml' only for the default language. Are there any cons in using urlSegments in the home page other than the need to render the 404 erro page for any other urlSegment? kind regards

great! thank you!

Hello Niko, i quiclky ported the wp shortcodes parser i made for SIlverstripe 3.1 to this: https://github.com/pine3ree/MarkupWPShortcodes of course being a port of the same library it's quite similar to yours. The module loads a default (*) definition file if found. You have also a public load($fullPath) to load other files other then default in templates. Or you can just use the add method. (*)I am in a hurry for a project so i didn't make it configurable, but that's easy to add. Inside the definition files, since are included inside the class you add shortcodes like this: $this->add('test1', function ($atts) { echo '<h3>This is a test shortcode with tag=test1</h3>'; }); in a template you can call: $shortcodes->load($config->paths->templates .'/shortcodes/extra.inc'); to add custom definitions for that template or simply, like your module: $shortcodes->add('test2', function ($atts) { echo '<h3>This is a test shortcode with tag=test2</h3>'; }); let me know if you have other suggestions to make it better, kind regards

SHORTCODE DEFINITIONS FILE INCLUSION: Hello Niko, i was thinking.... - we could define a standard or configurable location for the shortcode definition file. - we could add an initialized property for the module - when $shortcode->initialized == false we force the shortcode load the definition file and set $shortcode->initialized = true . we check for initialized inside the render method, if not => load the file so if we don't need shortcode rendering in a page render we avoid loading the definition file use case (let's assume we wants to parse the body field) if ($body = $page->body) { echo $shortcode->render($body); } if !$body => the definition file would not be loaded. what do you think? (in silverstripe 3.1 i ported the wp shortcode parser and the callbacks definition were actually static methods in a static class) kind regards

i understand this is a very old question... if $page is available wherever you define the shortcode closure: $shortcode->add('foo', function ($atts) use ($page) { //NOW I CAN USE $page here! }); but of course, wire() makes all the pw api vars available to you.

Hello Soma, forgive my (maybe idiotic) question, but i'm still new at PW and so i would like to report why the module isn't working for me. i had a 500 server error, cheching the logs i saw a notice explaining that the constant PHP_TUSAGE was already defined, then i remembered... i use $page to implement widgets and to render a widget in a widget group i foreach-loop it and call $widget->render() on each widget page, so that they use their own simple no-header/no-footer templates files => this of course makes more than 1 call to ChromePhpLogger::startDebug(). Could it be possible to move start/stop debug elsewhere? I have recently used debugbar in pw, but in my case i added (inder the $config->debug+superuser condition) manually in my common header footer what was needed to make it work. kindly