adrian

My best guess is that it's an htaccess issue - most likely an AllowOverride setting that isn't letting mod_rewrite kick in as needed. If you're not familiar with these settings in Plesk, it might be best to submit a support ticket. First thing I would try is to add some gibberish text to the top of the PW root .htaccess file to see if it's being loaded and go from there.

Don't forget Tracy's Captain Hook panel ?

The way other is to simply change the name of the page to match the ID is a hook in your ready.php // rename page to match its page ID $this->wire()->addHookAfter('Pages::added', function($event) { $p = $event->arguments[0]; if($p->template != 'basic-page') return; $p->setAndSave('name', $p->id); }); One thing to note in your module - you are hooking on "save", so it will rename it every time it is saved. If you need the other functionality of your module, perhaps you can change to Pages::added ?

Then try the Hanna code approach and set up attributes for the video ID, and max width / height and wrap the iframe in a container. Google embed video responsively and you'll get tutorials on how the wrapping works. You might end up with a shortcode format like this that lets you insert that into the RTE with the video ID and a max width and the Hanna code takes care of inserting these into the wrapper and iframe HTML. [[video_embed id="" width="500"]]

Are you embedded into a body of text that is wider than what you want the video to be? If the video is on its own, I would recommend checking the responsive checkbox and outputting this field inside a div with the max width you want. If not, then it might actually be easier to use the Hanna code module - then you can specify the url and width you want for each video separately, without the mess of trying to embed an iframe into an RTE field. Let us know if you decide to go this route and need help.

Did you read the configuration notes in the module's description ? "You may want to update the max width and max height settings on the module configuration screen."

For a video embed, use this module: http://modules.processwire.com/modules/textformatter-video-embed/ and select the responsive option. If you need to tweak more settings on the video, then also install this: http://modules.processwire.com/modules/textformatter-video-embed-options/

@antpre - I've just committed a new version - field pairings will now work regardless of the "ignore first row" setting. Please try it out when you get a chance and let me know if you still have any problems.

that's exactly what I don't want ? Just a quick comment - that is exactly what you are doing here anyway ? $channel->name = $this->sanitizer->pageName($title);

In a rush, so only a quick response. Usually when adding a page via the API, it's best to leave the "name" empty and let PW handle that if you simply want it converted from the title. When adding pages via the API, you can do your own check to see if a page with that title already exists: if(!$pages->has('parent=xxxx, title=myTitle')) { That uses the brand new 3.0.153 has() method, but you can also do it with find or count. If you want to prevent duplicates being added via the admin, then you probably want to hook into Pages::setupNew or Pages::add - I have used the latter many times, but not the former so without looking in more detail, I am not sure if it will work as I don't know if it has the new page name yet. Hopefully that gets you going, or someone else will come along with a more complete example.

Hi @antpre - sorry the problems. Looks like you have discovered an issue with field pairings when the "ignore first row" option in checked. If you uncheck that and of course remove that first row of column names everything should work fine. I tried to fix it quickly, but there's more to it than I realized and I have a deadline today, so will have to look at fixing properly later, but hopefully the above suggestion will get you going.

That new unique flag shouldn't impact this - PW still shouldn't allow duplicate names under the same parent. If for some reason it is, it sounds like a bug. Are you creating pages via the Admin or API?

@jonatan - looks like you used http://modules.processwire.com/modules/fieldtype-runtime-markup/ rather than https://github.com/Toutouwai/FieldtypeRuntimeOnly but they both do much the same thing. Anyway, glad you got it working and thanks for chiming on that Github request - that visibility stuff definitely needs an overall.

Hi @jonatan and welcome to the forums. The "Open when populated + Closed when blank + Locked (not editable)" is the closest to what you are looking for. You might actually want to add your support to this request: https://github.com/processwire/processwire-requests/issues/346 Back to your original question, I haven't used Mystique, so not sure what its limitations might be on this front, but I wonder if you can make use of https://github.com/Toutouwai/FieldtypeRuntimeOnly to add the instagram data in a runtime field.

Thanks @bernhard - is that just the start of things - is it listing virtually everything as new? It is kinda looking like the old cached version was removed somehow in the downgrade / upgrade process. Let's see what others report their experience to be.

Thanks @bernhard - those Breadcrumb and $process methods have been persistent for a while. I think you'll actually need one more update for them to disappear. I "reset" my cache when I was updating Tracy yesterday by going from 152 back to 151, then to 152 and today to 153. Can you remember to check on upgrade to 154 and let me know if the problem still persists please? Thanks.

Everyone else coming from 3.0152 to 3.0153 seeing this? Looks correct to me based on what Ryan just committed to the core.

Just a quick note that the latest release fixes the "NEW SINCE" feature in the API Explorer panel. It had always mostly seemed to work, but I was often seeing results from old upgrades but wasn't sure why. I think it's now fixed, but I'd appreciate if you guys could check at your end when you next upgrade the PW core and see if it appears correct for you as well. Thanks.

@horst - the site looks wonderful, but unfortunately the speed for me is actually unusable because of this: Unrelated to speed, but also notice this: HTH!

I think you'll get what you want by hooking InputfieldPassword::render Take a look at this function: https://github.com/adrianbj/EmailNewUser/blob/026653e76328607540ad782b104b79defe776469/EmailNewUser.module.php#L86-L99

Hi Ryan, Yeah, the key things are: 1) make name / email fields non-editable (actually I'd prefer not visible). Where is the "non-editable" option? I can't seem to find it in the field settings or the comments docs. 2) being able to use a different name field - guests who fill out the form are likely to enter something like "John Smith", but the automatic population of this for logged in users is going to be something like "jsmith" or perhaps even "jsmith-gmail.com" - this lack of consistency isn't nice. 3) use local image for the avatar, rather than using Gravatar. It does look like the new getFormMarkup(), renderForm(), and placeholders() might help solve some of these at least.

Yeah, it's the only way to handle it really because that upload_tmp suffix is needed to trigger the later rename. Anyway, glad you got it sorted.

Thanks for the comments system upgrades. Any chance while you're still in that space that you'd consider taking another look at the enhancement this PR (https://github.com/ryancramerdesign/ProcessWire/pull/954) added so that logged in users don't need to fill out name, email fields etc? Thanks.

Hey @Kiwi Chris - the "_upload_tmp" suffix is added when the value for one of the fields is not available yet. What should happen (and it working for me here) is that if there is no value for one of those fields listed in the format rule, after initial ajax loading of the image, it will have that "_upload_tmp" suffix, and then when you save the page, assuming you have selected something for those required format fields, the file will be renamed once again, now that it has the data it needs. BTW, I just tested with an Options fieldtype with a mixed case name, so there should be no problem there. I am sure you've thought of this, but be aware that Options and Page Reference fields set to store multiple values will automatically use the first selected value. Not sure where to go from here, but maybe you could start with a simple {$page->title} rule and if that works, add another field and see which one breaks it and we can investigate from there.

VC 2 is deprecated, you should use the dev branch instead: https://github.com/teppokoivula/VersionControl/tree/dev