wumbo

Ok, thank you.

Hi, all! I "inherited" a rather old processwire project and managed to upgrade the ProcessWire core version and nearly all installed modules to recent versions. Only the installed pro module ProFields: Table can't be upgraded via the module manager of ProcessWire. The module ProFields: Table must have been purchased by my clients at some point in time (no billing or license information is avalaible to me) and is still in use. Currently version 0.1.3 of ProFields: Table is installed. My problem is, that I upgraded the related module Table CSV Import / Export that depends on ProFields: Table. This depending module (now using vesion 2.0.16) apparently is not compatible with ProFields: Table v.0.1.3 . The concrete problem is that when using the csv import feature of the module Table CSV Import / Export, it uses some kind of Hook or public api of ProFields: Table that did not exists in v0.1.3. In detail it's a call to $tabelRows->new(...); // file TableCsvImportExport.module.php, line 512 I fully expect this problem to disappear as soon as I upgrade ProFields: Table to its current version. So in short: How do I upgrade ProFields: Table? Thanks in advance, Marco

I think something like this would be better: class ProcessPageView extends Process { // ... public function ___execute($internal = true) { // ... $page = $this->getPage(isset($_GET['it']) ? $_GET['it'] : '/'); } public function ___getPage($it) { // use $it argument instead of $_GET['it'] } } With this, the PW core could do its thing as always, but users may change the page look-up behaviour bei hooking into ProcessPageView::getPage.

Hi, I'm about to implement a multisite project with PW3 (which is great btw!!!). Because of "reasons" I need to implement my own routing. To do this I implemented a little module the hooks ProcessPageView::execute(). I reviewed its code and found out, that the actual logic to look-up the requested page from the request is placed in a protected method ProcessPageView::getPage(). And because this method is currently not hookable, I needed to do a dirty hack (overriding the GET.it parameter that is inspected by ProcessPageView::getPage()). I suggest making ProcessPageView::getPage() hookable and pass the arguments for the page look-up via method arguments instead of inspecting the GET scope within the method.

Thank you very much! I thought, I tried this. But I never refreshed the modules cache, I guess.

Hi there! I'm using ProcessWire 3 and I'd like to build a module that tabs into the ProcessPageView::execute hook. Currently I've built a small module that defines the hooking in its init() method as usual. public static function getModuleInfo() { return [ 'title' => 'MicrositeRouting', 'version' => 001, 'summary' => 'Routing logic for microsites', 'requires' => 'ProcessWire>=3.0.14', 'autoload' => 'template!=admin', 'singular' => true ]; } public function init() { $this->wire('log')->message(__METHOD__); $this->addHookBefore('ProcessPageView::execute', $this, 'lookUpPage'); } public function lookUpPage(HookEvent $event) { $this->wire('log')->message(__METHOD__); } I provided some log messages to check if the module works. But it seems that in spite of the module being initialized properly (the message is found in my logs), the hook itself isn't processed at all (the log doesn't show the corresponding message). I surely missed something important but currently can't find it. Thank you for any suggestions.

I think not. My problem is, that in my scenario PW tries to start a session a second time without checking if a session is already active. The session configuration is another topic.

Just forget it. This works quite as planned (using the non-namespaced address for the hook) as soon as I fixed my other bug ...

Hi everybody, im planning to release an updated version of the TwigReplace module for ProcessWire 3. In addition to the known config options for setting up the twig environment, I'm wantg to provide the means to enable twig extensions at will. But this can't be done via module config options because of different reasons (finding the correct twig extenion classes - installed or self-made, providing constructor arguments to the twig extension, ...). To solve this I plan to add a hookable method to my module that instantiates and returns the Twig_Environment object. If this works, users of the module may create their own project specific modules to intercept this hook and modify the Twig_Environment instance by adding twig extensions at will. Here's the skeleton of my module (with ___initTwig() being the hookable method): namespace nw\ProcessWire3; use ProcessWire\FileCompilerModule; class FileCompilerTwig extends FileCompilerModule { /** * @var \Twig_Environment */ protected $twig; /** * Creates the twig render engine if necessary */ public function init() { /* * gather module config settings ... */ $this->twig = $this->initTwig($pwTemplatesPath, $twigOptions); } /** * Instantiates a Twig environment * * THIS IS THE HOOKABLE METHOD. * * @param string $pwTemplatesPath * @param array $twigOptions * @return \Twig_Environment */ public function ___initTwig($pwTemplatesPath, array $twigOptions) { $loader = new \Twig_Loader_Filesystem($pwTemplatesPath); return new \Twig_Environment($loader, $twigOptions); } This works fine so far. But when I try to hook into the ___initTwig method via another module, nothing happens. Now I'm not sure if the entire concept (hooking into a module from another module) isn't supported by ProcessWire, or if I just haven't found the correct way to address the desired hook (maybe due to namespacing issues). So far I tried: namespace nw\ProcessWire3; use ProcessWire\HookEvent; use ProcessWire\Module; use ProcessWire\WireData; class FileCompilerTwigExtensions extends WireData implements Module { public function init() { $this->addHookAfter('FileCompilerTwig::initTwig', $this, 'addTwigExtensions'); // didn't work either // $this->addHookAfter('nw\ProcessWire3\FileCompilerTwig::initTwig', $this, 'addTwigExtensions'); // $this->addHookAfter('\nw\ProcessWire3\FileCompilerTwig::initTwig', $this, 'addTwigExtensions'); } public function addTwigExtensions(HookEvent $event) { /** @var \Twig_Environment $twigEnv */ $twigEnv = $event->return; $twigEnv->addExtension(new \Twig_Extension_Debug()); } } I'm thankful for any suggestions. wumbo

I just added the line $page->status = Page::statusHidden; to the ___install() method of the plugin. This prevents the page from being displayed in the sub menu of the Pages item of the editors main menu. I'm using ProcessWire v2.6.1.

Hi folks! I'm currently using the Pages::__save() hook within a custom module to inform an external service that a page was saved. Now I only need to inform the external service if a valid page was saved (no field validation errors occurred). ProcessWire saves the page (even published pages) regardless of any field validation errors (e.g. missing input for a required field). Is their any way of validating a page instance within my module? Something like $myPage->isValid()? It would also help if someone could point me to the relevant lines of source code where the ProcessWire editor validates page input on saving. Regards, Marco

Hi folks! In my current project I'm using ProcessWire v2.5 as pure backend service, including it in my frontend application as described here. Now I encountered some problems with the pw session handling interfering with the session handling of my frontend application. In this case the pw installation runs on a subdomain of my frontend application. Duplicate session_start() Each time I include pw's index.php pw tries to start it's own session, resulting in a notice that a session has already been started. To encounter this problem, I changed one row in Session::___init() (/ProcessWire/wire/core/Session.php): protected function ___init() { if (session_status() != PHP_SESSION_ACTIVE) @session_start(); } Session configuration override Additionally pw sets it's own session configuration and therefore overrides the config of my frontend application. To prevent this, I wrapped the session configuration block within the index.php (/ProcessWire/index.php, rows ~176ff) in a condition: if (session_status() != PHP_SESSION_ACTIVE) { session_name($config->sessionName); ini_set('session.use_cookies', true); ini_set('session.use_only_cookies', 1); ini_set('session.cookie_httponly', 1); ini_set('session.gc_maxlifetime', $config->sessionExpireSeconds); if (ini_get('session.save_handler') == 'files') { if (ini_get('session.gc_probability') == 0) { // Some debian distros replace PHP's gc without fully implementing it, // which results in broken garbage collection if the save_path is set. // As a result, we avoid setting the save_path when this is detected. } else { ini_set("session.save_path", rtrim($config->paths->sessions, '/')); } } } This is surely a bad way to fix my problem, because I had to change some code within the pw core. If anybody knows a more elegant solution to prevent pw from starting/configuring a session if used vi include, it would be very welcome. regards, Wumbo

Here are some screenshots. The field: The dialog:

Hi Adrian, 1. This seems to be the default behavior of the FieldtypeURL, which this module extends, or the InputfieldURL, which is used be the module. I'm not sure it's necessary/wise to change that. 2. The whole purpose for developing this module was to mimic the exact behavior of the link chooser dialog of the CKEditor module. This dialog wraps the marked rte content with completely rendered <a> tags. All I do is getting the href attribute from this <a> tag and copy it to the InputfieldURL. I'll try to introduce a config setting to choose whether to return a page's url or it's id. 3. I replaced the buttons text with the link icon.

And there it is: http://modules.processwire.com/modules/fieldtype-assisted-url/ https://github.com/marcostoll/processwire-fieldtype-assisted-url https://processwire.com/talk/topic/10530-module-fieldtypeassistedurl/