Mike Rockett

Have just submitted a patch to the dev branch. Please give it a try and let me know if it works. Thanks

Those columns shouldn't be empty at all. If no date is specified, it should use 0000-00-00 00:00:00. Also finding that to be quite strange because both the importer and the 'editor' use the same function (commitJumplink) to insert the jumplink. Going to test this out on my Linux server to see if I can reproduce this. Update: Okay, I'm able to reproduce this in CloudLinux running LightSpeed (and, thus, I'm sure many other nix setups will be the same). However, in my case, the date columns are not empty, but contain the zero date. I'll try and figure out what's going on.

That is indeed how it should be... I assume you're running on Linux? I develop on Windows, and it appears that most of the troubles that have come up relate to OS differences... I think I'm going to need to spend some time refactoring Jumplinks.

Hey Macrura - yeah, this seems to be quite weird. I'm sure it has something to do with storing null dates. Can you check in phpMyAdmin (or whatever you use) what the date is in the DB?

I think the context may be wrong. I don't know Joomla at all, but, to me, site:create would imply a multi-site environment, especially considering the existence of site:delete. Or am I wrong?

The dev branch is generally very stable, and can be used in production sites. That said, I suggest you have a look at this thread for more information. However, as Martijn has posted, we are very close to the 2.6 release, which implies that 2.5.28 is stable. I am using the dev branch on all the sites I'm building right now.

Small update committed to dev branch: Debug Mode now shows conversion notes for each wildcard, as in the example below. This gives a little more insight, which I think is quite useful. Page not found; scanning for jumplinks... - Checked at: Fri, 24 Apr 2015 12:18:16 +0200 - Requested URL: http://processwire.dev.local/Articles/2015/4/24/Hello%20World.HTML - PW Version: 2.5.27 == START == [Checking jumplink #12] - Original Source Path: Articles/{year}/{month}/{day}/{all}.{ext} - After Smart Wildcards: Articles/{year:num}/{month:num}/{day:num}/{all:all}.{ext:ext} - Compiled Source Path: Articles/(\d+)/(\d+)/(\d+)/(.*).(aspx|asp|cfm|cgi|fcgi|dll|html|htm|shtml|shtm|jhtml|phtml|xhtm|xhtml|rbml|jspx|jsp|phps|php4|php) - > Wildcard Check: 1> year = 2015 -> 2015 - > Wildcard Check: 2> month = 4 -> 4 - > Wildcard Check: 3> day = 24 -> 24 - > Wildcard Check: 4> all = Hello%20World -> hello-world - > Wildcard Check: 5> ext = HTML -> html - Original Destination Path: blog/{all}/ - Compiled Destination Path: http://processwire.dev.local/blog/hello-world/ Match found! We'll do the following redirect (301, permanent) when Debug Mode has been turned off: - From URL: http://processwire.dev.local/Articles/2015/4/24/Hello%20World.HTML - To URL: http://processwire.dev.local/blog/hello-world/ I have a few plans in the pipeline, such as the ability to use your own expressions, but not decided yet. Lastly, an issue came up a few days ago, where a jumplink is not working. I'm sure it has something to do with timed activation, and will look into it when I have more information. Seems that the end time (when not specified) is not being calculated properly. Normally, it would create a dummy time. I may actually need to look at redoing the whole timed activation feature...

Hi, and welcome to the forum, and to PW! I'm not sure why you'd want to do that - it really doesn't sound logical to me. That said, I don't think it's possible as I understand PW is very reliant on tree-structures (in other words, they are what they are). If there is a way of doing it, I'm sure someone else will be able to point you in the right direction. Would it not be viable for you to just put your service pages under the root?

Mmm, it seems it's working now, with no intervention on my end. Module upgrades are not working (even after manually upgrading ProcessWireUpgrade), but saving pages is working. The form data being sent (as mentioned before) is actually correct (surprisingly), as it works locally. I'm going to try a few things, such as re-installing the site on the server (via FTP, usual method) or, if that doesn't work, I'll do a profile export to a fresh installation. If all fails, then I'll get in touch with my host. By far, this is the weirdest thing to have happened to me... I'm almost convinced that it isn't a PW problem.

Okay, so I've just downloaded the installation from the production server to see if the same thing would happen locally. It doesn't. I can't really figure out what's wrong here. The file and folder permissions are set properly, and everything was working about a month ago. Any clues?

Hi all Seems I've bumped into an issue where, if I save a page or update a module, I'm redirected back to the home page (frontend). I was using 2.5.23-dev, and thought that an update to 2.5.27-dev would fix it, but no luck. No errors showing up in any logs either. The following modules are installed on the site: AIOM Diagnostics Map Marker Data Tables Maintenance Mode SEO Modules Manager Jumplinks Upgrades Template Notes Upon inspection, module/download/ is sending a 302 redirect to /. Interestingly, the inspector says that the following form data was sent to module/download/: godownload: Download and Update (0.0.4) which is the text for the button (was trying to upgrade the Upgrades module). I assume that is the problem? Update: This doesn't happen with every page, however. If I save the home page, I get redirected back to the home page. If I save the "certification" page, I get redirected to the home page. If I save the "donate" page, however, then it saves and reloads.

@Macrura Thanks - I'm glad you're liking it. Yeah, documentation is pretty important to me, and so I make sure I do it to the best of my ability. Originally, I wanted to host the documentation myself, but thought the GH wiki system would be perfect enough for the task. Regarding the selectors, I'm going to leave the implementation as-is for now (as mentioned in the docs).

Version Bump to 1.2.0 - Important Upgrade Destination Selectors Fix ProcessRedirects Importer (You can now also try the import again, if the previous import gets botched somehow) Various other enhancements and important fixes No schema changes

You're very welcome. Ah, you are right. Will edit that for others' reference.

Your code is saying the following: If the domain is not the second domain, then redirect to the main domain. As such, you should change it to this: Option 1: "If the domain is not the main one, redirect to the main one" RewriteCond %{HTTP_HOST} !www\.mymaindomain\.de$ [NC] RewriteRule ^(.*)$ http://www.mymaindomain.de/$1 [L,R=301] Option 2: "If the domain is the second one, redirect to the main one" RewriteCond %{HTTP_HOST} ^www\.myseconddomain\.de$ [NC,OR] RewriteRule ^(.*)$ http://www.mymaindomain.de/$1 [L,R=301]

Okay, so it appears the problem is coming from here: .cke_chrome { display: block; border: 1px solid #e5e5e5 !important; padding: 0; float: left; <------------- width: 100%; <------------- box-sizing: border-box; } Removing those lines fixes the inline toolbar, but it breaks the cke_chrome component for the classic editor. in that it lands up being 0px high, and so the border collapses and doesn't wrap around the entire editor. You can't use overflow:hidden there because then the tooltips for the inline editor break. It's like a naughty child that just won't stop. Nonetheless, I hope it points you in the right direction...

@Peter: The toolbar is going full-width for some reason. Seems that the inline style is being set to left: 0... Or this has something to do with width... No idea.

So I seriously think LightWire should be the default CKE skin.

Before I merge, I'd actually like to discuss the behaviour of the new selectors feature. In its current state, you specify a selector in your destination path using square brackets ([[your-selector-goes-here]]). However, you can also use multiple selectors, and prepend and append to them, which I don't think it actually the right way to do it. Prepending a string to a selector will cause a redirect to a non-existent page. As such, I propose the following: Instead of using double-square brackets to return the URL of the new destination page (using $page->url), I think it should return the name. This is handy when you want to redirect /blog/2015/<oldname> to /journal/<newname>/, for example. Then, to return a full URL, we should use use find: as a prefix to the selector - find: template=basic-page, legacy_name={name}, for example. What do you think?

I see how this tagging feature can become an issue, especially for new users. This thread, which has been moved, is a good example - it now has tags that aren't appropriate to the sub-forum, and its badge is the same as the topic title. Could someone take a look at that? Edit: Thanks LostKobrakai

I may have missed something somewhere there, but Jumplinks does work when you're in a sub-directory (my test-cases worked), and so your destination should only contain the path after your installation root. Nonetheless, I will look into it.

New commits to the dev branch synced. Fixed the select statements, as mentioned above (still working here). Also, if the import from ProcessRedirects gets botched somehow, you can now try again. It doesn't keep track of the state of ProcessRedirects, so if you uninstall and reinstall it, the importer will still offer you the opportunity. However, that isn't an issue in my eyes as such a process-flow is not practical. Hoping to merge into master as soon as possible. I'll give it another day (or just less, keeping in mind the severity of the issues encountered with the current 1.1.3) for more feedback until I merge.

In agreement with teppo here. My average speed HSPA connection took 31 seconds to load everything up, which is far too long. That aside, I like the design, and the choice of font. Great work

Okay, I hope I've fixed this (dev branch). Unfortunately not able to test as my tables are always lower case. An initial import run still works on my side. If you don't mind, please could you test it on yours? For reference, I've used the following to ensure the correct case is being used. If anyone thinks this can be optimised, please let me know. Thanks. // Get the correct table name for ProcessRedirects $redirectsTableNameQuery = $this->database->prepare("SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = :db_name AND TABLE_NAME LIKE :table_name"); $redirectsTableNameQuery->execute(array( 'db_name' => $this->config->dbName, 'table_name' => $this->redirectsTableName, // defaults to ProcessRedirects; which we use to check )); $redirectsTableNameResult = $redirectsTableNameQuery->fetch(PDO::FETCH_OBJ)->TABLE_NAME; if ($this->redirectsTableName == $redirectsTableNameResult || strtolower($this->redirectsTableName) == $redirectsTableNameResult) { $this->redirectsTableName = $redirectsTableNameResult; } Edit: My bad, didn't actually change the select statements. Shall commit that shortly, along with some other enhancements.

Great stuff! Busy working on the table name thing now... Looks like a decent solution is around the corner.