I set the manifest file for multiple pages on my website sandboxd.com to point to the same manifest file. Before doing this there were 4 entries listed on the Kik optimized search each with appropriate titles/thumbnails/descriptions. After setting these 4 different pages (3 games + 1 main site), all the titles/thumbnails/descriptions changed to the main page's. Even though they still point to different web addresses.
I've since set each page endpoint to have a different manifest file, but the entries already listed on Kik optimized results still all show the same info. You can see what I'm talking about by searching "sandboxd" on Kik. You should see 4 seemingly identical results each pointing to different addresses.
Is there something I should be doing to fix this? There was nothing in the documentation about using the same manifest for multiple pages, so I assumed this was okay.
All of your websites have the same title and description in their HTML. For example check the source of these urls:
https://www.sandboxd.com/
https://www.sandboxd.com/games/5
https://www.sandboxd.com/games/10
Related
Our website uses an optional language parameter for displaying pages in either English or Spanish, for instance:
https://www.spotmodel.com/product_info.php?products_id=17442&language=en
https://www.spotmodel.com/product_info.php?products_id=17442&language=es
Of course, code is exactly the same, performance is exactly the same, and page generation speed is exactly the same (just selecting different rows for page text locales)
BUT
In PageSpeed, mobile tab, pages with "language=en" consistently score about 10 points LESS than pages with "language=es" (about ninetysomething in "es", about eightysomething in "en").
According to my tests, it happens on every single page (within the bounds of the small score variations). The generated code is exactly the same (except the small text changes), html sizes are also similar or even bigger in the ES version (370k EN vs 377k ES), functions do NOT perform anything differently.
Problem is that, by default, if the parameter is not found, the page served is the English version, hence i'm getting an "orange" score most of the times, instead of the nice "green" on the Spanish pages.
Any clues on what I'm missing? Is it a bug in lighthouse parsing pages with <html lang=es>
Lets say I have Project A with an attached imageFile.
Then I created 10 different Projects which are underprojects of Project A.
I want to link the ImageFile of Project A to the Wiki of every underproject , so that I can see the ImageFile in the Wiki-Area of each underproject.
What im doing so far is to copy full path of the attached file of Project A in the Wiki of every underproject, like for example:
!>/attachments/download/157/schnittprofil.png!
Is there a better way to achieve that, because every time I update the imagefile, I have to renew the id-numbers of all imagefile-links in the underprojects.
Since an attachment is only actually identified by its ID and all attachments are immutable (i.e. can be changed after upload), new uploads will result in a new ID. Since multiple attachments with different IDs can have the same name, you can also not reliably find an attachment just by using its name in broad contexts.
That said, to solve your issue, you could use the include macro to include a common Wiki page in your sub-project's wiki pages which then displays the image attachment.
For that, you can create a Wiki page named e.g. Schnittprofil in your parent project where you directly upload your file. In the wiki page, just reference the image with
!schnittprofil.png!
Assuming the parent project has an identifier of project-a, you can then include the page in other wiki pages with
{{include(project-a:Schnittprofil)}}
Each time you change the page on the parent project, it will automatically also show the updated content on the child wikis. The only requirement is that the users need to be able to read the wiki of your parent project (e.g. are members of the project with the "Read wiki" permission).
I have two content types (in a Drupal 7.20 environment) which embed views or blocks. When I allow those content types in search results, the results page goes sideways whenever those content types are represented in the result set: the pager shows a different number of total pages from one results page to the next, or disappears entirely after I hit Next (!), fewer than 10 results show per page (yet there's a pager...), etc., etc.
If I disallow those content types (via Custom Search), I don't see any problems with pagination, etc.
What I have noticed is that the actual views/blocks get executed when the search results page is constructed - it's not merely a matter of hits being found in the search_index table.
Anybody know how to address this problem?
(I've searched through stackoverflow, and issues for Search and Custom Search on Drupal.org - no joy.)
Thanks in advance,
Lee
[Edit: fixed a couple of typos...]
[3/17/13 Edit: The problem turns out to be due to the pager for the view or block that is included in the search result set. If the view is in the result set, but doesn't have a pager, there is no problem. My solution, therefore, is to detect that I'm on a search results page in hook_views_query_alter() (by looking at the request URI) and set
$view->items_per_page = 0;
which effectively gets rid of the view's pager.
[I didn't realize I could answer my question - not sure how that's different from editing the question to include the answer, but I'll put my answer here as well, anyway.]
The problem turns out to be due to the pager for the view or block that is included in the search result set. If the view is in the result set, but doesn't have a pager, there is no problem. My solution, therefore, is to detect that I'm on a search results page in hook_views_query_alter() (by looking at the request URI) and set
$view->items_per_page = 0;
which effectively gets rid of the view's pager.
I created a block that I want to appear on these paths:
example.com/sample/1
example.com/sample/2 example.com/sample/3
example.com/sample/4 example.com/sample/6
However, I don't want it to appear on:
example.com/sample/5
Under the visibility setting for the block, I can select show block on "Only the listed pages"
and enter something like /sample/*
Howevever, how do I tell it not to show up in /sample/5 without typing out all other paths individually? Is there an "except" or "not" indicator somehow like how the * indicates all?
Use the context module to handle the placement of your block. It allows you to specify which paths the block should display on, as well as which it should not (by starting the path with a ~)
For example, in your context you can specify your paths like so:
sample/*
~sample/5
this tells drupal to display your block on all paths that match "sample/*" except for "sample/5"
There is only two ways of getting the fine tuning you need:
You type one by one all the URLs you want to include/exclude
You go for the perfectly customizable php code mode.
Maybe you should try Context module http://drupal.org/project/context and see if the more complex, configurable options it provide serve your purpose/solve your problem.
PD. My first answer completely missed the point, i was thinking on views... sorry!
I am using the Drupal 7 Migrate module to create a series of nodes from JPG and EPS files. I can get them to import just fine. But I notice that when I am done importing them if I look at the nodes it creates, none of the attached filefield and thumbnail files contain filename information.
Upon inspecting the file_managed table I see that both the filename and filemime fields are empty for ONLY the files that I attached via the migrate module. This also creates an issue with downloading the files.
Now I think the problem has to do with the fact that I am using "file_link" instead of "file_copy" as the file operation I specify. The problem is I am importing around 2TB (thats Terabytes) of image files. We had to put in a special request with Rackspace just to get access to that much disk space on our server. So I can't go around copying from one directory to the next because of space issues. So "file_link" seems like the obvious choice.
Now you probably want to see how I am doing this exactly, so here is the code snippet:
$jpg_arguments = MigrateFileFieldHandler::arguments(NULL,
'file_link', FILE_EXISTS_RENAME, 'en', array('source_field' => 'jpg_name'),
array('source_field' => 'jpg_filename'), array('source_field' => 'jpg_filename'));
$this->addFieldMapping('field_image', 'jpg_uri')
->arguments($jpg_arguments);
As you can see I am specifying no base path (just like the beer.inc example file does). I have set file_link, the language, and the source fields for the description, title, and alt.
It is able to generate thumbnails from the JPGs. But still missing those columns of data in the db table. I traced through the functions the best I could but I don't see what is causing this. I tried running the uri in the table through the functions that generate the filename and the filemime and they output just fine. It is like something is removing just those segments of data.
Does anyone have any idea what this could be? I am using the Drupal 7 Migrate module version 2.2. It is running on Drupal 7.8.
Thanks,
Patrick
Ok, so I have found the answer to yet another question of mine. This is actually an issue with the migrate module itself. The issue is documented here. I will be repealing this bounty (as soon as I figure out how).