ruewa

Hi David,

Thank you for your fast answer. I tried it with Ajax Search Lite and it does the job better than i thought. You have to dig into the extensive settings, but i got all i wanted.

I put the search field into a (self-made) header plugin area and restricted this area to the (private) wiki pages only (with is_singular('yada_wiki')), so it should be completely hidden from the public sphere.

Best regards,

Ruediger

Hi David,

you mean the standard WordPress search widget? Yes, i tried it, but that’s not what i want. It searches all pages – i need to restrict it to wiki pages. It does a full text search – i just want to search for titles. It delivers a result page – i want to get a dropdown link list. Just like the wiki link button in the Yada Wiki editor – and just like the behaviour of the wikipedia search field.

The optic might be secondary: whether it’s a dropdown-edit field or a button which opens a popup like the wiki link button. But there’s another wish: a switch to determine the kind of search: From the beginning or in-text (the link button does the latter).

Maybe i should explain what we are doing. We created an initiative which does local history research, focussed on the local nazi barbarism and its aftermath. In our neighborhood there was once a concentration camp established in late 1944. We do a lot of research about this camp, we now know all the prisoners names and mostly their fate, we collected > 12.000 document scans and already filled 1.500 wiki pages with specific information. Now the webspace runs short and we also want to go more public – with the aim of establishing a local memorial site some years ahead. Therefore i’m building a new website with more storage space. It should also become our public representation and history information site – with a public and an internal area. The wiki is our very detailed research “workshop” (which did really a good job by now) and should be resticted to members only. So i have to isolate the internal area with the wiki from the public area. This is the reason why i need a search widget restricted to the wiki. And there’s also a simple reason for the request to determine the search mode (from the beginning vs in-text): Every prisoner has his own page titled “Name (concentration camp prisoner)”. So if i search for “concentration camp prisoner” the result is useless, because i get hundreds of items while searching in-text. A search from the beginning would only result in some summary pages (i know, there would have been better ways using categories, but you don’t see all these things from the start).

So it would be great if you could help us resolving this problem. And i guess it could be also a great improvement for other users.

Best regards,

Ruediger

• This reply was modified 2 years, 4 months ago by ruewa.
• This reply was modified 2 years, 4 months ago by ruewa.

Hi David,

i got it, thanks to your hint with export/import. I didn’t see that “wiki pages” are an export category of its own (well done!). So here’s the HowTo:

1) Dashboard/tools/export the wiki pages and import them to the new site.

2) Copy all (relevant) media files including the scaled picture files to the new site via ftp.

3) Synchronize the new media files to the database – i used the plugin “Media Sync”.

4) In the hosting interface open the database (with phpMyAdmin in my case), select the posts table and replace the old domain name by the new domain name in the column post_content.

5) Myteriously some formatting information got lost in der wiki pages on the new site. Especially the alignment of the pictures was resetted to alignnone. In my case there are lots of wiki pages with attached document scans, originally placed side by side. Now they were one below the other. So i also replaced “<img class=”alignnone” by “<img class=”alignleft”. This caused some formatting flaws of its own on some pages, but significantly less than before. So some manual work is left, but that’s okay.

Thanks for putting me on track!

Best regards,

Ruediger

Problem solved. Thanks for the super fast fix!

Same problem here on two sites after updating 3.4.4 –> 3.4.4.1. Unable to get access to the backend with “critical error” message. After disabling wp-members via ftp I got access back.

Hi David,

this works fine and solved my problem.

Thank you very much!

Kind regards

Ruediger

Hi David,
thanks for the speedy reply, but this didn’t work. The ../wiki page showed up anyway, only without the caption “Archive”. It shows a complete list of all wiki pages.
On the other hand I couldn’t see newly created wiki pages anymore, they became redirected to 404, even though they showed up in the All Wiki Pages list and were accessible in the editor.
I tried to override the ../wiki page with a post and a page on the same address, but also without success.
Yes, it’s kind of sensible data – not on a live-or-die-level, but yeah…
I don’t use categories by now, there’s a clear tree structure of the pages.

Any way to redirect this ../wiki page to 404?

Best regards
Ruediger

Hi efrenjr,

I couldn’t fix it, but took the easy way where the problem occurred: I disabled the print option in these postings and enabled the download of a pdf-file instead. That’s okay for me, so I didn’t try any longer.

I guess the editor has dropped out. I also wrote to the polyglot team since.

In the meantime, the resulting translation can be downloaded manually via the translation page using “export” at the bottom of the page.

Yes I’ve seen, thanks. But this needs an additional trick: You have to set the export from “all current” (which excludes the pending phrases) to “only matching the filter” with filter setting to “Current/waiting/fuzzy + untranslated (All)”.

It’s working now on my system, but in the common interest I hope the polyglot team will fix it soon. Thanks!

Ruediger

• This reply was modified 7 years, 6 months ago by ruewa.
• This reply was modified 7 years, 6 months ago by ruewa.

I’m also got upset about the answer “don’t worry, it might wirk SOMETIMES”. But okay, I thought, a programmer needs time to find and fix a bug. Now 10 days are gone since posting the issue and my impression is that the author doesn’t take the issue serious. Obviously there is a bug. And I don’t want to run into the same situation as Bryan. So I disabled and deleted the plugin now.

Updated to Firefox 46.0
Tried with Chromium 49.0.2623
Tried with Linux Mint Debian Edition / Firefox
–> All the same

Hi Arshid,

Deletion / new installation seemed to help a little bit, but there are still issues. First captcha / login / logout: New captcha on logout screen
Second captcha / login / logout: No captcha any more, normal login.
After that: No Captcha any more until closing Firefox
Restarting Firefox: Captcha / login / logout / no captcha any more

WP 4.5.2
Iconic One 1.5
Kubuntu 14.04.4
Firefox 45.0.2
https://attac-aalen.org/blog/

Update: Deactivation / Reactivation helped, but still strange behavior:
a) Fallback to main page after first failed login attempt
b) No captcha but normal login after logout

Update: Seems to be completely broken: No timeout after > 5 attempts either.

Okay, got it.

I removed the get_sidebar line in single.php and added this after get_header:

<style type="text/css">
	.site-content {
 		width: 96%;
	}
	@media screen and (min-width: 960px) {
		.site-content {
 			width: 77%;
			margin: 0px 10%;
			border-right: 0px solid #F1F1F1;
		}
	}
</style>

I don’t know whether this is a good or an ugly approach (warn me, if that’s a bad idea), but it seems to work the way I want.