Jump to content

wumbo

Members
  • Content Count

    19
  • Joined

  • Last visited

  • Days Won

    1

wumbo last won the day on July 30 2015

wumbo had the most liked content!

Community Reputation

28 Excellent

About wumbo

  • Rank
    Jr. Member

Profile Information

  • Gender
    Male
  • Location
    Hanover, Germany

Recent Profile Visitors

1,631 profile views
  1. 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.
  2. 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.
  3. Thank you very much! I thought, I tried this. But I never refreshed the modules cache, I guess.
  4. 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.
  5. 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.
  6. Just forget it. This works quite as planned (using the non-namespaced address for the hook) as soon as I fixed my other bug ...
  7. 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
  8. 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.
  9. 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
  10. 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
  11. Here are some screenshots. The field: The dialog:
  12. 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.
  13. 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/
  14. Hi folks! I'm about to add my new module FieldtypeAssistedURL to the repository. You find the source code on github and hopefully in the modules repository soon. Here an extract from the README.md: This module offers you a new field type AssistedURL Field, providing and input field for storing absolute and relative URLs. The field type adds a button to open the URL chooser dialog known from the CKEditor link feature without the tab navigation bar for specifying link attributes. Using the URL chooser dialog the editor may select URLs from internal pages or uploaded files via a search field with auto-completion, a page tree control, and a file selector control. Please feel free to post suggestions and any form of feedback here in the forums or on github. Wumbo
  15. It just came to me, that I don't need to reassemble the url chooser dialog, but only the button that opens the dialog and a little bit of js surroundings. I think, I ready-to-use module will be available in the repository soon .
×
×
  • Create New...