ryan

The problem is that your links get converted to tags like {123} and the only thing that knows what that is, is PageLinkAbstractor. So if you were to ever stop using PageLinkAbstractor, all those links would be broken with no clear way to fix them short of manually editing each page. But if people really like the module still, I do have a much newer version (compatible with PageLinkAbstractor) called LinkMonitor that I could release. The nice thing about LinkMonitor is that it alerts you when it finds a broken link too. It checks for broken image/page links in the background when rendering pages. The only reason I've not released it is that I've been thinking abstraction of links isn't a good idea since it is 1) a drug you can't stop using; and 2) ultimately makes the content less portable. But maybe these are worthwhile tradeoffs. The 2.3 core comes with a module called PagePathHistory. It's not installed by default, but you can install it just by clicking "install" in the modules screen. It will keep track of all page movements and setup redirects to ensure links aren't broken.

This makes sense to me, I've gone ahead and changed it. It should appear on the dev branch next time I'm pushing updates to it, probably later this week.

On an unpublished page, there are two buttons at the bottom: Save and Publish. To save changes to an unpublished page, and keep it unpubilshed, you would click "save" rather than "publish". If you are worried about a novice editor, one good thing to tell them is to use the Save button at the bottom rather than the publish button at the top. Perhaps the button at the top should be the Save button, with the publish button at the bottom instead–I'll look into that.

$pages->find("parent.template=news-month-archive"); $page->rootParent->find("parent.template=news-month-archive");

Art, could I look at the relevant template files? If you don't want to attach them here, feel free to PM them to me.

That makes sense to me. Seems like a good approach.

PHP safe_mode was deprecated in 5.3.0 and eliminated starting in version 5.4.0. If the web host is advising not to turn it off, it would make me concerned about that web host's security. Any idea why they are advising that or suggesting that it involves a performance penalty? (it sure shouldn't)

I'm not sure I follow all of this or understand the https certificate issues that may be interfering with it, but you might want to try having a second invisible iframe that comes before the first (in the source/markup), to attempt to register/initiate the session?

I am guessing that maybe there is a module installed that had an older jQuery version dependency? jQuery tends to deprecate a lot of widely used stuff with new versions. We upgraded jQuery versions in the 2.2 => 2.3 upgrade, so if there was some jQuery dependency in a module installed in 2.2, that seems like a potential place to look. I would start by uninstalling 3rd party modules, especially those that might affect the PageList and see if you can track it down. Let us know what module it is.

Whenever you get that error message, go and enable debug mode in /site/config.php, just so that you can get some more details as to what is happening. Double check that your homepage template has the guest role enabled. No need to sanitize the password btw.

Sorry I'm a little behind with messages here, I'll be caught up by mid week. But I've got a good excuse. Yesterday Karena Savannah Cramer was born. She is our 2nd daughter (Hanna Ryan, age 3 is our first). We will all be coming home from the hospital hopefully tomorrow.

I've run into a similar issue on one of my sites that has a lot of accounts to manage. I'm hoping to improve the core modules (ProcessPageType and/or ProcessUser) in this regard whenever there is bandwidth to pursue it.

Nice job Soma! Any chance I can talk you into adding this to the modules directory?

There is a little overhead in using this module since it has to parse through the abstractions and translate them to/from URLs. There's also the aspect of being unable to stop using the module once you start (since abstracts get stored rather than URLs). As a result, I think it's best not to use this module and instead just do a search/replace on your SQL dump before you migrate it from a subdirectory install to a root install. Though I am hoping to have a native/core solution for this particular issue before long.

Not sure I understand -- Why? It's a Friday here, end of the day, and my mind is lazy.

I wonder why this is the case? Sounds like bug to me, I will have to try and duplicate. Has anyone else run into this? I'm unclear about why the homepage should be hidden and unpublished? From an SEO standpoint, I think it's a little better to let your homepage (root, no language segment) serve as the homepage for your default language. The thinking here is that people often link to your domain rather than a specific page in the domain. It's technically stronger to have those links resolve to an actual page rather than to a redirect. Here's another good example of a language switcher that uses the multi-language page names module: http://processwire.com/talk/topic/2979-multi-language-page-names-urls/?p=33537

These two URLs resolve to different places. If I take out the http and domain, they are still different: /site/assets/list-details.json /site/assets/data/list-details.json Is that it? Or just a typo?

I think this sounds like a fine approach, though would be more inclined to generate it dynamically. Assuming the JSON is originally generated from ProcessWire, having it generated dynamically is going to give you more flexibility and make it easier to update. Having a dynamic request cached is basically the same thing as having a static file. You could cache it with MarkupCache, the built-in template cache, or ProCache. On the other hand, if the data really is static, then you don't need ProcessWire to generate it or serve it, as you could just upload a JSON file to a page and be done with it.

It looks to me like the way you are doing it is right, if I understand it correctly. You could set a user-defined variable to $page, like $page->myJS = 'some javascript here'; and then output that before your closing </body> tag. The skyscrapers profile is probably an even better example of the main.php approach. Whereas the blog profile is also taking an MVC approach, so there's a little more going on in the blog profile that may be harder to follow at first. Though note that in the skyscrapers profile, the "main" file is called _out.php.

With template files you generally have a documented set of API variables ($page, $pages, $user, etc.), and this is what the set() methods of TemplateFile are geared towards. On the other hand, when passing variables into a $page->render(), variables passed in may be unknown/undocumented to the template file, and will be installation-specific, since PW doesn't pass in API variables that way. By having them in a known array ($options), you have a way of inspecting them, or at least knowing where they will be. Otherwise, the template file would have no means of self discovery for these things. It decreases the unknowns, increases the portability, and introduces an appropriate level of separation from the system API variables. On the other hand, this is largely theoretical… I've never had the need to pass in variables to template files in this manner, so am mainly just trying to accommodate the needs brought up in this thread.

After you do a $session->login() the $user variable that was already there will still be the same one that was there before the login. So you need to change the $user variable yourself, i.e. $user = $session->login($email_address, $asmUserId); Also be certain that none of this is mission critical from a security standpoint. This is a publicly accessible interface to creating, modifying and accessing user accounts.

For a PW upgrade, you shouldn't have to re-import data from a CSV? That sounds like kind of a difficult way to piece things back together. I would follow the traditional upgrade process if you can (by replacing the /wire/ dir, and any other version-to-version instructions included).

I just tried upgrading a PHP 5.2.17 install and ran into the same issue as you did. Though the errors got logged for me, and I'm not clear why PHP 5.2 triggers these errors that PHP 5.3 doesn't, but it was easy to fix. I've pushed a couple of small fixes to dev so that it should work with 5.2 again.

It should still work fine on PHP 5.2. You won't be able to use anonymous functions, but ProcessWire itself doesn't have any PHP 5.3 requirements yet. I'm thinking we shouldn't have that requirement until the next major version (PW 2.4). The error you are running into does sound a lot like a opcode cache error. Though it also could be a PHP 5.3.8 bug–it sounds like PHP doesn't like the fact that MarkupCache implements two interfaces that require a __get() method. That's not actually a problem, but will keep an eye out if anyone else runs into it.

You can move your /wire/ dir wherever you want and use symlinks. However, I don't think this would do anything for security. The benefit of doing it would be just if you want to share the same /wire/ dir amont multiple installs. I think that some CMS products are prone to vulnerable files and so you want to move them out of web root. ProcessWire is not one of those products and your .htaccess file protects several directories from web access. You can try modifying PW's /index.php file to choose a different $config->assets dir. But I don't recommend it, as I've not tested it. Yes, you can store these assets wherever you want. ProcessWire doesn't actually link to them, only you do, in your template files. As a result, it doesn't matter where you put them.